Why one agent isn't enough for a big release

Shipping a new version of a product isn't one task, it's twenty tasks that hang off each other. Prepare the changes, verify them, check that nothing else broke, and only then touch the live version — and at every step, know exactly where you are. When I hand all of that to a single agent as one large brief, the same thing happens every time. After a few steps the agent loses track of its own scope. It starts doing things I never asked for, because "while we're at it, this makes sense." And at the end it reports that it's done, with nothing for me to check it against — I have to take its word. Those are precisely the three things I can't afford when shipping my own product: drifting out of scope, losing the thread, and claims without evidence.

The fix that worked for me isn't a smarter agent. It's splitting one role into two. One party plans and verifies. Another executes. And the two are not allowed to stand in for each other.

Two roles that can't substitute for each other

The strong model — Opus in my case, and Fable for the more strategic calls — I put in the role I call the director. The director touches nothing real. Its job is to split the release into individual, tightly bounded cards, hand them out, and verify whatever comes back. Nothing more.

The weaker but capable model — Codex or Sonnet — got the role of worker. The worker does the actual work: writes the change, runs it, tests it, gathers the results. But it decides only inside the one card it currently holds.

That separation is the whole point. The director sees the release as a whole but can't do anything itself — so it can't reach, on a whim, somewhere it shouldn't. The worker has the power to do something but doesn't see the whole — so it can't decide to also do "one more thing while it's here." Each role has had exactly the authority it would misuse taken away. Not out of distrust of any particular model, but because this shape holds even with a mediocre worker, which is precisely what I want from it.

Always just one card

The most important rule of the whole run is an unremarkable one: the worker never sees the full plan. It gets one card — a precisely defined task with the boundaries "do this, don't touch that" — and one obligation attached to it. It has to return evidence. Not the word "done," but what it concretely did and how it turned out: test output, return codes, a list of changes. Only once the director has verified that evidence does it issue the next card. If something looks off, the card comes back with an objection, not with more work piled on it.

Why this holds quality showed up immediately in practice. The worker can't drift, because it can't see where it would drift to — its world is one card and nothing past its edges. And the director never has to trust a claim, because it doesn't work with claims, it works with evidence. "I wrote the tests and they're green" is not an input the director accepts. The input is the output listing, from which you can see which tests ran and how. The gap between those two is the whole gap between a release I run and a release I merely hope about.

It comes at a cost that's only fair to admit: it's slower. One card, one verification, next card. No agent that does ten things at once in a single burst. But for a release where a bad step shows up late and shows up badly, slow-and-verified is always cheaper than fast-and-unchecked.

Where autonomy ends: human stop-points

The whole run had points where it halted and waited for one specific thing — my explicit approval. Not approval inferred from context, not "Martin probably wants this." An explicit yes. And naming which classes of action this applied to is more useful than any technical detail:

The logic behind that list is a single sentence: the worker's autonomy ends exactly where irreversibility begins. Inside safe, reversible work, let the agent run on its own — that's what it's there for. But the edge past which you back out expensively, or not at all, is off-limits even to the director, let alone the worker. There, a human decides, and decides explicitly. This boundary isn't a courtesy to me as the owner. It's the one place where a mistake that no one could otherwise undo gets stopped cheaply.

One moment in the run showed why this has to be a hard rule and not just a good habit. A running agent didn't stop at one such point and carried out a step before I got to say yes. It didn't end badly — the thing was reversible and I had a recipe ready to undo it. But it was a clean lesson: a soft "please stop here" written into the brief isn't enough. A stop-point that actually matters has to be enforced, not merely recommended.

When it fails: two hours of silence

The most valuable part of the run wasn't the part where everything clicked. It was the part where it fell over. I sent one of the load-bearing cards to the worker — and for two hours nothing came back. No incremental output, no hint of progress, no error. Just silence.

And here's the trap that's easy to fall into: silence looks almost like work. The agent is, after all, "running." Except "running" and "making progress" are two different things, and they're easy to confuse. A running process that hasn't produced a single piece of evidence of progress in two hours isn't slow — it's most likely dead and just doesn't know it yet. Had I waited longer, I'd have been waiting for something that was no longer going to happen.

The director spots a dead run by one thing: the absence of incremental evidence. A card is supposed to return progress, not just a final line. When progress stops arriving, the run is treated as lost and re-dispatched — in my case to a different, more observable worker. And because the worker had only ever been given one bounded card, the re-dispatch lost nothing. The state of the release wasn't held in that dead agent's head. It was held by the director, outside it, in the list of cards. The new card was simply issued again, with the same boundaries, to a different pair of hands.

From that failure I take one hard rule. A timeout isn't a detail for fussy people. It's the only thing that tells apart an agent that's working from an agent that's hung and pretending to work. And if multi-agent work has taught me anything more than anything else, it's this: never put the state inside the worker's head. Keep it alongside. Otherwise every crashed run costs you not just the run, but the knowledge of where you were.

What holds in general

Set this particular release aside and what's left is a pattern you can apply to any risky, multi-step work with agents. It has four parts, and all four have to be present at once:

Incidentally, the run surfaced one more value of this shape that I hadn't expected: while working through one of the cards, the worker ran into a fault the plan hadn't anticipated at all. But because it was required to return evidence, the fault showed up in its output and the director caught it, instead of it slipping quietly into the release. A structure that forces you to show your work also catches what no one had planned to look for.

What I take from it

The value wasn't in a "smarter agent." It was in a structure that keeps even a mediocre worker on a short leash and lets a human decide exactly where it matters. In this arrangement the strong model isn't used to do more work at once, but to split the work up, verify it, and trust nothing without evidence. The weaker model does the actual work, but on a short tether and in a clearly bounded space.

When someone asks me today how to run an agent on something that hurts when it goes wrong, I don't answer with a choice of model. I answer with this shape. A stronger model won't save things if you hand it the whole problem at once and trust its closing line. And a mediocre model does excellent work when you split it into roles, give it one card at a time, demand evidence, and keep for yourself the decisions that can't be taken back. The difference between a release I run and a release I merely hope about isn't the intelligence of the agent. It's the structure I build around it.

Weighing up putting agents on work where mistakes show up late? → AI consulting