How to Hand Off State and Context Between AI Agents

A clean agent handoff is a written state packet: the goal, the decisions already made, the approaches tried and rejected, the current plan, and the single next action for the receiving agent. The sending agent writes this packet explicitly at the end of its turn, and the receiving agent reads it before doing anything else instead of re-deriving state from raw chat history.

What should a handoff packet actually contain?

Most failed handoffs fail the same way: the sending agent dumps a wall of transcript and assumes the receiver will figure out what matters. A transcript is not state. State is the distilled version a competent colleague would need to pick up the work without re-reading everything.

A handoff packet should contain exactly five things:

1. The goal, in one sentence. Not the original prompt, the current goal. Goals drift during a run; write down where things stand now.
2. Decisions made, with reasons. "We chose Postgres over SQLite because the data has to survive restarts." Without the reason, the next agent will happily re-litigate the decision.
3. Attempts and rejections. What was tried, what failed, and why it was abandoned. This is the most valuable section. It stops the receiving agent from burning tokens re-running dead ends.
4. Current plan and progress. What remains, in order, and what is already done.
5. The next action. One concrete step the receiving agent should take first. Ambiguity here is where handoffs go to die.

Keep the packet under a few hundred words. If it is longer than that, you have not distilled, you have just copied.

How does the planner/executor split change the handoff?

The most common multi-agent setup is a planner that breaks work down and executors that carry out the steps. The handoff in this pattern is directional: planner to executor, then executor back to planner with results.

The planner-to-executor handoff needs to be narrow. Give the executor the task, the constraints, and the definition of done, but not the whole plan. An executor that can see the entire plan will start improvising on parts it was never assigned, which is how you get two agents editing the same file in opposite directions.

The executor-to-planner handoff needs to be evidence-heavy. The planner does not need a narrative; it needs the outcome (done, blocked, or failed), the artifacts produced (file paths, URLs, identifiers), and anything unexpected that changes the plan. A good return packet is: result, evidence, surprises.

The rule of thumb: handoffs go down the hierarchy as instructions and come back up as evidence.

How do you stop the telephone-game degradation between agents?

Every time state passes through another agent's paraphrase, it loses fidelity. The third agent in a chain is working from a summary of a summary, and by the fifth, the original goal is a rumor. This is the telephone game, and it is the number one reason multi-agent pipelines produce confident, wrong results.

Three practices keep it in check:

Write state to a durable medium, not just the chat. If the handoff lives only in conversation history, each agent re-summarizes it through its own lens. Writing the packet to a file, a task tracker, or a shared store means every agent reads the same source of truth instead of a chain of interpretations.

Make the packet append-only with corrections, not rewrites. When an agent updates the state, it should add a new entry ("Update: the API rate limit is 60/min, not 100") rather than rewriting the whole packet. Rewrites silently drop details. Appends preserve the audit trail, and the newest entry wins when there is a conflict.

Keep chains short. If your pipeline needs more than three handoffs to complete a task, the task is probably decomposed wrong. Fewer hops means fewer chances for drift. When a long chain is unavoidable, have the final agent re-verify the goal against the original packet, not against the last handoff.

How do you verify the receiving agent actually loaded the state?

Writing a great packet means nothing if the receiving agent skims it and starts from scratch anyway. Build verification into the protocol:

1. Require a read-back. The first thing the receiving agent does is restate the goal, the next action, and any hard constraints in its own words. If the read-back is wrong, the handoff failed before any work started, which is the cheapest possible time to catch it.
2. Check the rejections list. Ask the receiving agent to name one approach that was already tried and rejected. If it cannot, it did not read the packet.
3. Spot-check the evidence. If the packet references artifacts (files, URLs, IDs), the receiving agent should confirm at least one exists before proceeding. A surprising number of handoff failures are just broken paths nobody checked.

This takes thirty seconds and catches the majority of silent handoff failures.

The handoff checklist

Run through this every time state moves between agents:

1. Write the goal in one current sentence.
2. List decisions with their reasons.
3. List tried-and-rejected approaches with why they failed.
4. State the remaining plan and what is done.
5. Name the single next action.
6. Write the packet to a durable medium, not just chat.
7. Append updates; never silently rewrite.
8. Keep the chain to three hops or fewer.
9. Require a read-back from the receiving agent.
10. Spot-check one referenced artifact before work begins.

One practical way to simplify all of this is a shared state layer both agents read and write instead of a file you pass around. Vilix AI is one option here: every connected agent reads and writes the same memory over MCP, so the handoff is just both agents looking at the same state. The honest tradeoff is that it is cloud-hosted, so if your setup requires everything to stay local, it is not the right fit.

What breaks most often in practice?

Three failure modes account for almost everything: the packet is a transcript dump instead of distilled state, the receiving agent never confirms what it loaded, and the chain is too long for anyone to notice the drift. Fix those three and most multi-agent setups go from flaky to boring, which is exactly what you want from infrastructure.