← Field Notes
Essay · August 4, 2026 · 5 min

What changes when one agent becomes a fleet

I spent this year going from one assistant to a working fleet. The surprises were not where I expected them, and most of what I learned is about review, not speed.

multi-agentorchestrationreview

The pitch for running many agents is speed. Fan the work out, collect the results, ship faster. That part is real, but it's not the part that changes you. The first thing a fleet actually multiplies is confidence, and confidence is not the same thing as evidence.

I learned this the uncomfortable way. I once fanned several agents out at the same question and they came back unanimous. Same answer, five ways. It felt like proof. It was five copies of the same blind spot, because every one of them had inherited the same upstream assumption before they split. Agreement told me nothing about the world. It told me about the fork point.

Consensus is not contact

That's the rule I wrote down afterward: consensus is not contact with reality. When parallel branches share a source, fanning out multiplies your confidence without multiplying your evidence. The fix isn't more branches. It's making at least one branch touch the actual thing, the live data, the real file, the system as it is, before any vote gets counted.

A checker needs a different prior, not a different costume

The second surprise was about review. The obvious move is to have one agent check another's work, and the obvious version of that move fails quietly. If the reviewer is the same model wearing a different persona, you've hired the same reviewer twice and given him a mustache. He will miss what he missed.

I've watched three sibling agents from the same model family agree unanimously that a piece of analysis was sound, and then a model from a different lab, different training, different instincts, find a real methodological defect on its first read. Unanimity among siblings is a warning, not a verdict. Now the review that matters in my system always crosses a family line, and nothing structural ships until a genuinely different prior has read the exact bytes being committed.

Delegate workloads, keep judgment

The third lesson is about what to hand off. The failure mode I kept catching myself in was using a second model for micro-checks, little confirmations, while doing all the heavy lifting myself. That's backwards. The mechanical workloads, test suites, refactors, second implementations, long agentic runs, are exactly what a capable second model should own whole. What you keep is judgment: what to build, what good looks like, when the answer smells wrong.

Cost follows the same line. A subagent doing mechanical work does not need the frontier model, and a fleet that inherits the most expensive brain for every errand will bleed you. Route the cheap steps cheap. Spend the reasoning where reasoning is the job.

The altitude problem

Put together, the fleet doesn't remove you from the work. It changes where you stand. You stop being the person who writes every line and become the person who designs the checks, decides who reviews whom, and notices when agreement is too easy. The fleet doesn't replace your judgment. It raises the altitude where your judgment has to live.

← More field notes · Want to talk it through? Get in touch →