Agent Handoff

What it is

Moving a task or conversation that is already under way from one agent to another, along with whatever the receiver needs to continue: the relevant history, the facts established so far, the user's actual objective, any commitments already made on the product's behalf, and the reason the move is happening. It is a transfer of custody with a payload attached.

Why it matters

The difficult part is the payload, not the switch. Everything the first agent learned — that the customer has already restarted the device, that the order number is known, that a refund was promised — exists inside its context and is lost unless deliberately packaged and carried across. Users experience a lossy transfer as being asked to repeat themselves, which is the most reliable way to destroy confidence in an assistant. Internally, the receiver redoes work that was already done or contradicts a commitment the product has already given.

Transfer, selection, and escalation

Selecting which agent gets a new piece of work happens before anything has been accumulated, so there is nothing to carry. A transfer moves work in flight and is defined by what moves with it. Escalation is one shape of transfer — upward, usually toward a human or an agent with greater authority — and the general case includes lateral moves to a peer with different tools and returns back to a previous owner, which have different payload and permission consequences.

Key decisions

• What crosses: the full transcript, a summary, a structured state object, or a reference the receiver can query for detail on demand.
• Whether custody moves permanently or the receiver returns control when finished, which determines who owns the user next and who is accountable for the outcome.
• Who initiates: the sending agent, a supervisor, a deterministic rule, or the user asking for someone else.
• What the user sees — a silent switch, an announced one, or a confirmation — and whether the receiver re-greets or continues mid-thread.
• Whether commitments made by the sender bind the receiver, and in what representation they travel so the receiver can see them at all.
• Whether a receiver may decline, and where the work goes if it does.

Failure modes

• The summary preserves conclusions and discards the evidence behind them; the receiver cannot verify anything and re-asks the user questions already answered.
• The receiver opens with a greeting as though the conversation were new, and the user recounts the entire problem a second time.
• A promise made by the sender is nowhere in the payload, the receiver refuses it, and the product contradicts itself to the user — the most damaging outcome in this capability.
• Transfers cycle: the first agent sends to the second, the second's rules send it back, and each pass appends more context to an already-growing payload.
• Both agents remain active after the transfer and the user receives interleaved replies from two personas.
• Tool permissions move implicitly, so the receiver either inherits a scope it should not have or silently loses one the task depends on.
• Only user-visible messages are carried, so the receiver cannot see the tool results on which the sender's statements were based and has no way to reconstruct them.
• The payload is assembled by a model, so its content varies between runs and nothing about the transfer can be tested deterministically.

Related capabilities

• Agent Routing — the selection made before work begins, not during it
• Multi-agent Orchestration — the scheme that decides when transfers are permitted
• Shared State Management — lets a payload be a reference instead of a copy
• Agent Lifecycle — the sender's instance must reach a defined state after handing over
• Autonomy Levels — the receiver's permission envelope may differ from the sender's

Applies: Production readiness · Design questions