Agent Context Handoff: What to Pass, Summarise or Drop

Facts fall out on the way, and nothing crashes. That is the core problem of agent context handoff: one agent reads the right fact, and the next agent never gets it.

An AI agent is a program where a model, the AI that reads and writes text, picks its next step in a loop. It can call tools, which are functions you allow, such as a page search.

Picture a common setup. A team uses four AI agents to prepare bids for government tenders. A tender here is a government body's formal invitation to bid for a job. The setup is made up, but the problem is real.

• The reader agent reads every page of the tender files and notes the key facts.
• The eligibility agent checks whether the client firm qualifies, for example on turnover (yearly sales) and past jobs.
• The pricing agent fills in a rate for each item of work.
• The compiler agent writes the final bid document, section by section.

A bids manager checks and signs off every bid. One bid was for a Rs 48 crore (480 million rupees) storm-water drain in Anakapalli. The tender ran to 312 pages, plus two corrigenda, which are official corrections issued after a tender is released.

Corrigendum 2 raised the earnest money deposit (EMD) from Rs 12 lakh (1.2 million) to Rs 15 lakh. The EMD is a security amount a bidder pays to show it is serious. The draft bid said Rs 12 lakh, and this tender could reject a bid with the wrong EMD.

The engineer who built the system traced the mistake. The reader agent had read corrigendum 2 correctly, and its notes ran to about 40,000 tokens, small pieces of text. Before the next agent saw them, a model squeezed them into one page, and the new EMD did not survive.

A second problem showed up the same week. The compiler agent ran for over three hours on a large bid. Early on, the bids manager told it not to list the Kakinada jetty job as past experience. Hours later, it listed the job anyway.

Both are handoff failures. The first happened between two agents. The second happened inside one long session, when old messages were squeezed to make room. The rest of this guide shows what the team changed, and why.

Five words cover most of this guide: context, token, context window, compaction and handoff note. Each gets a plain meaning and an example from the tender team.

Context. The context is everything the model sees in one request: its instructions, the conversation so far, tool results and notes. The model knows nothing outside it. Example: the compiler agent's context holds the price list and the bids manager's instructions.

Token. A token is a small piece of text, often a word or part of a word. Most model APIs count usage and charge by tokens. The reader agent's notes on one tender came to about 40,000 tokens.

Context window. The context window is the most tokens a model can work with in one request. When a long session gets close to it, something must be cut or squeezed. Your provider's docs say whether the reply counts towards that limit.

Compaction. Compaction replaces older parts of the context with a shorter summary, so a long session can keep going. It saves space, but anything the summary leaves out is gone for the model.

Handoff note. A handoff note is the package one agent or session leaves for the next. Example: the reader agent's note to the eligibility agent, with the goal, the key facts and the next step.

Memory, retrieval and compaction in general have their own guide on context engineering. This guide is about the moment work changes hands.

Agent context handoff is the step where one agent, or one session, passes the state of a job to the next, so work continues without starting over. It decides what the receiver knows.

The receiver cannot look inside the sender's context. It sees only what the handoff gives it. If a fact is not in the handoff, and the receiver has no tool to fetch it, then for the receiver that fact does not exist.

Think of a long-haul truck run from Visakhapatnam to Nagpur, with a relief driver taking over midway. The first driver cannot hand over his memory of the road. He hands over the keys, the delivery papers and a few words.

Good drivers know which words matter. The load is 18 tonnes of cement, and the yard at the other end closes at 6 pm. Nobody needs the songs he played or where he stopped for tea.

Map it part by part. The delivery papers are the exact facts, copied and never retold. The few words are the summary. The songs and tea stops are what you drop.

Where the picture breaks: the relief driver can phone the first driver with a question. An agent usually cannot, unless you build a way to send the note back. Without one, the receiver guesses.

There are three kinds of handoff to plan for. All three carry the same risk.

• Between agents. One agent finishes its part, and a different agent with different instructions and tools picks up. Example: the reader agent hands over to the eligibility agent.
• Between sessions. The same job continues in a fresh context, because the old one is too full, it crashed, or work resumes tomorrow. Example: the compiler agent on a three-hour bid.
• Between an agent and a person. The agent stops and hands the job to a human, like the bids manager, who must understand it fast.

Here is the team's first version. Follow the arrows from the tender files to the bids manager. Every arrow between two agents is a handoff, and every handoff is a place where a fact can fall out.

Each summary in that version was written from the summary before it, not from the tender itself. So small losses added up. By handoff 3, nothing in the context said that corrigendum 2 had changed the EMD.

