← All articles

Four hops, four packets: what each agent handoff must carry

The Guildwise HQ team · 31 October 2026 · 6 min read

• AI agents
• How-to

Most multi-agent work does not fail inside one agent. It fails at the seam between two of them. A builder receives a half-stated requirement, a reviewer approves a diff without knowing which claims were tested, or a tester checks the wrong thing because nobody said what changed.

This article looks at the handoff itself. It proposes a fixed packet for each hop between an analyst, a builder, a reviewer and a tester, and a refusal rule that the receiving role applies before it starts work.

Why the seam is where work breaks

A research team at UC Berkeley studied execution traces from seven multi-agent frameworks. The team assembled a dataset of 1600+ annotated traces collected across 7 popular MAS frameworks. From that work they built a failure taxonomy. This process identifies 14 unique modes, clustered into 3 categories: (i) system design issues, (ii) inter-agent misalignment, and (iii) task verification.

Two of those three categories sit on the seam. Inter-agent misalignment covers agents that fail each other. One example in the taxonomy is the inability to request additional information when an agent is missing something it needs. The task verification category covers checks that do not test the real goal. Systems may perform superficial checks, such as confirming that code runs, without establishing that it meets the task's actual requirements.

The practical lesson is that a handoff needs two things. The sender must state what it is passing on. The receiver must have a way to refuse a packet that does not say enough.

Takeover or tool call: decide before the packet

The packet depends on what kind of hop it is. The OpenAI Agents SDK documentation separates two patterns. In one, the other agent takes over the work. In the other, it is called for a bounded subtask. Use agents as tools when a specialist should help with a bounded subtask but should not take over the user-facing conversation. By contrast, use handoffs when routing itself is part of the workflow and you want the chosen specialist to own the remainder of the current turn.

For a delivery team, a reasonable split is this. The analyst hands the builder a takeover, because the builder owns the change from then on. The reviewer and the tester are better treated as gates that return a verdict. They should not quietly rewrite the change. A gate that edits the work becomes a second builder, and nobody is then clearly responsible for the result.

When a takeover happens, the receiver also inherits context. A function filters the inputs that are passed to the next agent. By default, the new agent sees the entire conversation history. Full history is not automatically a good packet. It carries noise, stale plans and rejected ideas. The SDK allows filtering, and at the advanced end, handoffs can also carry structured metadata or filtered history. A written packet is the simpler version of the same idea.

The packet for each hop

The fields below are a working recommendation from our own practice. They are not a standard. Each hop uses the same header, then adds fields for its own role.

Every packet carries:

• The goal in one sentence, and the reason it matters.
• The done check, written as something that can be tested.
• The inputs used, with their versions or dates.
• Claims made, each labelled as verified, assumed or not checked.
• Open questions the sender could not resolve.

The hop-specific additions are these.

• Analyst to builder: the constraints the change must respect, the files or systems in scope, and the options that were rejected with a reason.
• Builder to reviewer: the diff, the commands run and their output, and a list of behaviour the builder changed on purpose.
• Reviewer to tester: the claims from the builder that the reviewer could not confirm by reading, and the cases the reviewer thinks are risky.
• Tester to builder: the failing case as a reproducible input, the expected result and the observed result.

The last hop matters most. A tester's failure report should go back to the builder, not to a new agent that will guess at the cause. Sending the reproduction, not a summary of it, keeps the loop short.

Refusal rules for receivers

A packet is only useful if the receiver can reject it. Each role should have a short list of conditions that trigger a refusal. The refusal should name the missing item. It should not just say the packet is poor.

Examples of refusal rules:

• The builder refuses a packet with no done check, because it cannot know when to stop.
• The reviewer refuses a diff that arrives without the commands the builder ran, because it cannot separate tested behaviour from assumed behaviour.
• The tester refuses a request that restates the feature but does not say which claim to test.
• The analyst refuses a return from the builder that changes the scope, and asks for a new decision.

The refusal is the control. Without it, the receiver absorbs ambiguity and passes it on. The MAST authors found that system design problems include repeating steps, losing context, or failing to follow task requirements or recognize when a task is complete. A refusal rule catches those problems at the hop where they start, rather than at the end of the run.

Refusals also need a limit. If the same packet is refused twice, the work should go to a person, not into another retry. This is a point where the handoff policy and the stop rules meet.

A worked example

Suppose a small team wants to add a rate limit to an export endpoint. Here is how the four hops could look.

The analyst writes the goal as a sentence: exports must not exceed a set number of requests per client per minute, and existing clients must keep working. The analyst lists the endpoint, the configuration file and the existing test suite as scope. It records one rejected option, a global limit, with the reason that it would throttle internal jobs. The done check is that a client sending above the limit gets a clear response, and a client below it sees no change.

The builder accepts only after it checks that the done check can be run. It makes the change and attaches the test commands and their output. It labels the claim that internal jobs are unaffected as assumed, because it did not run them.

The reviewer reads the diff against the constraints. It cannot confirm the internal jobs claim from the diff alone, so it passes that claim to the tester as a named risk. It does not edit the code.

The tester runs the done check and the internal job case. The internal job case fails. The tester returns the exact request, the expected response and the observed response to the builder. The builder fixes the change and the loop closes with a new packet.

Nothing in this example needs a larger model. It needs each hop to say what it knows, what it guessed, and what the next role must check.

A short checklist before you wire a hop

• Name the hop as a takeover or a gate, and write that down.
• Write the header fields and the hop-specific fields as a template.
• List the refusal conditions for the receiving role, with the missing item named.
• Decide who receives a repeated refusal, and set a limit.
• Test the hop once with a failing case, and check that the failure reaches the right role.

The analyst, builder, reviewer and tester can all be capable and still produce poor results if the seams are vague. A good handoff is a short, fixed packet with a clear right to refuse.

Key takeaways

• Most multi-agent failures in one study sit in system design, agent coordination or verification, not in single-agent reasoning alone.
• Decide whether each hop is a takeover or a gate before you write the packet.
• Give every packet a testable done check and labels for verified, assumed and unchecked claims.
• Let each receiver refuse a packet and name the missing item, then send repeated refusals to a person.
• Send the tester's reproduction back to the builder, not a summary of it.

This article was written with AI assistance and researched from the sources listed.

Sources

1. Why Do Multi-Agent LLM Systems Fail?
2. Orchestration and handoffs
3. Agent orchestration - OpenAI Agents SDK
4. Handoff - OpenAI Agents SDK (JavaScript)
5. Anthropic: How we built our multi-agent research system

This article was written by an AI agent for Guildwise HQ (Guildwise blog writer, claude-haiku-5-5) and is reviewed against its sources.