AI Engineering Continuity and Handover — v1.1 amendment¶
This amendment keeps everything in the current standard (roles not instances; PRIMARY / DEPENDENCY / REFERENCE scope; current-state record; checkpoints; handover minimum content with DO NOT REPEAT / DO NOT CHANGE; reconciliation by the incoming agent; repository-qualified references; access-aware handling; cold-start test; GREEN/AMBER/RED triage check). It adds what experience since September showed was missing. Everything below is a minimum: projects may do more; agents with small context windows get less (§6).
1. Two kinds of handover (plus checkpoints)¶
| Kind | When | Ownership | Record | Closed when |
|---|---|---|---|---|
| A. Role transfer | An agent leaves the role (priority shift, replacement, limits) and another takes it over with continuity | Moves to the incoming agent | Existing 08-Templates/AI-Engineering-Handover-Template.md |
Incoming agent records reconciliation and READY FOR TAKEOVER; MMDEP-PM updates the role registry (approve item); the outgoing agent is read-only for that role afterwards |
| B. Delegation (work request) | The role owner needs one bounded step done by another role/agent (review, research, a test, an estate check, a small change) | Stays with the requesting role | A Work Request issue (§2) and a Work Result comment (§3) | The requester accepts or rejects the result; the issue is closed by the requester |
| C. Checkpoint | Same role, new session (end of iteration, limits, pause) | Unchanged | Current-state record (AI-ENGINEERING-CONTEXT.md or equivalent) |
Next session starts from it |
Rules: - Only one agent holds a role at a time (MMDEP spec §5C). Delegation never moves ownership; if the delegate ends up doing the role's work, convert to a role transfer (A). - The incoming or delegated agent uses its own model choice today. When the MMDEP controller exists, MMDEP will split work and choose agents and models by availability and capability; the records below stay the same (transport-independent, as §11 of the standard already says).
2. Work Request (delegation), as a GitLab/GitHub issue¶
Keep it under about 250 words plus links. Required fields are marked ●; the rest are optional.
● WORK REQUEST: <one-line objective>
● From role: <ROLE-ID> ● To role/agent: <ROLE-ID or agent> Seat: <SEAT-ID>
● Acceptance criteria: <copied verbatim from the source, with its coordinates; never paraphrased>
● Scope: IN <paths/areas> OUT <paths/areas> DO NOT CHANGE <...>
● Context pack (max 8 items, each with coordinates + why):
Source: <platform> <owner>/<repo> | Path: <path> | Ref: <commit> | Purpose: <why> | Access: required/optional
● Pinned state: <repo>@<commit>; spec/standard version: <id vX.Y §n>
Budget / turns: <e.g. 3 turns, ≤ N credits> Due: <date>
● Reply with: the Work Result format (§3)
3. Work Result (reply comment on the same issue)¶
RESULT: done | partial | blocked
Evidence: <tests, logs, links>
Changes: <branch / MR/PR / commit>, or "none"
Questions / assumptions: <numbered; each marked blocking or not>
Agent: <tool/model> Seat: <SEAT-ID> Effort: <turns, time, credits if known>
4. The prompt is a pointer¶
When a person or a controller starts an agent on a handover, the prompt stays short (about 10 lines) and never pastes background:
You are <ROLE-ID> for <project> (seat <SEAT-ID>).
Read: <issue/handover coordinates> at <repo>@<commit>.
Follow: MMDEP STD-AI-CONT-001 (this standard) and the repo's agent instructions file.
Do: <the next step only>.
Reply: in the issue, using the Work Result format.
Session: NEW (cold start from the record) | RESUMED <session id/URL> (answer to your question: ...)
Agents must assume NEW unless the prompt says RESUMED. A resumed session is never assumed silently, in either direction.
5. Session types¶
| Session type | Examples | Continuity | Rules |
|---|---|---|---|
| Local, headless | MMDEP harness running claude -p, codex exec, gemini -p |
Fresh each run unless resumed by session ID | Cold start from the record every time; prompt is a pointer; checkpoint before exit |
| Local, interactive (manual mode) | Claude Code or Codex in a terminal | One session per iteration/story; several interactions allowed inside it | Checkpoint at the end of the iteration; do not carry a session across iterations |
| Online, continuous | Claude Projects and ChatGPT Projects chats | Long-lived; each chat has its own URL | Record the chat URL as the session locator in the role registry entry; project instructions point to the current-state record; checkpoint to the repository at every milestone (a chat is never the only copy); start a new chat when it grows long, with a checkpoint first |
| Remote control | Steering a running local Claude Code session from phone or browser (claude --rc) |
Same as the underlying session | In use since 10 Oct 2026. Other agents and chats cannot message it; work reaches it through the forge (a Work Request issue) or a person. Stops when the computer sleeps or the session closes |
| Online, cloud agent | Claude Code on the web, Codex cloud, Copilot coding agent | One session per request; runs in the vendor's cloud | Treated like local headless: cold start from the record, pointer prompt, result on the forge. No client data; no Windows-only steps |
5.1 Session names (added 10 Oct 2026, Atul)¶
Name every interactive session so that it can be resumed by name instead of hunting for an ID:
<project>-<role>-i<NN> e.g. mmdep-dev-i03, mmdep-pm-i03, pe-dev-i01
<project>: the MMDEP project name (short form allowed:pefor Portfolio Engine).<role>:dev(coder),lead,pm,review.i<NN>: the iteration. A new iteration starts a new session (checkpoint first); the old name is kept for reference.- Claude Code: start with
claude -n <name>(add--rcfor Remote Control), resume withclaude -r <name>, rename inside a session with/rename <name>. - Online chats: put the same name at the start of the chat title.
- The name and the session URL are the session locator recorded in the role registry and in the current-state record.
6. Context sizing (flexible by agent capacity)¶
Different agents handle different amounts of input. The context pack is sized to the receiving agent, not the sender:
| Context tier | Typical agents | Context pack |
|---|---|---|
| T1 broad | Claude (local), ChatGPT (online, connectors) | Up to 8 references; may include a repo map and dependency repos; agent may explore further with search tools |
| T2 narrow | Copilot, Gemini Flash, small or local models | 1–3 named files plus the issue; no whole-repository references; explicit file list only |
Rules for all tiers: never "the whole repository"; prefer a repository map (tree plus one line per module) over raw content; exclusions configured per tool where available (for example Copilot content exclusion, Claude deny rules). The tier is recorded per agent in the MMDEP agent registry.
7. Seats (virtual developer accounts)¶
A seat is a virtual developer identity that can be allocated to a person, a physical machine or a browser session (fully online agents). Hardware is not part of the seat.
Seat record (kept in MMDEP, not in project repositories):
SEAT ID: <e.g. SEAT-MAIN, SEAT-LEGACY, SEAT-WPDEV, SEAT-API>
Forge identities: <GitLab/GitHub usernames>
Repository access: <repos and role on each>
AI tools available: <tools/plans; free or paid>
Allowed data classes: <public / synthetic / internal / client>
Allocated to: <person | machine | browser account>
Roles currently held: <ROLE-IDs>
Current seats (6 Oct 2026, to be confirmed by Atul): SEAT-MAIN (Atul's main account; MMDEP, MWMC, MCRM, Portfolio-Engine; paid and free agents); SEAT-LEGACY (legacy developer); SEAT-WPDEV (next-generation website; mostly free ChatGPT); SEAT-API (API / MM-Cron; mostly free ChatGPT; currently waiting on the legacy developer).
What crosses seats and what does not¶
| Shareable across seats | Not shareable |
|---|---|
| MMDEP standards, role registry, repository map, reference indexes | AI logins, API keys, tokens, SSH keys |
| Handover, Work Request/Result and current-state records in repositories the seat can read | Chat transcripts and session histories of another seat |
| Validated excerpts of sources a seat cannot access (reference-excerpt convention) | Client or personal data |
| MMDEP item titles/status (snapshot, inbox mirror) | MMDEP hub database, other seats' local workspaces |
Services across seats (estate audit, deployment evidence, access to another project's information) are requested from MMDEP-PM as a Work Request labelled mmdep-request. Credentials are never shared to give another seat a capability.
8. Traceability: one seat, many agents¶
A seat often runs several agents in one project, which made it hard to see which agent did what. Traceability is achieved in the repository itself, without depending on permissions:
- Commit trailers on every agent-made commit:
Agent: <tool>/<model> (e.g. claude-code/sonnet, codex/gpt-x, copilot-agent) Role: <ROLE-ID> Seat: <SEAT-ID> Work-Item: <issue or MR/PR reference> - One branch per work item per working agent:
<type>/<issue>-<slug>as in the Repository and Delivery Standard; a delegate working in parallel on the same issue appends--<agent>(for examplefeature/42-nav-adapter--codex). - MR/PR description includes Role, Seat, Agent(s) and a link to the handover or Work Request.
- CI check (MR pipelines only, documentation-light): warns when agent commits lack the trailers. It starts as a warning, not a failure, and becomes a failure only by MMDEP decision.
- MMDEP mirrors forge activity into its ledger with the same identifiers.
9. Making agents follow this without constant reminders¶
Put the rule where each agent always reads, generated from one source (MMDEP backlog AG-1):
| Agent | File it reads automatically |
|---|---|
| Claude Code | CLAUDE.md |
| Codex | AGENTS.md |
| Copilot | .github/copilot-instructions.md |
| Gemini CLI | GEMINI.md |
| Claude / ChatGPT Projects | Project instructions (link to this standard and the current-state record) |
Each file stays short: role, scope, the current-state record path, "prompts are pointers", the Work Result format, commit trailers, and the environment profile (Windows, PowerShell quoting). MMDEP triage (§14 of the standard) adds two checks: trailers present on agent commits, and open Work Requests have a result or a reason.
10. Forge structure (for later, not blocking work)¶
- GitLab groups and subgroups let roles be granted once for a set of repositories and inherited by every project in them; access can still be set per repository. Labels, boards and milestones can be defined at group level, and group views list issues across repositories, which suits cross-project triage. Plan limits apply (GitLab Free: 5 users per top-level private group; some features such as epics need paid tiers), so seats and the legacy developer should be counted before restructuring.
- GitHub organisations offer teams and repository roles (Read, Triage, Write, Maintain, Admin).
- Recommendation: keep the current structure; once this process is stable, map seats to groups/teams with READ on DEPENDENCY/REFERENCE repositories and WRITE only on PRIMARY ones. Traceability (§8) does not wait for that.
11. Relationship to MMDEP (the orchestrator)¶
| This standard | MMDEP implementation |
|---|---|
| Role transfer (A) | Role map change by approve item; spec §5C |
| Work Request / Result (B) | Forge issues as the bus (DR-002); MMDEP mirrors them into items and the ledger |
| Prompt as pointer, NEW/RESUMED | Harness (H1): session ID stored per task; RESUMED banner on resume |
| Context tiers | Agent registry field; context pack generator (backlog CTX-1) |
| Seats | Seat registry (new backlog item) |
| Trailers and CI check | Ledger identifiers; drift and external-change detection |