Pass exact facts word for word, summarise the history and the reasons, and drop everything the next step will not use. The real skill is sorting each piece of context into one of those three piles.

Pass word for word

Some facts must never be reworded. Amounts, dates, deadlines, names, ids and the user's own instructions belong here. A model asked to summarise may round a number, merge two dates, or keep the old value next to the new one.

The team calls these must-carry facts. Each one also carries its source, such as corrigendum 2, page 1, so anyone can check it in seconds.

Summarise

The story so far can be shortened. The receiver needs what was done, what was decided and why, but not every step. A few lines such as all 312 pages and both corrigenda read, no joint ventures allowed, can stand in for 40,000 tokens of notes.

Keep decisions together with their reasons. If the eligibility agent decides a past job does not count, the note should say so and why. Without the reason, the next agent may reopen the question and decide differently.

Drop

Most context is safe to drop. Raw tool output, failed searches, retries, polite chatter and the sender's step-by-step thinking rarely help the receiver. They cost tokens and bury the facts that matter.

Dropping is not deleting. The team saves the full trace of every agent, meaning the complete record of one run, in storage. The receiver never sees it, but a person can open it when something looks wrong.

The table sorts the usual kinds of context in the tender team into the three piles. Rs 15,00,000 in it is Indian digit grouping for 1.5 million rupees.

When you are unsure about one item, ask two questions in order. The diagram shows the sorting the team's code now does for every item.

Write it as a fixed structure with named fields, not as free text. A structure makes missing pieces easy to spot, both in code and by eye.

Hospitals face the same problem, because patients change hands at every shift. A 2012 commentary in the journal Pediatrics described I-PASS, a structure for doctors' spoken handoffs.

Its elements are illness severity, patient information, an action list, situational awareness and contingency plans, and synthesis by the receiver. Synthesis means the receiver says back what it heard, so gaps show up before work starts.

The team's handoff note has six fields. The code below is the whole format, in plain Python with no framework, and we ran it on Python 3.13. A dataclass is a Python class that mainly holds named fields. If you do not code, skip to the paragraph after it.

import json
from dataclasses import dataclass, field, asdict

@dataclass
class HandoffNote:
    goal: str                    # what the whole job is for
    done: list[str]              # finished steps, one line each
    must_carry: dict[str, str]   # exact facts, copied by code
    open_questions: list[str]    # what nobody has settled yet
    next_action: str             # the receiver's first step
    sources: dict[str, str] = field(default_factory=dict)

# In real use, must_carry is filled from the reader agent's tool results.
note = HandoffNote(
    goal="Bid for the Anakapalli drain tender, due 28 Oct",
    done=["Read all 312 pages and both corrigenda"],
    must_carry={"EMD": "Rs 15,00,000"},
    open_questions=["Is the 20 October site visit compulsory?"],
    next_action="Check the turnover rule for the last 3 years",
    sources={"EMD": "Corrigendum 2, page 1"},
)

saved = json.dumps(asdict(note))           # store this with the checkpoint
loaded = HandoffNote(**json.loads(saved))  # the next session rebuilds it
print(loaded == note, len(saved), "characters")

Run it and you should see one line: True 322 characters. True means the note survived the trip to JSON text and back unchanged, and 322 is the length of that text.

Two fields matter most. The team's code fills must_carry straight from the reader agent's tool results, never from a model's summary. And next_action names one first step, so the receiver does not wander.

The open_questions field is easy to skip and costly to lose. An unsettled question that drops out of a handoff quietly becomes an assumption further down the line.

Treat a long session as a chain of shorter sessions, each starting from a clean handoff note. Pin the must-carry facts and the user's instructions in a block that no compaction can remove.

Research points to two risks. A 2023 study, Lost in the Middle, found that models often used information best when it sat at the start or end of a long input. Results often dropped when the key fact sat in the middle.

A 2025 study found a second risk: tasks that arrive in pieces over several messages. Across six tasks where the model writes something, such as code or a summary, scores dropped by 39% on average, compared with giving the whole task in one message.

That study tested pieces arriving over turns, not long inputs as such. A long agent session gathers instructions the same way, piece by piece, which is our reason to apply it here.

Compaction alone does not fix this. Each compaction is a handoff from a session to itself, usually written by a model, with the same risk of losing facts. That is how the Kakinada instruction disappeared.

The team now runs the compiler agent's long sessions in six steps. The steps work with or without an agent framework.

