Resume an AI agent session or hand off project work

My Architect keeps project context, work ownership, and recorded progress available across sessions. Use a checkpoint to locate the work, then verify the live state before continuing. An explicit handoff transfers a claim; a message, document, or nextStep description does not.

The expected outcome is a continuation under verified ownership, with completed work, uncertain operations, and remaining actions clearly identified.

When to use this workflow

Use it after a session interruption, context reset, worker change, or uncertain command response. You need the exact project pid, authorized scope, the current executor’s distinct actor identity, and any saved requests/receipts. Start with the agent quickstart if the connection is new.

Resume from verified state

1. Open the checkpoint. Recover the target and work IDs, actor/claim IDs, observed revisions, source snapshots, complete-read records, accepted decisions, evidence, blockers, and next step. Keep full requests and receipts for your own operations. A checkpoint is a project document, not proof of current server state; an old next step may already be completed.

2. Refresh the connection and work. Call get_epic_flow_capabilities({pid}) and get_epic_flow({pid,nodeId}). For child work, also read get_child_work_claims({pid,nodeId}). Confirm current ownership, stage, wait, cancellation, and accepted policy. A missing endpoint or access failure means unavailable state. Do not reinterpret it as an empty queue or bypass it with legacy status writes.

3. Read complete fields and fresh sources. When compact fields are truncated, use get_epic_flow_detail for policy, review, nextStep, or wait. Policy is project-wide; other fields require nodeId. Join all content windows at nextOffset, pin continuations to the first revision with expectedRevision, and parse only when complete. A revision conflict requires restarting that field.

   Refresh get_scoped_context summary without the old token. A matching fingerprint plus retained complete content allows reuse; an old token alone does not. A changed snapshot requires the mandatory manifest/details again, preserving all current/base/proposed records and variants. Follow the context-reading workflow, including unresolved gaps. Refresh affected sources without repeating unrelated audits.

4. Verify the claim before execution. Check the exact actor and claim ID against live state. Do not adopt another agent’s actor or take its claim because it appears old. For unclaimed authorized work, obtain your own claim through the coordination workflow. get_next_epic recommends work; it does not assign ownership or expand scope. An empty recommendation does not mean delivery.

5. Record progress or transfer ownership. If live capabilities advertise update_progress, the current root or child holder can report verified results, remaining work, and blockers in nextStep. This leaves stage, ownership, wait, review, and policy unchanged. Without support, save the checkpoint and identify unsynchronized board progress.

   To transfer an epic, the current holder sends handoff. Child work uses handoff_child. Save the complete request before sending. These illustrative arguments require replacement with live IDs, a new operation ID, and the observed revision:

   {
     "pid": "Example Project",
     "command": {
       "operationId": "handoff-example-001",
       "expectedRevision": 12,
       "actor": "worker-session-a",
       "action": {
         "type": "handoff",
         "nodeId": "epic-example",
         "claimId": "claim-example-001",
         "assignee": "worker-session-b",
         "reason": "Implementation checked; review remains.",
         "nextStep": "Review the recorded artifact and evidence."
       }
     }
   }

   Submit through apply_epic_flow_command. Verify receipt and current state: the new claim ID is the handoff operation ID, and the epic stage is preserved. Decision waits can block transfer; describing progress does not clear them.

Recover uncertain operations

After a timeout, replay the exact saved request, including operation ID, revision, actor, and action. Do not create a replacement claim. get_epic_flow_history({pid,operationId}) helps reconcile receipts, but its preview cannot reconstruct a lost request.

After a known revision conflict, reread state and reconsider intent; a new logical request needs a new operation ID. Preserve others’ changes. A replay receipt’s resultRevision can precede the returned current flow revision; never restore old ownership from that receipt.

Expected outcome

The next agent can identify verified work, unresolved operations, and its actual ownership. Handoff and progress do not complete work. Merged code, done children, or an old completion note still require delivery verification.

Prompt to copy

Resume this My Architect work from its checkpoint. Refresh capabilities, context, and claims; reconcile uncertain operations before writing. Continue only the authorized scope under the correct claim. Record verified progress, unresolved gaps, and the next step, preserving exact requests needed for retry.

Verified against app/MCP 1.11.0 and workflow plugin 2.6.0 on October 13, 2026. Confirm the connected server’s capabilities before applying a procedure.