Agent-to-agent handoffs without the game of telephone

You have seen this failure. A research agent spends twenty minutes digging through docs, finds the answer, writes it up beautifully, and hands it to a second agent that is supposed to implement it. The second agent promptly implements something else entirely. Not because it is stupid, but because what it received was a game of telephone: a summary of a summary, each retelling a little more wrong.

Multi-agent setups live or die on handoffs. Here is how to make them reliable.

The core problem: context is not portable by default

An agent's working state is mostly implicit. It lives in the conversation: half-formed hypotheses, things it tried and quietly abandoned, constraints it noticed three messages ago. When you hand off to another agent, all of that implicit state has to become explicit, or it is lost.

The classic mistake is forwarding the transcript. A 40-message conversation is not a handoff; it is a homework assignment. The receiving agent will skim it, anchor on the wrong details, and confidently proceed in the wrong direction. You need to distill, not forward.

Build a handoff card, not a handoff dump

Think of it like a patient chart in a hospital. When shifts change, the outgoing nurse does not hand over a transcript of everything the patient said. They hand over a chart: current status, medications, what was already tried, what to watch for. Your agents need the same thing.

A solid handoff card has five fields:

• Current objective — one sentence, as it stands right now, not as it was originally phrased.
• Decisions with reasons — "chose library X because Y." The reason matters more than the choice; without it the next agent re-opens settled questions.
• Dead ends — everything tried and rejected, with the failure reason. This is the highest-value section. It is the difference between a fresh agent and a fresh agent that repeats an hour of wasted work.
• Progress and remaining work — done versus todo, in order.
• First action — the one concrete step the receiver takes next. If you cannot name it, the handoff is not ready.

Aim for a few hundred words max. Brevity is a feature: a short card gets read, a long one gets skimmed.

Direction matters: instructions down, evidence up

In a typical researcher/writer or planner/executor split, handoffs flow both ways but carry different cargo.

Downward (planner to executor): keep it narrow. Task, constraints, definition of done. Do not hand the executor the whole master plan; agents with too much context improvise, and improvisation in a sub-agent is how you get two agents overwriting each other's work.

Upward (executor to planner): keep it evidential. Result (done / blocked / failed), the artifacts produced with real paths or identifiers, and anything surprising that should change the plan. No narrative needed.

Fighting drift across long chains

Each hop in an agent chain is a chance for meaning to decay. The fix is structural:

1. Persist the card somewhere both agents can see. A file, a task tracker, a shared store. Anything beats "it is in the chat history somewhere," because chat history gets re-summarized through each agent's lens.
2. Append, don't rewrite. New information goes on as a dated entry. Rewriting the whole card is how details vanish silently; appending keeps an audit trail where the latest entry wins.
3. Shorten the chain. More than three handoffs for one task usually means the decomposition is wrong. When long chains are unavoidable, have the last agent verify its understanding against the original card, not the most recent handoff.

The 30-second verification ritual

Before the receiving agent touches anything, make it do two things: restate the objective and the first action in its own words, and name one dead end from the card. If it cannot do both, the handoff failed and you caught it at the cheapest possible moment. Also have it confirm one referenced artifact actually exists. Broken paths in handoff cards are embarrassingly common.

When the card is not enough

Sometimes the state is too big or too fluid for a card, for example when agents run on different schedules and the state keeps changing between runs. In that case you want a shared layer both agents read from and write to, so there is no "passing" at all, just one current state everyone sees.

Vilix AI works this way: agents connected over MCP share one memory, so the handoff is implicit. The tradeoff is that it is cloud-hosted, which rules it out if your threat model demands everything local.

The takeaway

Reliable handoffs are a writing discipline, not a tooling problem. Distill state into a short card, pass instructions down and evidence up, persist the card outside chat, append instead of rewriting, keep chains short, and verify with a read-back. Do that and the telephone game stops.