Agent Handoffs: How to Pass Work Without Losing Context

🚪 Why handoffs are where reliability actually breaks

Agent handoffs look simple from the outside. One agent finishes part of the work, another picks it up, and the task continues. But in production, this is one of the most failure-prone boundaries in an agent system. The problem is rarely routing alone. The real issue is transfer quality. If the next agent receives a vague summary or a bloated transcript, it has to reconstruct intent, constraints, and progress from messy evidence. That reconstruction is where mistakes begin.

This matters because downstream errors often get blamed on the specialist agent when the specialist never had the right state to begin with. A billing agent that ignores a refund window may not be reasoning badly. It may simply never have been told the refund window. A debugger agent that repeats the same shell command may not be confused. It may have received a handoff with no record of failed attempts. In both cases, the visible failure happens later, but the system broke earlier.

The better framing is to treat a handoff as a contract. The sender is responsible for declaring what matters, what has already happened, and what the receiver now owns. This fits how current LLM agent architecture is evolving. OpenAI’s Agents SDK exposes explicit handoffs and allows developers to shape what the next agent sees through structured metadata and filtered history, rather than blindly forwarding everything. That is an important shift because it moves handoffs out of prompt folklore and into system design. You can read the underlying primitives in the handoffs documentation and the broader agent runtime docs.

Why this matters in practice is subtle but important. Most multi-agent systems are judged by the final answer, yet the final answer is often determined by whether the intermediate transfers were faithful. Teams tend to over-invest in role prompts, tool choice, and agent orchestration, then under-invest in the transfer format between agents. That imbalance creates fragile systems. The handoff boundary is where user intent gets compressed, business rules get dropped, and ownership becomes ambiguous. If you strengthen only one part of a multi-agent workflow, strengthening the handoff often gives the highest reliability gain.

🧠 The core idea: a handoff is a compact working set

The receiving agent does not need the entire conversation. It needs the smallest set of context that preserves correctness. That sounds obvious, but many systems still pass along “the conversation so far” as if more tokens automatically mean more continuity. In practice, extra history often makes continuity worse. The next agent must sift through old deliberation, duplicate tool output, and stale branches before it can act. That raises cost, increases latency, and creates more room for the model to anchor on the wrong detail.

A more reliable model is to define a handoff contract with six required fields: intent, constraints, status, evidence, next action, and stop condition. These are not abstract categories. Intent tells the next agent what user outcome matters now. Constraints carry the rules that cannot be dropped, such as policy limits, auth scope, or formatting requirements. Status explains what is complete and what is pending. Evidence preserves only the tool outputs or artifacts worth trusting. Next action creates ownership. Stop condition defines what counts as done.

This is aligned with a broader context engineering principle described by Anthropic: context is finite, so the goal is not maximum transcript size but maximum token utility. A curated working set beats a raw replay almost every time because it reduces inference load at the exact moment the system needs a clean decision. Anthropic’s discussion of effective context engineering makes the same point from a different angle. Good handoffs are less about memory and more about selective continuity.

It helps to think of a handoff as the agent equivalent of a function signature plus local state. A function does not need your whole program history. It needs the inputs relevant to the next computation. The same idea applies here. If a planner in an agent loop has already explored five branches and ruled out four, the debugger does not need every exploratory step. It needs the current hypothesis, the rejected paths that should not be retried, the evidence supporting the current direction, and the boundary of its responsibility. Once you see handoffs as working sets rather than archives, the design becomes much clearer.

📦 What should actually be inside the handoff contract

A useful payload has to separate fields by purpose, not just collect whatever seems relevant. A practical shape is: task ID, user goal, inferred intent, hard constraints, soft preferences, completion status, completed steps, attempted tools, important tool results, unresolved questions, next action, stop condition, and artifact references. Each field exists because it solves a distinct failure mode. Completed steps prevent duplicate work. Attempted tools prevent wasteful retries. Important tool results preserve the small number of outputs that truly affect the next decision.

