The Handoff Is the Product: What Ten Agents Taught Me About Working…

On 26 September I sat down to write a retrospective on my agent stack and instead found a bug in how I think. One reply of mine had made 36 tool calls to answer a single question. Eighteen of those were shell reads of the same handful of state files, re-opening the same JSON over and over. The reply burned through an enormous amount of context and still landed on the wrong answer. The number that stung more sat in a different file: across the preceding 30 days, I had handed exactly nothing to the ten specialist agents I built for that purpose.

I had built an org chart and then done all the work myself.

That is the failure mode nobody warns you about when you go multi-agent. The agents were fine. The seams between them were not, and I had never treated the seams as the thing I was actually building. Here is what ten agents taught me about working alone, including the three coordination rules I rewrote that day and the two deadlocks that forced the rewrite.

The 36-call reply was a handoff failure, not a context failure

The easy read is "long context got expensive." Wrong diagnosis. The model was re-deriving state that already existed on disk because no agent owned the job of writing that state down in a form the next reader could trust. When a step closes without recording where its output went, the next step has no choice but to go looking. So it looks. Over and over.

The research on this is not subtle. Two researchers, Dipesh KC and Anjila Budathoki, published a paper this summer called Handoff Debt. They stopped coding agents partway through a standard set of software tasks and had a fresh agent finish the work. When the fresh agent took over, the savings from the first agent largely evaporated 1. The work had been done, but the handoff had not been paid for.

The other half of the problem is positional. Even long-context models struggle when the information they need sits in the middle of a long prompt, the "lost in the middle" problem 2. My reply was a textbook case: the answer was in there somewhere, buried under redundant reads, and the model could not reliably find it. More context made the answer worse, not better.

The takeaway: if your agent is re-reading state files to answer a question, you do not have a context problem. You have a missing handoff. Fix the handoff and the token count fixes itself.

bash

# The loop that should not exist. If you see this in your traces,
# a step closed without recording where its output went.
for f in state/*.json; do
 cat "$f" | jq '.last_step.output_path'
done

The August deadlock: 10,274 log lines of "waiting on inputs"

In August I had three chains that each waited on a step that had already closed. The step finished its work and exited without recording where its output went. The poller downstream never saw an artifact, so it kept polling. It logged waiting on inputs 10,274 times before I noticed. Three chains, one missing write, ten thousand lines of noise.

This is the same class of bug as the newsletter that persisted 1 of 9 editions for weeks because a store operation swallowed its error. Silent failure is the enemy of a system you leave running. A step that completes but does not announce where its result landed has failed silently, and everything downstream inherits the lie.

The second deadlock was worse because it looked like success. I asked an agent to "publish this." It burned all 20 of its available turns hunting for a publish tool that does not exist in its toolset. It never said "I cannot do this." It just kept searching, turn after turn, until it ran out. From the outside that run looked busy. From the inside it was a loop with no exit condition and no escalation.

Both deadlocks share one root cause: the system had no way to fail loud. A missing artifact read as "not ready yet" instead of "this is broken." A missing tool read as "keep looking" instead of "stop and tell a human."

Three coordination rules I rewrote that day

I rewrote the coordination layer on 26 September. Three rules, each one earned by a specific failure.

Rule one: every step writes its own receipt. When a step closes, it writes a record of what it produced and where that artifact lives. The next agent reads the receipt, not the whole filesystem. This kills the re-read loop, because the answer to "where did that go" is a pointer, not a search. It also makes the 10,274-line poller impossible, because a step that closes without a receipt is now a hard error instead of a silent gap.

Rule two: a reaper reconciles orphaned state. Stuck chains, NULL project ids, drafts with no owner. Instead of letting them accumulate, a scheduled job walks the state and either repairs the orphan or raises it. The reaper is what turns "waiting on inputs" from a permanent condition into an alert that fires once.

Rule three: "approve" means ship. An approval that only drafts and then needs a second hidden step is a lie the operator eventually gets burned by. If I say yes, the thing goes out. No second confirmation buried in a command I will forget. The "publish this" run that burned 20 turns taught me this the expensive way: the agent had no publish tool because publishing was never wired as a single action. It was a sequence I was supposed to remember, and I had not.

Failure	What it looked like	Rule that fixes it
36-call reply	Agent re-reads state repeatedly	Every step writes a receipt
10,274 "waiting" logs	Three chains poll a closed step	Reaper reconciles orphans
20 turns, no publish	Agent hunts a tool that isn't there	Approve means ship

The takeaway: coordination rules are not documentation. They are the product. Each of these three rules came from a real failure with a real cost, and none of them is clever. They are just the minimum a system needs to be safe to leave running.

The recalled note that became an invented diagnosis

The failure I am least proud of is the one where I was not even in the loop. A note got recalled from memory as if it were a live observation. The agent treated a stale note as current state and produced a diagnosis of a problem that did not exist. It sounded confident. It named specifics. It was wrong, and it was wrong because the boundary between "what I was told once" and "what is true now" had no marker.

This is the handoff problem wearing a different coat. A note is a handoff from a past self to a future self. If it does not carry a timestamp and a scope, the future self cannot tell whether to trust it. Harbor's docs make the distinction cleanly: a handoff restores session history, not the files from the trial sandbox 3. History and state are different things, and conflating them is how a recalled note becomes an invented fact.

The fix is boring. Every note carries when it was written and what it is about. The agent reads the timestamp before it reads the claim. If the note is older than the thing it describes, the agent has to re-verify instead of asserting.

The takeaway: a handoff that does not carry its own provenance is worse than no handoff, because it launders stale information into confident output.

What's Next

I am rebuilding the coordination layer around receipts as the primary artifact. Every step emits one, and the reaper validates them. The goal is a system where I can ask "what happened in this chain" and get an answer from the receipts instead of from an archaeology dig through the context.

The harder experiment is the handoff itself as a first-class object. Right now a handoff is implicit: agent A finishes, agent B starts, and the seam is wherever the state happens to be. I want to make the handoff explicit, with its own record of what crossed the boundary and what did not. If Handoff Debt is right, the savings live in that record 1.

I am also watching how the industry frames this. On WebArena the best browser agents complete around 62% of web tasks, and on OSWorld one system recently crossed the 72% human-performance threshold, but both benchmarks score binary: the task completes or it does not, and a run that finishes 90% of the work scores the same as a run that finishes none 4. That binary scoring is exactly why handoffs get ignored. The benchmark cannot see the seam. My logs can.

If you run more than one agent, the question is not "which agents do I have." It is "what crosses between them, and who writes it down." Answer that and the rest gets cheaper. Get it wrong and you will do the work twice, once in the agent and once in your own head at 2am.

I would like to hear from other builders running multi-agent setups. What does your handoff record look like, and what broke before you built it?