1. 1

   Pin the facts

   Must-carry facts and the bids manager's instructions sit in a pinned block at the very top of every request. Compaction never touches that block.

2. 2

   Watch the fill level

   Code counts tokens after each step. When the context reaches 70% of the window, the session finishes its current section and starts no new one.

3. 3

   Write a handoff note

   The session fills a HandoffNote: sections done, decisions and reasons, open questions, and the next section to draft.

4. 4

   Save a checkpoint

   The note and the finished sections go to a store. A checkpoint is a saved point you can restart from, so a crash or a pause loses nothing.

5. 5

   Start fresh

   A new session begins with only the pinned block, the note and the files it needs for the next section.

6. 6

   Read back first

   Before drafting anything, the new session restates the must-carry facts and the next action. Code compares them with the note.

The 70% figure is the team's own setting, made up like the rest of the setup. Your number depends on your model and your task, so measure it rather than copying it.

The diagram shows one rollover from session 1 to session 2. Notice that the pinned facts travel inside the checkpoint, outside any summary.

Ask the receiver to read back the must-carry facts, then compare its answer with the note in code. If anything is missing or changed, the handoff goes back before any work starts.

This is the I-PASS synthesis step, made strict. The receiver returns its read-back as structured data, with each fact in a named field. Code then checks each one exactly.

Add the code below under the first block and run the file again. The read_back dictionary stands in for the receiver's answer, which in real use comes from a model call.

def handoff_problems(note, read_back):
    """List every must-carry fact the receiver lost or changed."""
    problems = []
    for name, value in note.must_carry.items():
        got = read_back.get(name)
        if got != value:
            problems.append(f"{name}: sent {value!r}, got {got!r}")
    if read_back.get("next_action") != note.next_action:
        problems.append("next_action: not restated exactly")
    return problems

# Stand-in for the receiver's answer. In real use, a model call returns this as JSON.
read_back = {"EMD": "Rs 15 lakh", "next_action": note.next_action}
for problem in handoff_problems(note, read_back):
    print(problem)

It fails. Under the first line, the file now prints EMD: sent 'Rs 15,00,000', got 'Rs 15 lakh'. The comparison is exact on purpose. A false alarm costs one retry, while a missed change can cost a bid.

If false alarms become common, change the format, not the check. Store amounts as whole rupees, such as 1500000, and ask for the read-back in the same form. Then an exact match is still the right test.

Retries need a limit too. After two failed read-backs, the team's code stops and hands the job to the bids manager, with the note and the list of problems.

A 2025 study, Why Do Multi-Agent LLM Systems Fail?, built a list of 14 failure modes from 150 traces of agent teams at work. LLM means large language model, the kind of model these agents use.

Several of the 14 are handoff problems. The names below are the paper's. The plain meaning and the guard are ours, mapped to the tender team.

• Information withholding. An agent has an important fact and does not pass it on. In the tender team, this was the EMD. Guard: must-carry facts copied by code.
• Loss of conversation history. Part of the conversation is lost, and the agent works from an older picture of the job. This was the Kakinada instruction. Guard: the pinned block.
• Conversation reset. A conversation restarts without reason, and progress is lost. Guard: a done list in every note.
• Task derailment. An agent drifts away from the task it was given. Guard: the goal field, at the top of every handoff.
• Fail to ask for clarification. An agent goes ahead on a wrong assumption instead of asking. Guard: open questions in the note, and a way to send the note back.
• Ignored other agent's input. An agent gets input from another agent and does not use it. Guard: the read-back check.

Two more failures matter just as much. The first is mixing old and new values. When corrigendum 2 changed the EMD, the note should hold only the new value, with its source, not both amounts.

The second is untrusted text. A tender file is outside content, and whoever writes it controls its words. If a summary turns a planted line into an instruction, the next agent may obey it.

OWASP, a non-profit that publishes security guidance, calls this indirect prompt injection: the model takes input from outside sources such as websites or files. Its 2025 advice includes clearly marking untrusted content and giving the model only the access it needs.

The team's notes keep document text in a separate, labelled field, never among the instructions. Marking text this way lowers the risk but does not remove it.

Hand over to a person when the read-back keeps failing, when sources disagree, or when an open question changes money or eligibility. Those are the moments where a confident guess does the most damage.

A note for a person uses the same fields, written for a busy reader. The team puts the decision needed on the first line. Example: corrigendum 2 says the EMD is Rs 15 lakh, the price list still uses Rs 12 lakh, please confirm.

The bids manager answers in a minute or two, and the answer goes back into must_carry as a new exact fact. The agents then carry on from there.

