Pattern Matrix/White Paper/C4

C4 · Handoff Chain

Coordinate Collaboration × Chain (pass)
Cost Medium (each handoff adds one LLM call)
Pattern group Collaboration patterns
Summary Split a long process into N agents with clearly scoped responsibilities. After one agent finishes its leg, it passes the critical state to the next through a structured HandoffPacket (not raw text), and each agent is good at only one thing.

What problem it solves

When multi-agent systems fail, it is often not because any single agent is too weak, but because the handoff dropped the baton. A front-line agent holds all of the customer's information; when it transfers to the second tier, it passes only "the verbatim text of the customer's last sentence." The second tier picks up like a colleague who just walked in—with no idea who the customer is, why they are upset, or what has already been said—and so it asks again.

The Handoff Chain addresses the problem of passing a task sequentially across multiple agents so that each handoff loses no information, assigns clear responsibility, and remains traceable on failure. Its design center sits in a naming judgment: handoff is "handing over," not "relay." A relay is an action (running); a handoff is a state (a shift change). What truly passes between agents is not the act of running but the state the previous leg completed, and that state must be made explicitly schema-driven so it does not get lost. Human call centers solved this 30 years ago, calling it a warm handoff: a few seconds before the transfer, the outgoing agent briefs the incoming agent on the situation, then routes the call over.

Why the coordinate is "Collaboration × Chain"

  • Vertical axis · Collaboration: the output of one agent is the input of the next—relay-style multi-agent collaboration. Each leg is a peer with a clearly scoped responsibility, with no supervisor as a stable anchor—this is its biggest difference from Hierarchical Delegation.
  • Horizontal axis · Chain: N agents pass strictly in sequence, neither in parallel nor in a loop. This differs from Fan-Out/Aggregate, where N workers run at the same time, and from Adversarial Review, where there is back-and-forth debate. Order sensitivity is its defining trait.

Core mechanism

A single handoff keeps the baton from dropping through three things:

  1. Responsibility splitting: the long process is split into N agents with clearly scoped responsibilities, where each leg is good at only one thing and need not understand the whole process.
  2. Structured packaging: when the previous leg finishes, it packages the critical state into a HandoffPacket and passes it to the next leg—not a dump of conversation history, but a schema-driven structure. This is its biggest difference from a single agent chaining multiple prompts: in the latter, context carries forward naturally, whereas a Handoff Chain spans agents and sessions, so state must be made explicitly schema-driven.
  3. Controlled handover: before the handoff, a permission gate judges whether this handoff is reasonable; a chain-length cap prevents endless passing; and each handoff writes to an audit log.

A HandoffPacket should carry at least a five-layer schema:

Layer Content
Goal the customer's fundamental need + the specific problem still unresolved
Artifacts completed outputs (KBs checked, scripts run, tickets copied)
Decisions decisions including what / why / evidence—the layer most easily lost
Rejected Paths directions already tried and failed, which the next leg should not repeat
Next Required the explicit next action, with no "use your judgment" allowed

Production scenarios it fits

  • Tiered customer support: L1 triage, L2 technical, L3 engineering, Director escalation, where the model grows stronger, tool permissions open up, and the SLA escalates tier by tier.
  • Approval workflows with professional division of labor: in healthcare, triage nurse to general practitioner to specialist to chief; in law, paralegal to associate to partner; in sales, SDR to AE to CSM to VP.
  • Handing control back from an execution-type agent: when an agent finishes its own responsibility and needs to return control to a higher layer (see the enterprise example for one case).

Four conditions must hold at once: clear professional division of labor, a definable order, structurable state, and an SLA escalation mechanism that is central to the business.

Where it tends to go wrong

  • Cold transfer: only "the user's last sentence" is passed to the next leg, which receives none of the preceding context. The signal to watch for is the customer being asked questions they have already answered immediately after the handoff, with the shift in mood from calm to frustrated coinciding with the handoff point. The fix is that the HandoffPacket must contain at least the five-layer schema.
  • Loss of decision provenance: the Artifacts all get passed along, but the why behind the decisions does not—so the next leg sees a pile of outputs without knowing on what basis the predecessor took that path, and so reruns the process or overturns the predecessor's decisions. "Artifacts survive handoff, decisions don't," unless decisions are given a dedicated schema field.
  • Oscillation loop: the same pair of agents hands back and forth repeatedly; L2 thinks L1 should handle it and kicks it back, L1 kicks it back again, and after 8 hops it is still in place. The fix is to set a hard chain-length cap (3-4 legs, beyond which it forcibly escalates to a human), explicitly constrain can_handoff_to (L2 cannot hand back to L1), and record a visited set.
  • Over-handoff: by default an LLM tends to over-hand off, wanting to kick anything slightly difficult to the next agent. You can add a classifier before the handoff to examine "is this handoff reasonable, or should I finish it myself."
  • Misuse on short tasks or without clear roles: for tasks that take 30 seconds overall, for "general assistant" scenarios that are essentially single-agent, and for real-time conversations sensitive to latency, the cost of handoff becomes a burden instead. Scenarios with high loop risk should use Hierarchical Delegation, letting the supervisor be the anchor.

