Should one agent do the whole job, or should you split it?

The argument for using more than one AI coding tool is usually made badly. It is made as a leaderboard argument: this one scores higher on that benchmark, so use it for the hard things.

That is not the reason, and following it produces a worse setup than picking one and staying put.

The real difference is shape, not intelligence

Coding harnesses differ far more in how they work than in how well the underlying model reasons. Some are built for a long unattended run: they take a goal, work for an hour, and hand back a branch. Others are built for a tight loop: you watch every edit, redirect after each one, and the value is that you can steer mid-thought.

Those are not two grades of the same product. They are two different tools, and they are good at opposite things. A long-run harness given a two-line fix will produce a plan, a test, and a summary for work that took one edit. An interactive harness given an eight-hour refactor will ask you a question every ninety seconds until you stop paying attention, at which point it stops being supervised at all.

The question to ask is not which is better. It is which shape of work you are handing it.

What a handoff costs

Every boundary between two agents is a place where context is dropped. This is the part that does not appear in the plan.

What crosses a boundary cleanly: files, commits, tests, anything written down. What does not cross: the three approaches the first agent tried and rejected, the reason a module is shaped strangely, the fact that the user's instruction was ambiguous and a call was made. That reasoning existed in the first agent's context and dies with it.

The visible symptom is the second agent confidently undoing a decision the first one made for a good reason nobody recorded. It looks like the second tool being worse. It is the boundary being in the wrong place.

Put boundaries where work pauses

A handoff at a natural pause — a plan agreed, a branch green, a milestone reached — needs only a summary to cross, because the state is already externalised in artifacts. A handoff mid-task needs the entire working state, which is precisely the thing that cannot be summarised.

So the practical rule: split along the seams the work already has. If you find yourself writing a long brief to get the second agent up to speed, the boundary is in the wrong place — move it earlier, to the last point where a short brief would have sufficed.

A routing policy that holds up

Three questions, in order:

• How long can this run unattended? If the answer is hours, it needs a harness built for sessions and durable state, not one built for a conversation.
• How much do I need to steer? Exploratory work where you will change your mind wants the interactive loop. Well-specified work does not.
• What does it need to touch? Some work is gated by access — to a database, a browser, an internal service — and that constraint outranks preference.

Nothing in that list is a benchmark score, and that is the point.

When one tool is the right answer

Most of the time, for most teams. A split has a fixed overhead — two sets of conventions, two sets of habits, two places for context to leak — and that overhead is paid on every task while the benefit accrues only on the ones where fit actually differs.

The honest test: look at last month's work and sort it by shape. If it is all one shape, you have your answer, and the second tool is a distraction. If it splits cleanly into two piles with different requirements, routing is worth its handoff cost — provided you put the boundary where the work already pauses.