When work changes hands
An agent handoff is the moment one AI agent passes a piece of work to another agent, or to a person. The first agent has done its part. The next one picks up the rest, with enough context to carry on without starting over.
Think of a lead that comes in through your website. One agent reads the form, checks the lead against your CRM and writes a first reply. When the lead asks for a quote, that agent hands the work to the agent that prepares quotes. When the quote is accepted, the work moves again, this time to the agent that sends the invoice.
Each move is a handoff. Done well, nobody notices them. Done badly, they are where work gets lost.
Why work gets split between agents
A single agent can do a lot. So it is fair to ask why you would split work at all. There are a few good reasons, and they are the same reasons a business splits work between people.
- Different tools. The agent that runs your ads needs your ad accounts. The agent that chases invoices needs your accounting software. Neither needs the other’s access.
- Different rules. Spending money on ads has one set of limits. Writing to a customer about a late payment has another. Keeping each set of rules with one agent makes both easier to check.
- Focus. An agent with a narrow job and a clear brief tends to do that job more reliably than one asked to do everything.
- A clear record. When each agent owns one part, you can see which part went wrong and fix that one.
The cost of splitting is the handoff itself. Every time work moves, something can be dropped. So the split only pays when the parts are truly different.
What a good handoff carries
A handoff is more than a message that says “your turn.” The receiving agent needs to know what it is picking up and why. A useful handoff carries five things.
- The goal. What done looks like for this piece of work, in plain words.
- What already happened. The steps the first agent took, the replies it sent and the answers it got back.
- What is still open. The question that is not answered yet, or the step that is waiting on someone.
- The source records. The customer record, the email thread, the order or the row in the spreadsheet, so nothing has to be looked up from memory.
- Who is responsible now. One clear owner from this point on, so the work never sits between two agents.
Take a support example. A customer writes to your shared inbox about a damaged order. The first agent reads the email, finds the order in your store and confirms it shipped last week. The customer wants a refund. Refunds belong to a different agent with access to payments and a rule that any refund above a set amount goes to you. The handoff carries the email, the order, the photos the customer sent, a short note of what has been said so far and the open question of whether to refund in full.
The refund agent should not need to ask the customer anything the first agent already knows. That is the test of a good handoff.
The common shapes of a handoff
Handoffs follow a few patterns. Most setups mix them.
Agent to agent, in a line
Work moves from one agent to the next in a fixed order. Lead, then quote, then invoice. This is the easiest shape to follow and the easiest to check.
A coordinator that routes work
One agent receives everything and decides which specialist should take it. A request in the shared inbox might go to support, sales or billing depending on what it says. The coordinator does little of the work itself. Its job is to route well and keep track of where each item went.
Agent to person
Some work should always end with a person. An agent drafting a contract change, a large refund or a reply to an upset customer hands the work to you with everything you need to decide. This is a handoff too, and it deserves the same care. You should not have to dig for the context.
Person back to agent
After you decide, the work often goes back. You approve the refund, and the agent sends it and writes to the customer. A good setup makes that return trip as clear as the first one.
How an agent decides to hand off
From a developer’s point of view, a handoff is a decision the system makes at a step boundary, and it should be made on signals you can name and test. Leaving it to the model’s general sense of “I should ask someone” produces handoffs that are too early on easy cases and too late on hard ones.
These are the signals most production systems use.
| Signal | What triggers it | Usually hands to |
|---|---|---|
| Capability boundary | The next step needs a tool or permission this agent does not have, like payments or production access | Another agent that holds that capability |
| Policy gate | The next action is one policy reserves, like a refund above a limit or a contract change | A person with the authority to approve it |
| Low confidence | A classifier score, a retrieval match or the agent’s own check falls below a threshold, or required fields are missing | A person, or a specialist agent for that case type |
| No progress | The same tool fails repeatedly, the plan loops or a step exceeds its retry budget | A person, with the attempts so far attached |
| Budget exhausted | The task has used its token, time or cost budget without finishing | A person, or a queue for later |
| Explicit request | The customer or user asks for a person, or the conversation shows anger or legal language | A person, at once |
| Deadline risk | A service-level clock will breach if the work keeps waiting on this agent | A person or a team queue with capacity |
The choice between another agent and a person follows from the signal. Hand to an agent when the problem is capability, meaning the work is clear and only needs a tool or access this agent lacks. Hand to a person when the problem is judgment or authority, meaning the right answer is unclear, the stakes are high or policy says a human decides.
In code, a handoff is usually modeled as a tool the agent can call, with a target and a typed payload. Frameworks such as the OpenAI Agents SDK and LangGraph offer this directly, and a coordinator agent can call it to route work as well. The important design choice is that the call is validated like any other action. The target must exist, the payload must carry the required fields, and the policy layer, not the model, decides whether this agent is allowed to hand this work to that owner.
Tuning handoffs for timing and quality
Handoffs are the part of a multi-agent system that degrades quietly, so they need the same engineering discipline as any other path to production. These practices make the biggest difference.
Make the criteria explicit and testable
Write the handoff conditions as rules and thresholds in code or configuration, versioned with the agent. “Escalate refunds above EUR 500” and “escalate when retrieval confidence is below 0.6” can be tested and reviewed. “Escalate when unsure” in a prompt cannot.
Give the handoff a schema
Define the payload as a typed object with required fields, like the goal, the actions taken, open questions, the source record IDs and the new owner, and reject a handoff that is missing them. The receiver should never have to ask for something the sender already knew.
Build an evaluation set for handoff decisions
Collect real cases, label the right moment and the right target for each, and replay them against every change to the agent’s prompt, model or policy. Track three error types separately, because they have different costs. Early handoffs waste people’s time. Late handoffs let an agent struggle or act beyond its remit. Missed handoffs are the dangerous ones.
Trace every hop
Emit a trace span for each handoff with the sender, the receiver, the reason code, the payload size and the time spent waiting. With OpenTelemetry-style tracing you can follow one customer case across agents and people, which is the only way to debug a failure that spans three of them.
Watch the numbers that show trouble
- Ping-pong rate. Work that moves back and forth between the same two owners means the routing rules overlap.
- Re-ask rate. A receiver asking for information the sender had means the schema is missing a field.
- Wait time per queue. Long waits after handing to people mean the wrong team or too few approvers.
- Override rate. People routinely reversing what the agent did before handing off means the threshold is too low.
- Hop count. Cases that pass through many owners need a maximum, after which they go to a person.
Prevent double work with ownership
Give each piece of work a single owner at a time, held as a lease that expires. A receiving agent claims the work before acting, and a second claim fails. This stops two agents replying to the same customer when a retry or a race fires the handoff twice.
Roll changes out carefully
Run a new routing rule or threshold in shadow mode first, where it records what it would have done without acting, and compare it with the live decision. Then move a small share of traffic, watch the metrics above and widen it. Feed the resolutions people make on escalated cases back into the rules and the evaluation set, so the same case is handled by the agent next time.
Where handoffs go wrong
Most failures fall into a short list. Knowing them makes them easier to spot.
| Failure | What it looks like | What prevents it |
|---|---|---|
| Lost work | A request that nobody picks up after the first agent finishes | One named owner at every step, and an alert for work that sits too long |
| Double work | Two agents both reply to the same customer | A clear rule for who owns each kind of work |
| Lost context | The customer is asked again for an order number they already gave | A handoff that carries the full history and the source records |
| Wrong owner | A billing question lands with the ads agent | A routing rule you can read and correct |
| Silent changes | An agent changes a record the next agent relied on | A record of every change, visible to every agent that touches the work |
| No way back | A person decides but the work never moves on | A defined return step after every approval |
Lost context is the one teams feel most. It is also the one customers notice, because it is the moment they have to repeat themselves.
What to check before you rely on handoffs
You do not need to understand how agents talk to each other to judge whether handoffs work. You need to ask the right questions and look at the record.
- Can you see every handoff? There should be a record that shows when work moved, from which agent to which, and what went with it.
- Is there always one owner? At any moment, you should be able to say who holds a piece of work. If the answer is “both” or “nobody,” the setup has a gap.
- Does the next agent have enough? Pick a few real handoffs and read what was passed. Could a new employee carry on from that note alone?
- What happens when an agent is stuck? An agent that cannot finish should hand the work to a person, not drop it or keep trying forever.
- Do your approvals survive the move? A rule that says refunds over a certain amount need your approval should hold no matter which agent handles the refund.
- Can you correct the routing? When work goes to the wrong agent, you should be able to fix the rule in plain words, not wait for someone else to change it.
Run these checks on a small slice of real work before you widen it. A week of invoices or a day of support email will tell you more than any demo.
How handoffs compare to the way people pass work
The best way to think about agent handoffs is to compare them with how a well-run team passes work between people. The same habits matter.
| Habit | On a good team | Between agents |
|---|---|---|
| Clear ownership | One person owns each task | One agent owns each piece of work at a time |
| A written note | A short summary when a task changes hands | A handoff that carries goal, history and open questions |
| Shared records | Everyone works from the same CRM and inbox | Every agent reads the same source records |
| Escalation | Hard calls go to a manager | Decisions you reserve come to you |
| Follow up | Someone checks the task got done | The record shows the work reached its end |
If a handoff would be poor between two people, it will be poor between two agents. If it would be good between two people, it is likely to work between agents too.
Keep the number of handoffs small
More agents is not better on its own. Each extra handoff is one more place for context to fall out. Start with the fewest splits that make sense, usually where the tools, access or rules truly differ. Add a new agent only when one is clearly doing two jobs that pull against each other.
A large support operation might start with one agent on the shared inbox and one on billing, with a single handoff between them for billing questions and a handoff to people for anything outside policy. That is enough to learn how handoffs behave in your systems before you add more.
