Agent handoffs: passing context between AI agents without losing it
How to hand work from one AI agent to the next without losing the reasoning: a handoff template, a read-back check and a worked example you can copy.
An agent handoff is the moment one AI agent finishes its part of a job and passes the work to another agent or a person. To pass context without losing it, write the handoff as a short, structured note: the goal, what was done, what was decided and why, what is still open, and where the sources live.
Most multi-agent setups fail at the seams. Each agent does its step well, then hands over output with none of the reasoning behind it. This post covers what gets lost, a handoff format that works, and how to check the next agent got the message.
What an agent handoff is
A handoff happens any time work moves between agents or between an agent and a human. Some common examples:
A research agent gathers competitor pricing, then a writing agent drafts the pricing page.
A triage agent reads a support ticket, then a coding agent fixes the bug.
You close one chat session at 6pm and start a fresh one the next morning.
That last one counts. A new session is still a new agent with an empty context window. The next agent only knows what you put in front of it.
Why context gets lost between agents
Agents don't share a memory by default. Each one starts with its instructions, whatever the previous step passed along, and the tools it can reach.
The output travels, the reasoning doesn't
A research agent returns "Recommended price: $49 per seat." The writing agent gets the number. It does not get the fact that you ruled out $39 because it undercut a partner, or that the number only applies to annual plans. So the draft says "$49 per seat, billed monthly," and nobody notices until a customer does.
Summaries drop the edge cases
When an agent compresses a long session, it keeps the main thread and drops the exceptions. Exceptions are usually what matters: "except for EU customers."
Each agent sees a different version of the truth
If one agent reads last quarter's policy and the next reads the current spec, they will disagree, and neither will know. This is the agent version of the handover problem teams have when people change roles.
Nobody owns the open questions
An agent flags something it could not resolve, then the run ends. The next agent never sees the flag, so the question quietly becomes an assumption.
What a good handoff contains
A handoff note should be short enough to read in full and structured enough that nothing depends on prose. Use the same headings every time.
Field | What goes in it | Example |
|---|---|---|
Goal | The outcome the whole job is for, in one sentence | Publish a pricing page for the new Team plan by Friday |
Done so far | What this step produced, with links | Pricing research doc, three competitor tables |
Decisions and reasons | What was settled, and why | $49/seat, annual only, because monthly churned twice in the pilot |
Constraints | Rules the next step must follow | Don't mention the partner discount publicly |
Open questions | What is unresolved, and who decides | EU VAT wording: finance to confirm |
Sources | Where the facts came from | Link to the pricing decision, the policy doc, the spec |
Next step | Exactly what the receiving agent should do | Draft the page using the decisions above; flag anything that conflicts |
Two fields do most of the work. "Decisions and reasons" stops the next agent from re-deciding settled questions. "Open questions" stops guesses from turning into facts.
How to set up handoffs step by step
Write a handoff template. Put the table above into a short Markdown file. Tell every agent in the chain, in its instructions, to end its run by filling it in.
Make the receiving agent read it first. The first line of each agent's instructions should be: "Read the handoff note before doing anything. If it conflicts with your other instructions, stop and ask."
Pass links, not copies. A link to the source doc stays current. A pasted summary goes stale the day someone edits the original.
Keep the handoff in one shared place. A repo folder, a ticket or a shared doc, not a chat history the next agent can't open.
Add a read-back check. Ask the receiving agent to restate the goal, the key decisions and the open questions in two or three lines before it starts. If the read-back is wrong, the handoff was wrong. Fix the note, not the agent.
Close the loop on open questions. When a person answers one, update the note and the decision record. Our guide on guardrails for AI agents covers how to log who decided what.
A worked example
Say a triage agent picks up a ticket: "Export to CSV drops rows over 10,000." Its handoff to the coding agent reads:
Goal: CSV export returns all rows for any account.
Done: Reproduced on a test account with 12,000 rows. Logs linked.
Decisions: Fix the export, don't raise the limit in the UI. Reason: product agreed in last month's planning that the cap was a bug, not a feature (decision linked).
Constraints: Don't change the export format. Two customers parse it with scripts.
Open questions: Should exports over 100,000 rows be emailed instead? Owner: product lead.
Next step: Write a fix and a test for 12,000 rows. Don't build the email flow.
The coding agent knows what to build, what not to touch, and what is not its call.
Where tools like MCP fit
The Model Context Protocol (MCP) is an open-source standard for connecting AI applications to external systems, such as files, databases and tools. It helps with handoffs in one specific way: if every agent in your chain can reach the same source, through the same connection, they read the same version of the truth instead of copies.
MCP is plumbing, though. It lets an agent reach your decision log. It doesn't make the previous agent write down why it chose $49. That is still your job. For a plain-English intro, see MCP explained for people who don't write code.
FAQ
What is the difference between a handoff and shared memory?
A handoff is a message passed from one agent to the next at one point in time. Shared memory is a place both can read from at any time. Use both: the handoff says what changed and what to do next, and shared memory holds the decisions and sources it links to.
How long should a handoff note be?
Usually under a page. If it is longer, you are probably pasting sources instead of linking them.
Should a person review every handoff?
No. Review the handoffs where a wrong assumption is expensive: anything touching pricing, customers, security or production. For low-risk steps, the read-back check is usually enough.
Does this apply when I just start a new chat?
Yes. Ending a session and opening a new one is a handoff to an agent with no memory of the first. Ask the old session to fill in the template before you close it, then paste it into the new one.
Getting started
Pick one chain of agents your team already uses, even if it is just research followed by drafting. Add the template and the read-back check, and run it for a week. The field the receiving agent gets wrong most often tells you what your handoffs were missing.
We're building Shane to keep the decisions, reasons and sources behind your team's work in one place every agent and teammate can read, so handoffs carry the why along with the what. If that's a problem your team has, you can join the waitlist at tryshane.ai.