Hard constraints deserve special attention because they are the first thing to disappear when teams rely on inherited transcript history. If a triage agent discovered that identity verification succeeded, that fact should not live only in assistant prose. If the system knows refund policy is thirty days, that should not be buried in a past prompt. These are durable operational facts. They need to survive every transfer boundary.

Artifacts should often be references rather than inline blobs. Instead of handing over a full search result set, pass a short summary plus document IDs, file paths, record IDs, or tool-result handles. That “summary plus provenance” pattern matters because it keeps the hot path small while preserving drill-down capability. LangGraph’s state-first view and LangChain Deep Agents’ context isolation patterns support this style well because they encourage shared state and external artifact storage over transcript dependence. See LangGraph’s state-oriented guidance and Deep Agents overview for concrete examples of that design instinct.

The reason to be explicit at this level is long-term system health. When the handoff shape is stable, you can validate it, log it, diff it across runs, and test whether critical fields were preserved. If the payload is just free-form prose, every improvement becomes subjective. You cannot easily tell whether one incident came from a missing constraint, a dropped artifact, or a weak summary. A compact schema does not remove model judgment, but it gives your workflow a dependable skeleton. That is what makes debugging and iteration tractable instead of anecdotal.

🧭 Keep three channels separate or debugging becomes guesswork

One of the most useful implementation rules is to separate three channels that developers often mix together. First is application state. This is for durable facts your app already knows, such as tenant ID, auth scope, policy bundle, customer record, permissions, or workflow checkpoint. Second is handoff payload metadata. This is for small structured information about the transfer itself, such as reason, priority, or escalation type. Third is filtered history. This is only the minimal transcript the next agent should see.

OpenAI’s agent framework makes this distinction explicit. Application-owned data belongs in RunContextWrapper.context . Model-generated transfer metadata can be shaped with input_type . Transcript inheritance can be controlled with input_filter . That separation is not just elegant architecture. It is how you preserve accountability. If a specialist ignores a policy, you need to know whether the policy was missing from state, omitted from the handoff payload, or present but not followed by the model. When everything is stuffed into messages, that diagnosis becomes impossible. The relevant mechanics are documented in OpenAI’s pages on context and handoffs.

Why this matters in real systems is simple: reliability work starts after the failure. If your data flow is blurry, every incident turns into speculation. Teams end up debating prompts when the real issue was state propagation. Clean channel boundaries turn handoff bugs into observable engineering problems instead of mysterious model behavior.

A concrete example makes the distinction easier to hold. Suppose a support agent escalates to a compliance specialist. The user’s region and account tier belong in application state because the app already knows them and they may affect policy. The fact that this is an escalation due to a refund exception belongs in handoff metadata because it explains why the transfer happened. A single prior user message clarifying urgency may belong in filtered history because the wording itself matters. If those three things are mixed into one summary paragraph, you lose the ability to reason about what was known, what was inferred, and what was merely conversational.

📉 Why transcript-first handoffs cause duplicated work

Passing the raw transcript feels safe because it seems like nothing can be lost. In reality, this is often the design smell at the heart of multi-agent inconsistency. The receiving agent sees all prior messages, but it does not automatically inherit a clean model of progress. It still has to infer what is complete, what failed, what is tentative, and what the current ownership boundary is. That inference is error-prone, especially when the transcript contains tool chatter, abandoned reasoning branches, and repeated user restatements.

The most common symptom is re-triage. A worker agent receives a full conversation and starts planning from scratch instead of executing. It runs search again, re-checks the same APIs, or asks the user a question that was already answered. Not because the model is incapable, but because the handoff never declared a status ledger. Fields like completed_steps , attempted_tools , known_failures , and open_questions are what stop that loop. This is especially important for tool calling agents, where duplicate API calls and repeated tool usage quickly turn into wasted cost and weaker agent reliability.