Key metrics

  • Chain length in hops (healthy zone ≤ 4): the number of handoffs a single chain passes through. Beyond 4 hops it should forcibly escalate to a human; this is the key line of defense against an oscillation loop running out of control.
  • Post-handoff repeat-question rate (healthy zone near 0): the proportion of customers asked questions they have already answered after a handoff. This is the most direct symptom of a cold transfer.
  • Decision retention rate (healthy zone high): the proportion of the previous leg's decisions passed intact to the next leg. A low value indicates the HandoffPacket has degenerated into a raw history dump.
  • SLA attainment rate (accounted by tier): the proportion of agents at each tier completing within their SLA window, combined with sentiment carry over to monitor changes in customer mood along the escalation path.

Minimal implementation skeleton

HandoffChain.execute(request, initial_agent, max_hops=4):
                current, prev_packet = initial_agent, None
                for sequence in 1..max_hops:
                    output = run_agent(current, prev_packet)   # input is a structured packet, not raw history
                    packet = build_packet(prev_packet, output) # cumulatively inherit artifacts/decisions/rejected
                    audit(packet)
                    if output.complete: return result
                    next = output.handoff_to
                    if next not in current.can_handoff_to:      # permission gate: prevent skipping tiers + prevent oscillation
                        return escalate_to_human()
                    prev_packet, current = packet, next
                return escalate_to_human()                      # exceeding max_hops escalates to a human

            HandoffPacket: five-layer schema (Goal / Artifacts / Decisions / Rejected Paths / Next Required)
            

Four engineering points: each leg's system prompt and tool permissions are strictly tiered (the front line cannot be given refund authority); can_handoff_to explicitly lists the permitted next legs; max_hops is set to 3-4, beyond which it forcibly escalates to a human; and the audit log satisfies compliance recordkeeping for cross-leg data flow.

Enterprise example

A mid-sized SaaS company used LangGraph to deploy a four-tier L1/L2/L3/Director customer support agent. It went live in June and was cut in October, triggered by a screenshot that had been forwarded 18,000 times: a customer said "the webhook isn't receiving events, 20,000 orders are stuck," the front line transferred to the second tier, and the second tier opened by asking again "what problem are you running into" and "what is your account email," to which the customer replied "I just said that" and "it's already above." The root-cause analysis concluded: in the four-tier architecture, every handoff point opens a fresh session, and the previous leg passes only the verbatim text of the customer's last sentence. This was not a technical bug; it was a design choice, made on the original belief that "the next one doesn't need to see what the previous one handled, it saves tokens." The fix was to package a five-layer HandoffPacket at each handoff: customer need, KBs already checked and scripts already run, decisions made including the why, directions already ruled out, and the next action—combined with model tiering (Haiku on the front line for volume, Opus in the engineering layer for complex cases), progressive tool permissions (read-only on the front line, only the Director able to approve refunds), and a chain-length cap of 4 legs, beyond which it escalates to a human. Another landing worth citing is handing control back from an execution-type agent: when a ReAct agent judges the current decision type to be plan (or when a Skill contract stipulates PlanExecute), it does not execute downward itself but uses a handoff to return control to the orchestrator, which decides the subsequent orchestration—applying the Handoff Chain to control-flow handover inside the agent, not only to user-facing tiered support.

Relationship to other patterns

  • Prompt Chaining (Action module): a same-origin dual. Prompt Chaining is a single agent chaining multiple prompts (context carries forward naturally); the Handoff Chain is multiple agents passing explicit state across sessions (which must be made schema-driven). The key difference is whether context needs to be made explicitly schema-driven.
  • Hierarchical Delegation (C1): the Handoff Chain has no supervisor and every leg is a peer, whereas Hierarchical Delegation has a supervisor as a stable anchor. When loop risk is high, returning to Hierarchical Delegation and letting the supervisor be the anchor is more stable.
  • Fan-Out/Aggregate (C2): the Handoff Chain has N agents working in sequence, whereas Fan-Out has N workers working at the same time.
  • Sub-Agent Isolation (C5): the Handoff Chain focuses on explicit state passing across legs, while Sub-Agent Isolation focuses on the context boundary of a sub-agent; their concerns differ, but both bear on the design of information flow between agents.

What this pattern teaches

The engineering essence of the Handoff Chain is not data passing but turning a human organizational process that has existed in enterprises for 30 years into an engineering structure that agents can execute—it wins where all five schema layers are engineered, and it loses where one only dumps conversation history and pretends that counts as a handoff.


This page is part of the ADPS pattern white papers. Back to the pattern matrix, or see the runnable code catalog.