It supports restarting, with one caveat. In the 2025 multi-turn study, gathering all the pieces of a task into one fresh message recovered nearly all the lost performance.

The authors ran more than 200,000 simulated conversations. In the sharded setting, a task's details arrived in pieces over several turns. In the concat setting, the same pieces were joined into one message, and scores averaged 95.1% of the original single-message version.

They also split the drop into two parts. Aptitude, a model's best-case score, fell by about 16% on average, which the authors call a minor loss. Unreliability, the gap between its good and bad runs on the same task, rose by about 112%.

Fixes inside the same conversation helped only partly in the authors' follow-up tests. Repeating earlier details in the last turn or in every turn did not bring scores back to the single-message level.

Setting temperature, the randomness setting, to 0 did not fix it either. The authors report that about 30% unreliability remained in multi-turn chats even at temperature 0.

The authors' advice to users is to start a new conversation and consolidate the requirements into one instruction. That is a handoff note by another name.

Now the caveat. Their concat messages were the original pieces joined as a bullet list, not a model's free-form summary. Their advice includes asking the model itself to consolidate, and a model-written summary is exactly where the EMD went missing.

So consolidate, but let code copy the must-carry facts. Lost in the Middle adds where to put them: the study tested question answering over many documents and finding a value by its key in a long list.

In both tasks, accuracy was often highest when the needed fact sat at the start or end of the input, even for models built for long inputs. That is why the pinned block goes at the very top.

One open-source library for building agents ships a summarisation middleware: code that runs before each model call and can compact the message history. We read its source and tested its latest release as of 19 October 2026.

By default it does nothing. You switch it on with a trigger, such as a token count. When it fires, it keeps about the 20 most recent messages and replaces everything older with one summary message. It moves the cut point so that a tool call and its result stay together.

The summariser reads only the recent part

One setting matters for handoffs. Before the summary is written, the old messages are trimmed to fit about 4,000 tokens, the default for its trimming setting. The source keeps the newest, so when the old part is longer than that, the oldest never reach the summariser.

The docs give the 4,000 limit but do not say which end is kept. So we tested it with a fake model, a stand-in that makes no network calls, on a 121-message history of about 13,300 tokens.

The first message was the Kakinada instruction. The trigger was 5,000 tokens and the setting kept the last 20 messages. Here is what reached the summariser.

Token counts here come from the library's built-in approximate counter, not a real tokeniser. In both runs the instruction was not kept word for word after compaction. With trimming off, it could survive only if the summary repeated it.

Where the pinned block can live

In a second test, we built an agent with the library's agent builder and put the must-carry facts in its system prompt, the fixed instructions sent with every request. After compaction, the model still received the system prompt first, and the early instruction was gone.

That works because this middleware compacts the message list, and the agent builder keeps the system prompt outside that list. So in the release we tested, the system prompt is a natural home for the pinned block.

To check your own setup, put a unique instruction in the first message and fill the history past your trigger. Then print what the summariser receives, and whether the instruction is in it.

What the handoff docs say to pass

The library's multi-agent docs, as of 19 October 2026, make this point about handoffs between agents too. When each agent runs as its own sub-workflow, they say you must explicitly decide what messages pass between agents.

Their example passes only two messages to the next agent: the tool call that asked for the handoff and the tool result that answers it. A code comment says not to pass the full history, and the docs suggest putting a summary of the work in that tool result.

That tool result must carry the matching tool call id, which pairs a tool call with its answer. Without it, the docs say, the message history is malformed. The must-carry facts can travel in the same tool result, copied by code.

Explain each handoff as an interface: what goes in, what must survive word for word, and how the receiver proves it got it. Then walk through the parts in order.

1. 1

   Draw the agents and the arrows

   Show each agent and each handoff. Say plainly that every arrow is a place where a fact can be lost.

2. 2

   Sort the context

   Explain pass, summarise and drop with one example each, such as an amount, the work done so far, and raw search results.

3. 3

   Define the note

   List its fields: goal, work done, must-carry facts with sources, open questions and the next action.

4. 4

   Keep exact facts out of summaries

   Say that code copies must-carry facts from the source, so no model ever retypes them.

5. 5

   Plan for long sessions

   Describe the pinned block, the fill-level trigger, checkpoints, and a fresh session that starts from the note.

6. 6

   Add the read-back check

   The receiver restates the key facts, code compares them, and repeated failures go to a person.

7. 7

   Log every handoff

   Keep full traces and every note in storage, so a lost fact can be traced to the exact handoff that dropped it.