OpenAI’s handoff docs also highlight an important caveat here. The receiving agent normally sees inherited history unless you filter it, and built-in filters like remove_all_tools only remove structured tool items. They do not remove tool outputs that were already copied into regular assistant messages or summaries. So item deletion is not enough. You need semantic filtering. If a planner previously wrote, “Searched Jira and found ticket ABC-123 blocked by missing OAuth scope,” that sentence can still leak forward even if tool records are stripped. This is why handoff quality is not just about trimming tokens. It is about deliberate reconstruction of the right working set.

There is also a cost dimension that matters more than it first appears. Repeated work is not just slower. It compounds uncertainty. Every extra search, API call, or shell command creates new evidence that may partially conflict with old evidence, especially in changing systems. Then the receiving agent has to reconcile both. A bad handoff therefore does two kinds of damage at once: it wastes tokens and tools, and it muddies the factual state of the task. The result is a workflow that feels inconsistent even when each individual model call seems reasonable.

⚠️ Constraints drift more easily than most teams expect

Constraint loss is one of the quietest failure modes in agent systems because the transfer often looks successful. The next agent receives something, continues the task, and even sounds confident. But safety rules, formatting requirements, or policy boundaries may already have disappeared. That is especially important when developers rely on inherited history across runs and assume instructions persist automatically.

In OpenAI’s Responses API, previous instructions are not automatically carried forward simply because you continue from a previous response identifier. If you depend on previous_response_id without restating critical constraints or storing them in durable state, a downstream specialist can drift. The result is subtle. The agent may still complete the task, but it stops following compliance language, output structure, or policy checks that the earlier agent enforced. The relevant API behavior is documented in the Responses API reference.

This matters because many production teams interpret drift as model inconsistency when it is actually state design failure. If refund eligibility, auth scope, or tenant-specific policy must survive every downstream call, they belong in durable app state and should be projected explicitly into each handoff. Summaries can remind the model. They cannot serve as the source of truth for business rules. That distinction between context and state is easy to skip in prototypes and painful to rediscover in production.

A useful rule is to classify every important fact as either durable or situational. Durable facts are the ones your system must preserve no matter which agent acts next. Situational facts are only helpful for the immediate decision. Refund windows, permission scopes, customer verification status, and required output format are durable. A temporary hypothesis about why an error might be happening is situational. Durable facts should be stored and re-injected. Situational facts can be summarized and dropped when they stop mattering. Making that distinction early prevents a surprising amount of downstream drift.

🧪 A concrete example: triage to refunds specialist

Consider a customer support workflow. A triage agent receives a complaint about a duplicate charge. It verifies identity, checks the order record, reads billing logs, and decides the issue should move to a refunds specialist. A weak handoff says, “User has a billing issue. Please help.” That sounds plausible, but it forces the specialist to reconstruct the case from scratch. Was the user verified? Which order is affected? Is the charge duplicated or merely pending? Which tools were already queried? What exact decision is now required?

A better handoff passes a compact contract. The user goal is a refund for a duplicate charge. Hard constraints include the refund window and identity verification status. Completed steps list the order lookup and payment log check. Attempted tools name the orders and billing APIs. Important tool results record that the charge appears duplicated and attach the order ID. Unresolved questions ask whether the second charge settled. Next action tells the specialist to decide eligibility and draft the response. Stop condition says approved or denied with reason.

That structure changes behavior in a very practical way. The specialist can start at the real decision boundary instead of repeating discovery work. It also gives observability. If the specialist denies the refund because it claims identity is unverified, you now know the issue is either dropped state or model non-compliance, not vague “AI weirdness.” This mirrors the specialist routing scenarios described in OpenAI’s handoff examples, but the important lesson is broader: ownership only transfers cleanly when status and constraints transfer with it.

Notice what the specialist does not need. It does not need the entire wording of every prior support exchange, every line of billing log output, or the triage agent’s full reasoning path. Those details may be useful later for audit or appeal, but they do not belong in the hot path unless they directly affect the next decision. This is where many systems over-share. They optimize for the feeling of completeness instead of the reality of decision quality. A compact contract respects the specialist’s role and shortens the path from transfer to action.

