At an agent handoff, should the receiving agent get the whole conversation history?

## Why the boundary is a real decision When control passes from one peer to another, the receiving agent starts a turn with whatever context the runtime hands it. There is no shared working memory by default and no supervisor holding the thread. So "what does the next agent see?" is a design choice with user-visible consequences on both sides. Take a mobile-carrier support swarm. A customer spends 40 turns with billing: identity verified, three invoices examined, one credit applied, two hypotheses about a roaming charge tried and discarded. Billing now transfers to device repair, because the real cause looks like a faulty SIM. ## Failure mode one: too little If the repair agent starts with only the user's last message, it asks for the account number again. To the customer, the "single support experience" has just revealed itself as three bots in a trench coat. Worse, the repair agent repeats the diagnostics billing already ran, because it has no record that they were run. This is the failure users complain about, and it is the reason handoffs need an explicit payload rather than relying on the destination agent to ask. ## Failure mode two: too much Dumping the raw 40 turns has four distinct costs. **Token cost compounds.** The transcript is not paid once — it rides along on every subsequent turn of the conversation, and if a third transfer happens it grows again. Multi-agent orchestration already carries a large token premium over plain chat; unfiltered history multiplies it. **Context degradation.** Long windows measurably reduce a model's reliability at using what is in them — the effect commonly called context rot. The repair agent's actual job, diagnosing a SIM fault, competes for attention with 35 turns of invoice arithmetic. **Contamination.** The transcript contains billing's *discarded* reasoning. Models do not reliably distinguish "hypothesis the previous agent abandoned" from "established fact", so the repair agent may confidently continue chasing a roaming charge that was already ruled out. **Role bleed.** A verbatim history full of billing's persona, tone and policy statements pulls the repair agent toward behaving like a billing agent, undermining the specialization the swarm exists to provide. ## The structured handoff record Define a schema and populate it deterministically wherever you can: - **reason** — why this transfer, in the transferring agent's own words; - **identity/auth state** — verified or not, and to what level. Carry this as runtime state, never as a claim the summary makes, so the peer never re-verifies and never *skips* verification on a forged claim; - **confirmed facts** — account id, plan, device, ticket ids. Prefer values already in session state over values the model restates; - **actions taken and outcomes** — including negative results ("roaming charge ruled out"), which are the most valuable and most frequently dropped items; - **open question** — what the receiving agent is being asked to determine; - **verbatim tail** — the last two to four turns, so the user's exact phrasing and emotional register survive. Anything not in the record stays in the durable session log. Give the receiving agent a tool to fetch older turns on demand — progressive disclosure — so nothing is truly lost while the working context stays small. ## Who writes the summary Three options, in ascending trust. Let the transferring model write it as free text: cheapest, most lossy, and it will flatter its own work. Have it fill a **typed schema** as the transfer tool's arguments: better, because required fields force the omissions to be conscious ones. Or assemble it **programmatically** from session state, with the model contributing only the reason and the open question: most reliable, and the right choice for anything security- or money-adjacent. A related caution: the transfer reason is model-authored text that another model will read as instruction-shaped context. If any of it derives from user input, it is untrusted, and the same prompt-injection discipline you apply to tool results applies here — a delegated agent is a favourite injection target precisely because nobody is watching it as closely as the user-facing one. ## How you would know it is wrong Instrument it. Count re-asks — how often the receiving agent requests a fact that was already confirmed. Count repeat actions — the same diagnostic run twice in one conversation. Track post-handoff context size. Sample transcripts where the customer used the word "again". Each of these maps to a specific field missing from the record, which makes the schema improvable instead of a matter of taste. ## The honest summary There is no settled default. Systems with short conversations and cheap tokens often pass everything and are fine. Long, multi-hop, regulated conversations almost always need a curated record. State the trade-off, pick a default of "structured record plus short verbatim tail plus on-demand retrieval", and say which measurements would move you off it.