On the Phased HandoffWhen One Agent Is Not Enough, Divide the Work, Don’t Just Add More

For a while, “multi-agent collaboration” was a phrase I heard everywhere.

I saw plenty of descriptions like this: start three agents and have them write the same feature in parallel. It sounds impressive. But once you actually try it, you find that each agent sees only its own part, their outputs overwrite one another, and there are more merge conflicts than if one had written the whole thing from scratch. In the end, someone still has to sit down, line up the three versions line by line, and piece them back into something that runs. After all that, what exactly did we save?

That is not what I do.

Real Multi-Agent Work Is a Relay, Not a Side-by-Side Effort

The process I usually follow now goes roughly like this: Claude handles the main implementation. At a certain point, I gather the current state into a handoff note, switch to Codex for an independent review, then open a fresh Claude session to take over acceptance checks, and finally deploy.

Nowhere in this chain are “two agents typing at the same time.” At any given moment, only one is working. What differs is the role: one moves the work forward, one looks for faults, and one brings it to a close.

Why does it have to work this way? Because there is a limit to how much context a model can hold in its head at once. A truly complex task often will not fit into a single session from beginning to end. By the second half, details from the first half have been pushed out of the context window, and the model itself can no longer remember all its earlier decisions. The only way is to write that state down outside the session, in documents and version history, so the next session can pick it up from there.

This is no compromise forced on us by technology. It is a discipline we have to maintain ourselves: when it is time to hand off, faithfully put the state into writing instead of struggling to finish everything in one session.

Reviewing Your Own Work Is Not Enough

At first, I thought a model reviewing its own work would be enough: research the background, draft a plan, then go through several rounds of close review until it settles. That should make it sound.

Then, one time, I had a plan for fixing more than twenty bugs. After reviewing it back and forth for several rounds, the model told me: it has more or less settled; we can start implementing.

I did not start right away. I gave the plan to Codex exactly as it was and asked for an independent review. In the first round, it found several serious flaws that would halt the process outright, along with a string of lesser problems.

I was not ready to leave it there, so I ran another round. Several entirely new serious flaws. Another round, and there were still more. Round after round, the corrections added up to dozens, every one of them untouched by the earlier self-reviews.

It was not for lack of effort. It could not see what it could not see.

When a model reviews a plan it wrote itself, its thinking is already locked inside that plan’s internal logic. It keeps confirming, “My reasoning is right,” but finds it hard to step outside and ask, “What if I started from the wrong place?” It is much like editing a piece you have just written yourself. You can catch the typos, but the real structural problems are almost invisible to you.

What a Fresh Session Can See on a Cold Read

Here are a few recurring kinds of blind spot. All of them actually happened.

Misreading transaction boundaries. The model sees a transaction commit call in a reading window of a few dozen lines and decides that the function is transaction-safe on its own. Only when another session searches the entire file does it become clear that the outer caller is what actually commits the transaction. The line inside the function is a remnant of an earlier test. The window was too small: it saw a part and took it for the whole.

Inventing a nonexistent interface from memory. The plan confidently says to “get the history ID from a certain field on a returned object.” The field name sounds perfectly natural and reasonable, but there is no such thing in the code. The model “thought it up” from its training memory: a field that looks as though it ought to exist, but does not.

Getting the case of enum values wrong. The actual enum values in the code are lowercase; the plan casually writes them in all caps. You do not notice it by reading alone without running tests. Run them, and a database constraint rejects it immediately.

Inventing a filename by intuition. The plan says to “backfill a certain initialization script,” complete with an authoritative-looking number in the filename. In the actual repository, the script numbers in that directory do not even begin with that number. The file does not exist. The name sounds right; listing the directory gives it away.

These are not random glitches. They are structural blind spots: the model simply cannot see them in its own plan. Yet put that plan into a fresh session with no memory of it, give it a cold read, and combine that with full-text searches, close reading of each file, and checks against the actual environment, and the problems turn up on the spot. The difference is not who is smarter. One is standing inside the plan; the other is outside it, trusting no existing account and checking every conclusion against the live environment.