💻 Another example: planner to debugger in coding agents

Coding agents make the same mistake in a louder way. A planner agent explores a repository, runs commands, inspects files, and then hands the task to a debugger or fixer agent. If it forwards the full shell transcript, the receiving agent inherits a mountain of low-signal tokens: command output, package install logs, repeated stack traces, and dead-end hypotheses. That feels comprehensive, but it slows down the next decision and often causes the debugger to re-run work that already failed.

A stronger handoff is much tighter. Pass the current repository path, failing command, short error excerpt, files already inspected, rejected hypotheses, and one bounded objective such as “find why test_auth.py fails after token refresh and propose the minimal patch.” If there are useful artifacts, pass file paths or result handles instead of pasting the entire command history. This follows the same context engineering rule that Anthropic applies to tools: return only high-signal information and paginate or truncate large outputs with sensible defaults. Their article on writing tools for agents is really a handoff lesson in disguise.

Why this matters is not just token efficiency. It protects role clarity. The planner should own exploration and decomposition. The debugger should own diagnosis inside a defined boundary. If the debugger receives the whole transcript with no ownership line, it often starts planning again. Multi-agent performance then collapses under coordination overhead, not because specialization was a bad idea, but because the transfer never created a clean work boundary.

From a developer perspective, AI coding agents reveal handoff flaws quickly because repetition is expensive and easy to spot. If the debugger reruns the same test three times, opens the same file again, or revisits a rejected hypothesis, the waste is visible. In customer support or research workflows, the same waste can hide behind fluent language. That is why coding agents are a useful mental model even if your product is not a coding product. They make context problems concrete. A bad handoff is simply duplicate work with nicer wording.

🧠 Handoffs, memory, and state are not the same thing

Teams often blur agent handoffs with AI agent memory, but they solve different problems. A handoff moves a bounded working set between agents. Memory preserves facts across steps, runs, or sessions. State management decides where those facts live and how they are updated. If you merge all three into a transcript, the system becomes harder to reason about and much easier to break.

This is where short-term vs long-term memory in agents becomes useful. Short-term memory is the working context needed for the current decision. Long-term memory is what should survive beyond the immediate task, such as user preferences, validated constraints, prior outcomes, or procedural memory for agents. Handoffs should usually carry short-term working context plus references to long-term stores, not become the long-term store themselves.

That distinction matters even more for long-running agents. Over time, raw history grows, summaries drift, and stale assumptions accumulate. If durable facts are kept in explicit stores and projected into each handoff, the workflow stays stable even as the agent loop runs for longer periods. This is one reason state-first designs such as LangGraph memory are appealing. They make agent state management visible instead of hiding it inside message history.

In practice, the cleanest model is simple. Keep durable facts in application state or external memory. Keep the handoff focused on what the next agent must know now. Keep history narrow and intentional. Once those roles are separated, debugging becomes easier because you can tell whether the failure came from missing memory, bad transfer design, or weak execution.

🔒 Privacy, isolation, and the limits of inherited history

There is also a production concern that gets overlooked when teams focus only on convenience: inherited history weakens isolation. If a specialist agent should not see previous logs, sensitive tool results, or irrelevant customer details, conversation carryover can become a liability. OpenAI’s docs note that server-managed conversation features like conversation identifiers and automatic previous-response chaining limit the normal handoff filtering options when you need stronger separation. In those cases, the recommended pattern is to start a fresh run with explicitly selected input rather than reuse the original server-managed history.

This matters because nested history is a compaction feature, not a security feature. A summarized transcript may still contain sensitive details that were copied into assistant prose. Tool arguments or outputs can survive inside nested summaries even after tool items are stripped. So if a billing specialist should never see debugging logs or personally sensitive content from another branch, compaction is not enough. Sanitization and fresh payload construction are the real controls.

The broader lesson is that handoffs define privacy boundaries as much as task boundaries. Once you see them that way, transcript inheritance stops looking harmless. It becomes an architectural decision about least privilege. That is why context filtering should be deliberate, explicit, and auditable rather than treated as a convenience layer.

