The agent handoff receipt

What a receipt is

A handoff receipt is a short, fixed-shape block that a worker lane returns at the end of every run. It is not a summary and not a status update. It answers one question: can the next worker continue from here without re-reading the whole history?

Seven fields is enough. Fewer and the next run starts guessing. More and nobody fills it in.

Mission

The single job this run was supposed to do, in one line.Example: Repair checkout handoff

Source of truth

What the run treated as accepted reality — the files, routes, records, or documents it read from.Example: Accepted files and routes

Worker lane

Which lane owned the work. Research, build, QA, content, operations. One lane per run.Example: Build + QA

Last checkpoint

The most recent verified state, stated as pass or fail. Not "looks good."Example: Build passed

Proof returned

What a human or the next agent can actually inspect: files changed, checks run, sources used, blockers hit.Example: Files changed, route checks, blockers

Human gate

Whether this run is allowed to proceed on its own, or is holding for approval. Sends, deploys, spend, and deletes always hold.Example: Deploy approval required

Next action

The one thing that happens after approval, and the fallback if approval is refused.Example: Approved publish, or repair and re-run

The copy-paste template

Put this at the end of a system prompt, a mission brief, an n8n step, or a repo convention file. Ask the lane to return it filled in, every run, without exception.

handoff-receipt.md

## Handoff receipt

- Mission:          <the one job this run was given>
- Source of truth:  <files / routes / records treated as accepted>
- Worker lane:      <research | build | QA | content | operations>
- Last checkpoint:  <pass or fail, and what was checked>
- Proof returned:   <files changed, checks run, sources, blockers>
- Human gate:       <none | approval required for: send/deploy/spend/delete>
- Next action:      <what happens on approval / what happens on refusal>

Rules:
1. Every field is filled in. "N/A" is a valid answer; blank is not.
2. "Last checkpoint" states a real check. If nothing was verified, say so.
3. If the run touched a gated action, it stops and reports instead of proceeding.
4. Unresolved questions are listed under Proof returned, not omitted.

How to tell it is working

• You can hand a run to a different tool or a different person without a verbal briefing.
• A failed run is as informative as a successful one, because the checkpoint field says what actually broke.
• Nothing irreversible happens without your name on it, because gated actions stop at the receipt.
• Re-running work stops requiring you to reconstruct the context from memory.

Where it usually goes wrong

• The receipt becomes prose. The moment it turns into paragraphs, nobody reads it and the fields stop being comparable between runs.
• "Last checkpoint" gets filled with confidence instead of a check. If nothing was verified, the honest value is "no check run."
• The gate is written but not enforced, so a run reports approval-required and then proceeds anyway.
• The source of truth is a chat thread. Chat is where work is discussed, not where accepted state lives.