Team systems
Multi-agent handoff playbook
Switching from Grok to Claude to a local model should not reset truth. This playbook is how we move work across agents on LYGO projects without relying on “read the whole chat.”
The packet
Every handoff packet contains:
- Goal and non-goals
- Current status (green / yellow / red) with reasons
- File map (paths that matter)
- Continuum capsule or hash list
- Open questions for humans
- Next three actions only
If a packet lacks done checks, it is a diary entry, not a handoff.
Roles
| Role | Job | Champion lens |
|---|---|---|
| Builder | Change files | ARKOS / OMNIΣIREN |
| Verifier | Re-check claims | Δ9RA / ÆTHERIS |
| Integrator | Merge and release notes | SANCORA / Lightfather |
| Human owner | Consent and publish | always human |
Failure modes
- Story without files, reject the handoff.
- Files without claims, seal before switching agents.
- Claims without re-verify, verify is the first act of the new agent.
- Secret leakage, redaction pass before packet paste.
30-minute drill
- Pick a tiny task.
- Complete it with Agent A.
- Seal Continuum claims.
- Open Agent B with only the packet (no prior chat).
- Agent B must re-verify and extend work.
If B cannot proceed, the packet was incomplete, improve the template, not the mythic language.
A packet that survives a new session
The test of a handoff is simple: a competent agent with no access to the previous chat should be able to continue without guessing. If it needs the transcript, the handoff is not finished. The packet is the map; the chat is the weather.
GOAL: One sentence. What is this work supposed to achieve? NON-GOALS: Three things this handoff is not trying to do. STATUS: Green / yellow / red, with one sentence of evidence. FILES: - path, role, last verified hash or date - path, role, last verified hash or date DECISIONS: - decision, why, date CLAIMS / SEALS: - claim, check, result, date OPEN QUESTIONS: - question, who can answer it, what happens if unanswered NEXT 3 ACTIONS: 1. 2. 3. CHECK: The command, URL, or page that proves the handoff is real. OWNER: Who receives the packet and who can publish.
Worked example
Agent A has rewritten a guide. It has not published. The packet to Agent B looks like this:
GOAL: Finish the guide rewrite and hand it to the human publisher. NON-GOALS: - Do not change the site navigation. - Do not add new pages. - Do not publish. STATUS: Yellow, draft is complete, but the internal link audit has not run. FILES: - guides/example.html, the draft, modified 2026-10-18 - guides/index.html, links into the draft, unchanged DECISIONS: - Kept the existing headline. - Removed the old FAQ because it repeated the intro. CLAIMS / SEALS: - claim: page contains the new worked example check: grep for "Worked example", pass - claim: every internal link resolves check: link audit. NOT RUN OPEN QUESTIONS: - Should the old FAQ stay? Owner: human publisher. NEXT 3 ACTIONS: 1. Run the internal link audit. 2. Fix any broken link. 3. Send the diff and audit result to the human. CHECK: `link_audit.py --repo .` exits 0. OWNER: Agent B prepares; human publisher approves.
Agent B’s first three actions are not “read the whole chat.” They are: restate the goal, run the missing check, report the result. If B cannot do that from the packet, the packet is incomplete.
Status vocabulary
“Status: in progress” is not a status. Use three colors and attach evidence.
| Status | Meaning | What the packet must include | What the next agent may do |
|---|---|---|---|
| Green | The stated check passed and there is no open blocker. | The check output and the date. | Continue to the next action; still re-verify before publishing. |
| Yellow | Work is usable, but one known risk or check is outstanding. | The risk, the missing check, and the owner. | Resolve the risk first; do not call it done. |
| Red | A check failed or a decision is blocked. | The failing output and what was tried. | Stop and ask the owner; do not paper over it. |
A yellow handoff is normal. A red handoff is useful. A green handoff without a check is a story.
The file map
A file path is not enough. The map should say what each file is for and when it was last verified. “The page” is not a path. “The guide” is not a file. Write the path, the role, and the last check.
- Source of truth: the file the next agent should edit.
- Generated output: the file that must be rebuilt, not hand-edited.
- Reference: the file that explains the intent, not the file to change.
- Forbidden: the file that must not be touched in this task.
If a file is generated, say so. An agent that edits a generated file creates a change that disappears on the next build.
Claims and seals
A handoff claim has four parts: the claim, the check, the result, and the date. “The page is fixed” is not a claim. “The page returns 200 and the link audit exits 0 on 18 October” is. If you use Continuum, the capsule is the container; if you do not, a hash or a URL plus a date is enough to start.
The receiving agent should re-run at least one claim before extending the work. Re-verification is not distrust; it is how the new agent learns the shape of the task. A claim that only works in the sender’s session is a memory, not a receipt.
Human-to-agent handoff
The same packet works in both directions. A human handing work to an agent should include the goal, the files, the constraints, and the check. An agent handing work back to a human should include the diff, the check output, the open questions, and the exact decision the human needs to make.
The human keeps the publish/consent step. The packet can recommend “publish,” but it cannot grant permission. That boundary is the difference between a handoff and an automation.
The 30-minute drill, with pass/fail
- Pick a tiny task that changes one file and has one check. A one-paragraph edit is enough.
- Agent A completes it and writes the packet. No chat history is allowed in the packet.
- Seal one claim, a hash, a URL status, or a Continuum capsule.
- Open Agent B with only the packet. B must restate the goal and the next action in one sentence.
- B runs the check before changing anything. If the check fails, B reports red and stops.
- B makes one improvement and updates the packet. Compare the two packets.
| Result | What it means |
|---|---|
| B restates the goal correctly and runs the check | Pass, the packet is usable. |
| B asks for the chat history | Fail, the packet is missing context or a file path. |
| B invents a file path | Fail, the file map is ambiguous. |
| B cannot tell whether the check passed | Fail, the claim lacks a result or a date. |
| B finds a red status and stops | Pass, the handoff is honest, even though the work is blocked. |
Failure modes, with examples
| Failure | What it looks like | Fix |
|---|---|---|
| Story without files | “I updated the page and it looks good.” | Name the path, the diff, and the check. |
| Files without claims | A list of paths with no proof anything changed. | Add one claim with a check and a date. |
| Claims without re-verify | The new agent trusts “done” and builds on it. | Re-run one claim before extending. |
| Secret leakage | A token or private URL pasted into the packet. | Redact before the packet; rotate if it slipped. |
| Stale packet | The file changed after the packet was written. | Include the last verified date; re-check it. |
| Too many next actions | A list of twelve things, none prioritized. | Three actions maximum; one is better. |
| No owner | “Someone should review this.” | Name the human who can approve. |
What not to put in a packet
- The full chat transcript. Link to it if it matters; do not paste it.
- Personality notes or lore that do not change the task.
- Secrets, private URLs, customer data, or unredacted logs.
- Speculative ideas that are not decisions. Mark them as open questions or leave them out.
- Twenty next actions. The packet is a map, not a backlog.
FAQ
How is a packet different from a task brief?
A brief starts work; a packet moves work that already exists. The brief defines the job; the packet records the state, the files, the claims, and the next action.
Do I need Continuum to hand off work?
No. A hash, a URL status, or a dated screenshot can be enough. Continuum is useful when you want the claims and the checks in one capsule. The principle is the same: a claim needs a check.
Can a human be the receiving agent?
Yes. The packet is written for a competent stranger, human or machine. The human still owns the publish decision.
How often should the packet be updated?
At every handoff, and whenever a check result changes. A packet that is updated only at the end of a project is a postmortem, not a handoff.
What if the next agent disagrees with a decision?
It should record the disagreement as an open question and ask the owner. A handoff is not a command to repeat the past; it is a map of what is known.
