Agent Handoff — Patterns

A typed envelope, not a summary

Problem. When what crosses is a paragraph the sender wrote, its content varies run to run, important fields are omitted under context pressure, and no test can assert that a transfer carried what it should.

Approach. Define a schema for the transfer: the objective in the user's terms, established facts with their sources, actions already taken, commitments made, what has been tried and failed, and the reason for the move. Require every field, allow explicit empties, and validate before the receiver is started.

Trade-off. A schema cannot anticipate everything, and nuance that does not fit a field is lost just as surely as in a summary. Senders also learn to fill required fields with filler text, so field presence must be reviewed, not just field validity.

Carry a reference, not a copy

Problem. Copying the full history into the receiver's context doubles cost at every transfer and makes a third transfer unaffordable. It also duplicates sensitive material into another context with possibly different retention.

Approach. Keep the authoritative record in shared state under a stable task identifier and transfer the identifier plus a compact envelope. The receiver reads what it needs on demand, including the sender's tool results, rather than receiving everything up front.

Trade-off. The receiver must now be able to query, which adds a round trip before the first reply and requires the store to be available for the conversation to continue. It also means the receiver may simply not look, so the envelope still has to carry what matters most.

A custody token with one holder

Problem. Without an explicit owner, both agents can remain active after a transfer. Two replies reach the user, both write to the task state, and the later write wins arbitrarily.

Approach. Make custody an explicit, single-valued token on the task. Writes and user replies are permitted only by the current holder; the transfer is the atomic move of that token, and the sender's instance ends or suspends as a consequence of losing it. A receiver that declines returns the token rather than leaving it unheld.

Trade-off. It introduces a contention point and a new failure mode — a token held by an instance that has died — which needs an expiry and a reclaim path. Strict single-writer custody also forbids genuinely useful arrangements where a second agent observes and contributes without taking over.

Hop limits with a terminal destination

Problem. Each agent's instructions are locally sensible, and transfer rules written locally produce cycles: the billing agent sends to support, support sends back to billing, and the user watches the conversation grow with no progress.

Approach. Carry the hop count and the set of agents already visited in the envelope. Refuse a transfer to an agent already in the set, and when the hop limit is reached, send to a terminal destination — usually a human queue — rather than to another agent. Record every hop so cycles are visible in aggregate even when the limit catches them.

Trade-off. A legitimate return to an earlier agent, which is common once a blocking question has been answered, is forbidden by a naive visited-set rule and needs an explicit exemption. Hop limits also mask a bad transfer policy by containing it, so the recorded hop counts must actually be reviewed.