Async human-agent handoffs that survive clean sessions

An asynchronous human-agent handoff should be a durable task with an owner, current state, evidence, acceptance criteria, and one explicit next action. Chat history can explain a session, but it should not be the only place where the team records a commitment or blocker.

The handoff packet

Use these six fields:

1. Outcome: what must be true when the task is done.
2. Current state: completed work and the exact stopping point.
3. Evidence: links to code, documents, logs, screenshots, or decisions.
4. Constraints: security, scope, deadlines, and actions that require approval.
5. Acceptance: observable checks that prove completion.
6. Next action: one person or agent, one verb, and the condition for starting.

Example:

Outcome: MCP setup guide matches the released endpoint and passes the site build.
Current state: Article drafted; client command still needs verification.
Evidence: MR !84, release notes 2.3, screenshot in task attachment.
Constraints: Do not publish before production endpoint responds successfully.
Acceptance: command tested; links resolve; npm run check/build pass.
Next action: Roman verifies production credentials, then moves task to Ready.

Why chat summaries are not enough

Chats are useful for exploration but weak as coordination state:

• A new session may not receive the full conversation.
• Teammates cannot reliably query every private agent thread.
• Decisions, evidence, and proposed work become mixed together.
• “Done” can mean the agent stopped rather than the outcome shipped.

A shared task board makes state queryable. Source code remains in version control; durable knowledge belongs in documentation; sensitive secrets stay in a secret store. The task links those systems without copying all of them into its description.

Use statuses as contracts

Keep states small and explicit. A useful baseline is:

State	Meaning
Pending	Accepted backlog item; nobody is acting yet
In Progress	One named actor owns the next action
Blocked	A documented condition prevents progress
In Review	Work exists and a named reviewer has a decision to make
Done	Acceptance checks passed and the outcome is available

Do not move a task to Done merely because an agent produced text or code. Link the validation result, release, or approved decision.

Make blockers actionable

“Waiting for human” is not a useful blocker. Record:

• the decision or permission needed;
• why the agent cannot safely infer it;
• the recommended option and tradeoff;
• who can answer;
• what will resume after the answer.

This turns a notification into a decision packet. A teammate in another time zone can respond without reconstructing the session.

Prevent duplicate ownership

Before starting, the actor should list relevant In Progress tasks and claim one task explicitly. During execution, new discoveries become comments, checklist items, or separate proposed tasks—not invisible side quests.

When the work changes owners, update both the assignee and the next action. An assignment without a clear next action only relocates ambiguity.

Apply safe agent autonomy

Agents can list, create, and update tasks through an MCP task server, but permissions should reflect impact. Use the MCP security checklist before allowing automatic state changes, and retain human approval for destructive or high-blast-radius operations.

A repeatable clean-session routine

At the start:

1. Load the task and linked evidence.
2. Confirm its state, owner, constraints, and acceptance checks.
3. Check for newer comments or releases.
4. Restate the next action before changing anything.

At the end:

1. Update current state and evidence.
2. Record validation performed and failures remaining.
3. Set the next owner/action or mark a precise blocker.
4. Move to In Review or Done only when its definition is satisfied.

This is MCP task management applied as an operating discipline rather than a TODO capture trick.

Try the pattern

Create one board, choose one real cross-time-zone task, and use the six-field packet for a week. Kangram can keep the same task visible from the web, Telegram, and an MCP-connected agent; the setup page shows the current connection path.