The Seven-Part Handoff That Stops Builders' AI Agents From Repeating Work

When you have more than one AI agent working on the same job, at some point one of them has to stop and let another one continue.

One agent does what it needs to do and hands it off to agent B for agent B to take over and continue.

That moment is where agent systems break. Below is what the handoff is, when to use one and the seven things the package needs to carry.

What is an agent handoff?

In a handoff, ownership of the work transfers from one agent to another along a defined context package.

Once the first agent is done with its part, the second agent is responsible for the outcome.

Think of a legal agent and a sales agent. The legal agent reviews the terms. Once that is done, it says, hey, legal agent is done. Sales agent, please take over and continue. From there the sales agent owns the result.

For the bigger picture of how agents fit into a business, read building AI workers.

When should one agent hand off to another?

Use a handoff when ownership of the work should move. There are a few cases I see:

• A specialist agent should continue the work from here.
• A department agent has to become responsible, like sales after legal.
• The first agent has reached the edge of what it is allowed to touch.

That last case matters. Each agent has its own access. A sales agent working on sales things does not need access to your support desk, and the finance agent does not need what the sales agent has. A handoff lets the work move between them while each one keeps its own access. Each agent should get only the access its job needs. It also helps to write down what each agent must never do.

Key point: A handoff moves ownership. After the handoff, the receiving agent owns the outcome. The sending agent is done with its part.

What goes wrong when there is no handoff package?

If agent A just says “your turn” and passes nothing else, the receiving agent might repeat the work that has already been done. And we don’t want that to happen.

Two other things happen too.

Evidence is lost. The first agent found something, and the second agent never sees it.

The permission might silently be widened or narrowed. The receiving agent ends up able to do more than the job needs, or it cannot reach what it needs to finish.

Then you are paying for the same work twice.

What goes in an agent handoff package?

The required handoff package is your current objective, conversational context, relevant evidence, completed actions, unresolved questions, permissions and expected output.

Part	What the receiving agent gets
Current objective	The overall goal the work is serving
Conversational context	What has been said so far, with the client or with other agents
Relevant evidence	What the first agent found and where it came from
Completed actions	I have completed xyz
Unresolved questions	What is still open and who needs to answer it
Permissions	What the receiving agent is allowed to read and do
Expected output	This is what you need to do in order to finish the overall objective

The completed actions line is the one that stops the repeat work. The receiving agent reads what is done and starts from there.

The expected output line tells it where the finish is.

1. 1
   Agent A finishes its part. It writes down what it has completed.
2. 2
   Agent A builds the package with all seven parts.
3. 3
   Agent B reads the package and checks it has the access it was given.
4. 4
   Agent B picks up from the open questions and works toward the expected output.

How do you check that handoffs are working?

Testing and evaluating the system is how you understand exactly what is going on.

When I test a system with handoffs, I look at what the receiving agent did first. If it starts redoing research the first agent already did, the package is missing the completed actions or the evidence.

I also compare the permissions in the package with what the receiving agent actually used. That is how a widened permission shows up.

It also pays to keep evidence of what your agents did and why.

Handoff or shared workspace?

Some work keeps the same owner while several agents add to it over time.

For that I use a shared workspace, sometimes called a blackboard. Every agent writes to the same place: the evidence, the hypothesis, the task, open questions, partial output, decisions, confidence levels and unresolved conflicts.

Personally, I use the shared workspace a lot, for work where knowledge develops gradually. When one agent is finished and another one takes over, that is a handoff.

To see where agents fit next to the rest of your systems, read the AI systems playbook.

It is the same question we ask of people

When I map a process with a team, I ask: where is the handoff? Who do you pass it on to? And finally, what is now the outcome?

Agents need the same answers. If a handoff between two people is unclear in your business today, it will be unclear between two agents as well. Mapping it first is what we do in FusionMap.

Before you automate a handoff, explain the process first.

What changes in how the work runs

Without a package, agent B starts by working out what agent A already did, and sometimes it does that work again.

With the package, agent B reads what is completed, what is open and what it is allowed to touch. Then it continues. Each agent keeps its own access, and you can follow the work from one agent to the next when you test the system.

Takeaways and next steps

• A handoff transfers ownership of the work from one agent to another.
• The package has seven parts: objective, conversational context, evidence, completed actions, open questions, permissions and expected output.
• Completed actions stop the receiving agent from repeating work.
• Permissions are written into the package, so they cannot widen or narrow without anyone noticing.
• Work that several agents build up over time goes on a shared workspace instead.

If you own your own orchestration, you decide what the package looks like. More on that in vendor dependency vs. owned orchestration.

Common mistakes with agent handoffs

1. Passing only the last message to the next agent.

Why it fails: The receiving agent has no idea what was already done, so it starts again.

Better approach: The package carries all seven parts, including completed actions.

2. Letting the receiving agent inherit the sending agent’s access.

Why it fails: A sales agent ends up with finance access it never needed.

Better approach: Permissions are written into the package for the job the receiving agent has to do.

3. Leaving the evidence behind.

Why it fails: The second agent makes a call without what the first agent found.

Better approach: Evidence travels with the package, with where it came from.

4. No expected output.

Why it fails: The receiving agent does not know when it is finished.

Better approach: The package ends with what needs to happen to finish the overall objective.

5. Using a handoff for work that builds up over time.

Why it fails: Ownership keeps bouncing between agents and each one sees only part of the picture.

Better approach: Gradual work goes to a shared workspace that every agent writes to.

6. Never testing what the receiving agent does first.

Why it fails: Repeat work and widened access go unnoticed.

Better approach: Testing checks the first steps of the receiving agent against the completed actions and permissions.

Frequently asked questions

Glossary

Agent handoff

The point where one AI agent transfers ownership of a task to another agent.

Handoff package

The set of information passed with a handoff: objective, conversational context, evidence, completed actions, open questions, permissions and expected output.

Completed actions

The list of steps the sending agent already finished, so the receiving agent does not repeat them.

Permissions

What an agent is allowed to read and do, such as which systems it can open and whether it can send anything.

Shared workspace (blackboard)

A common place where several agents record evidence, open questions, partial output and decisions as work develops.

Orchestration

The setup that decides which agent does what and when, and how work moves between them.