Why this matters operationally is that privacy mistakes are harder to roll back than logic mistakes. If an agent gets the wrong instruction, you can usually retry. If it receives data it was never supposed to see, the failure already happened at the moment of transfer. That shifts the design goal. You are not merely trying to make the next agent effective. You are trying to make it effective with the minimum necessary visibility. Good handoff design therefore supports both reliability and compliance, which is a rare case where the safer design is also usually the simpler one.

📊 How to observe and evaluate handoff quality

If handoffs are a first-class systems boundary, they need first-class observability. Log each transfer as its own event or span with fields like from-agent, to-agent, reason, payload size in tokens, filtered item count, artifact references, and a hash of the active constraints. This gives you a concrete way to answer a question that shows up in almost every incident review: did the receiving agent ignore the rule, or did the runtime fail to pass it?

Good evaluation is also possible here. You can score handoffs on completeness, constraint retention, redundant tool-call rate after transfer, context size before and after filtering, artifact reuse rate, and task completion without upstream rework. These are practical metrics because they connect directly to the user-visible failure modes teams already care about: repeated questions, duplicated API calls, policy drift, and slow specialist execution. Anthropic’s guidance on agent evals reinforces the idea that multi-turn workflows should be judged at the system level, not just by single prompt outputs.

This is where a handoff contract becomes more than a design preference. It becomes measurable. If your contract says every transfer must preserve intent, constraints, status, evidence, next action, and stop condition, you can test whether each field survived. Once you can test it, you can improve it. That is the real step from demo orchestration to production-grade agent engineering.

A practical evaluation loop might look like this. Sample real transfers, inspect whether the receiving agent repeated prior work, and trace the cause back to missing fields or noisy context. Then update the contract or filter and run the same scenarios again. Over time, you should see fewer redundant tool calls, shorter time-to-first-correct-action, and fewer downstream corrections. Those are not abstract research metrics. They are signs that your workflow is becoming easier to trust. In production, trust usually grows from observability before it grows from sophistication.

🛠️ A practical implementation pattern developers can use now

The most reliable pattern in practice is hybrid: pass compact machine-readable state plus a short human-readable narrative. The structured part gives deterministic fields for orchestration, logging, and validation. The narrative helps the model preserve nuance that schemas alone may flatten. Neither is enough by itself. Transcript-only handoffs are too noisy. Schema-only handoffs are often too brittle. The combination works because it serves both the runtime and the model.

At the same time, treat summaries as lossy aids, not truth stores. Durable business facts belong in application state or external systems, then get projected into each handoff as needed. If another store is already the source of truth for permissions, balances, or customer records, retrieve from that store instead of inventing a second memory hidden in assistant prose. That principle shows up across modern agent frameworks because it reflects an operational reality: summaries drift, state stores do not.

This pattern fits well with Responses API agents, the OpenAI Agents SDK, and other stateful orchestration layers. It also maps cleanly onto supervisor worker agents in larger multi-agent systems, where a supervisor can keep durable state and assign bounded work to specialists. The same idea supports durable execution for agents because each transfer becomes a checkpoint with explicit state, clear ownership, and recoverable intent.

The deeper lesson is simple. Multi-agent systems usually do not fail because the router chose the wrong specialist. They fail because the transfer boundary was underspecified. Once you stop treating handoffs as transcript dumps and start treating them as contracts, you get cleaner ownership, lower cost, better privacy, stronger agent observability, and far easier debugging. In other words, better handoffs do not just preserve context. They preserve system integrity.

If you need a starting point, keep the implementation modest. Store durable facts in app state. Define a small handoff schema with the six core fields. Attach artifact references instead of large blobs. Filter inherited history aggressively, then add back only the pieces the receiving agent genuinely needs. Finally, log every transfer so you can inspect failures later. That workflow is not glamorous, but it is the kind of design that ages well. Agent systems become easier to scale when each transfer is intentional, bounded, and testable.