Why AI coding agents lose context between handoffs (and what fixes it)
Every tool in this category isolates agents from each other. Almost none connect them. That gap is why you keep re-explaining the same codebase.
If you run more than one coding agent, you have hit this: the first agent works out how the authentication flow actually behaves, finishes, and that understanding evaporates. The next agent starts from zero. You become the memory.
AI coding agents lose context between handoffs because isolation and memory are implemented by the same mechanism. Tools give each agent its own git worktree so agents cannot overwrite each other's files — but a worktree is also a fresh, empty starting point, so each agent begins with no knowledge of what the previous one discovered.
Why does this happen at all?
It is a side effect of how the category solved its first problem.
When people started running several agents at once, the immediate failure was collision: two agents editing the same files, overwriting each other's work. Git worktrees fixed that cleanly. Each agent gets its own working copy of the repository, edits freely, and nothing clobbers anything.
The fix worked so well it became universal — nearly every orchestration tool now uses worktrees. But isolation is symmetrical. A boundary that stops agent A corrupting agent B's files also stops agent A telling agent B anything. The tools did not decide against shared memory; they inherited the absence of it from the isolation model.
The practical result is that most orchestrators route coordination through the human. The board holds task state, not a shared understanding. You read what one agent produced, judge what matters, and carry it forward yourself.
What does the context loss actually cost?
Three things, in rough order of how much they annoy people:
- Your attention. You are the integration layer. Every handoff needs you present to read output, extract the relevant findings, and brief the next agent. That is exactly the work you were trying to delegate.
- Tokens. Each agent re-reads and re-derives the same context independently. A three-agent team has been measured at roughly seven times the token consumption of a single-agent session — a good part of that is duplicated discovery.
- Consistency. Independent agents reach independent conclusions about the same codebase. Two of them can implement incompatible interpretations of the same requirement, and you find out at integration time.
There is a real trade-off here, though, and it is worth being straight about it: for genuinely parallel work, isolation is not a bug. Three unrelated features in three worktrees, each agent starting clean, is the right design. The problem is specific to sequential work, where step two depends on what step one learned.
What approaches actually address it?
| Approach | How context moves | Honest limitation |
|---|---|---|
| You, manually | You read and paste between agents | Works today, costs your attention at every handoff, does not scale past a couple of steps |
| Project memory files | A file in the repo that every agent reads | Good for stable facts about the project; poor for findings from the current run, and it goes stale silently |
| First-party agent teams | Sub-agents share a task list and can message each other | Real coordination, but confined to one vendor's agents — no help if you deliberately mix Claude Code with Codex |
| Routing with carried context | The orchestrator holds context and passes it across each handoff | Addresses the sequential case directly; the orchestrator becomes a dependency you are trusting |
The workaround most people land on
A committed project memory file gets you further than you would expect, and costs nothing to try. Write down the things every agent needs to know about the repository — architecture, conventions, the non-obvious constraints — and point each agent at it. It solves the stable half of the problem. It does not solve the volatile half: what this particular agent just discovered in this particular run, which is the part that actually evaporates.
If you use one vendor's agents
Check the first-party option before adding anything. Anthropic has an experimental agent teams feature where a main session spawns specialised sub-agents that share a task list and can message each other directly, each with its own context window. If your work is entirely inside one ecosystem, that is real coordination without a new dependency. It does not help if the reason you run several agents is that you want different vendors' strengths on different steps.
How does routing with carried context differ?
The distinction is what the orchestrator is for. Most tools orchestrate execution — they start agents, isolate them, and show you the results. The alternative is to orchestrate the task: keep one task as the unit, decide which agent handles each step, and carry the accumulated context across every handoff.
That is what AgentPilot does. One task goes in; each step is routed to the agent best suited to it; the context gathered so far travels with the work; one finished result comes back. If an agent stalls partway through, the mission continues — the work moves to a standby agent along with everything gathered so far, so an interruption costs a handoff rather than the whole task.
It runs on macOS and Windows, and missions execute on your own machine rather than someone else's cloud. File, terminal and web access are granted per mission and can be revoked, and your credentials stay isolated from the agent sessions that use them.
The caveat that belongs here: AgentPilot is in early access, not generally available, so it cannot be the answer to "what should I install today". If you need a working setup this week, the manual and memory-file approaches above are real and cost nothing. If the re-explaining is the part that has worn you down, the waitlist is the honest next step.
What should you check before choosing a tool?
Whatever you end up with, these four questions separate the tools in this category better than feature lists do:
- Does anything persist between runs? If each session starts empty, the team learns nothing across a week of work.
- Can agents reach each other, or does everything route through you? This determines whether you can step away mid-task.
- Is the isolation about files or about your machine? Worktrees stop file collisions. They do nothing about an agent running a destructive command against your host.
- What happens when an agent stalls? Whether that costs you one handoff or the entire task is a design decision, and it is rarely on the feature list.
Frequently asked questions
- Why do AI coding agents lose context between handoffs?
- Because isolation and memory come from the same mechanism. Orchestration tools give each agent its own git worktree so agents cannot overwrite each other's files, but a worktree is also an empty starting point. Each agent therefore begins with no knowledge of what the previous agent discovered.
- Does git worktree isolation cause context loss?
- It is the direct cause. Worktrees solve file collisions between parallel agents, and the same boundary that prevents agent A corrupting agent B's files also prevents agent A passing anything to agent B. For genuinely parallel work this is the correct design; for sequential work it means context is discarded at every handoff.
- How much does context loss cost in tokens?
- A three-agent team has been measured at roughly seven times the token consumption of a single-agent session. A significant share of that is duplicated discovery, because each agent independently reads and re-derives the same context.
- Can a project memory file fix this?
- Partly. A committed file describing architecture, conventions and non-obvious constraints solves the stable half of the problem and costs nothing to try. It does not carry findings from the current run, which is the context that actually evaporates at a handoff, and it goes stale without anyone noticing.
- What happens if an agent stalls halfway through a task?
- That depends on the tool and is rarely stated on feature lists. In most worktree-based orchestrators the work in that session is lost and you restart it. Designs that carry context centrally can hand the work to a standby agent along with everything gathered so far, so an interruption costs one handoff instead of the whole task.
Disclosure: this page is published by AgentPilot, which is one of the tools compared. Details about other products come from their own public documentation on the date shown above, and this category changes fast — verify anything you are about to depend on.