A Handoff Note Is a Protocol, Not a Work Summary

For whoever takes over to review independently, the handoff note cannot just be a running account of “what I did.” It has to be a protocol: a clear statement of what you may and may not do after taking over, and how to establish the current state for yourself.

From:         Previous session
To:           Next session (human or agent)
Boundary:     Verify only; do not implement
Code version: <TBD: fill in after committing>

## Completed
Use the actual version history as the source of truth. Do not trust the figures in the snapshot below.

## Recovery steps
Pull the latest code
Read the recent commit history
Check the current state against the actual environment

## To do
First run the recovery steps above to establish the latest state, then decide accordingly.

There are two things here that I only learned to include after getting them wrong.

First, never put the actual value from that moment in the code version field. The first thing whoever takes over must do is pull the latest code. Fixing an old value in the note does not help; it misleads them into judging against an anchor that is already out of date. Any metadata that can drift with time, such as version numbers, deployment status, or how many items remain, should be marked as pending. Tell the next person explicitly: trust what you verify for yourself, not the state I recorded at the moment of writing. I learned this by stumbling over it: some information in one handoff was still valid when it was written, but by the time the previous session had committed its work, those figures were all stale. Anyone taking them at face value would have been led astray.

Second, the boundary field must leave no room for doubt: “You only verify; you do not implement.” Without that sentence, the reviewer reads the plan, gets the itch to act, edits a pile of files and commits them, and the whole chain falls into disorder. Its job is to look for faults with a cool eye, not to take over along the way.

The care this kind of writing takes is much the same as learning to write a proper commit message. It is not written for yourself at this moment. Its real reader is some agent at another time, or perhaps me a few months later, when I have forgotten all the details. The traces left for that person must let them pick up the work without having to ask follow-up questions.

The Traps I Actually Fell Into

A few traps I have stumbled into on this path, left here for whoever comes next.

One is receiving the instruction “do it all” and stubbornly trying to finish a large change across several services in a single session, pressing on until the context window overflows, then rushing the ending and leaving the work half done.

Another is writing no handoff note and simply saying, “Switch to Codex.” Whoever takes over is completely in the dark. All they can do first is repeat the research from scratch and draft the plan again. Everything the previous session worked so hard to produce goes to waste.

Another is a fresh session taking over and starting work without reading the handoff note. It reinvents the wheel, then falls into exactly the same traps that earlier sessions had painstakingly discovered and recorded.

I have fallen into every one of these myself. So now, before switching sessions, I make myself finish the handoff note first, even if it is only ten lines. Ten lines are still better than leaving the next person to find their way from scratch.

When Assessing a Multi-Agent Workflow, Look First at the Roles

Looking back, the core of “multi-agent collaboration” was never strength in numbers. It was whether the boundaries between roles were clear enough.

The agent doing the main implementation goes deepest, and is also the most likely to become trapped in its own plan. The one looking for faults has no memory, accepts no existing account, and checks every statement against the live environment. It knows nothing when it takes over, and that is precisely its value, not a defect. I am the one coordinating: deciding when to switch, when to wrap up, and who should handle each stage.

The most worthwhile multi-agent collaboration does not force one agent to do more. It lets each agent do only the stage it is best at, while leaving one another traces that fit together exactly. The first part determines how far the work can go; the second determines whether this way of working holds up at all.

Translation log: translated from the Chinese original by Codex on 2026-11-03, 17:51–17:54 (US Eastern). Main thread GPT-6 Astra (gpt-6-astra), reasoning effort ultra; it spawned 1 sub-thread: 1 on GPT-6 Astra (effort ultra). Together they read 446,805 tokens (418,944 of them from cache) and wrote 6,938 (1,135 of them reasoning).