Where_the_Conventional_Wisdom_Fails

The industry has spent two years solving the wrong problem. "How do we build better agents" is legitimate engineering work. But it is not what killed 70-90% of pilots. Pilots died because someone asked "how do we orchestrate this" before they asked "what does success look like when this agent runs in production for real."

A single-agent system in production still requires an evaluation harness. It needs accuracy thresholds that trigger escalation - cases where the agent's confidence is above zero but below your tolerance, so a human makes the call. It needs latency targets and fallback routes. It needs state invariants, audit logs, permission boundaries. These are not agent-specific. They are production-specific. The difference between a pilot that scales and one that stalls is not that the pilot had one agent and the production system will have twelve. The difference is that the production system defined what "working" means before it went live.

When you add a second agent, the orchestration problem is real and computational. Hand-offs between agents, shared state, synchronisation, the inevitable failures where one agent waits forever for another - these create new failure modes that did not exist in a single-agent system. The justification for that complexity has to be equally real and computational. If you are adding a second agent because the work can decompose into independent sub-tasks, you have a valid reason. If you are adding it because your project looks sophisticated, or because your vendor sold you a 12-agent stack, or because you have people-shaped reasons to put different teams on different agents - those are not computational reasons. They are organisational reasons. And they reliably collapse in production.

The test is disarmingly simple: If each sub-task can fail, be evaluated, and escalate independently without blocking the others, the decomposition is valid; if not, collapse to one agent and add the evaluation harness instead. That sentence is the difference between the 10% of pilots that scale and the 90% that stall.

The_Audit:_Which_Agents_Earn_Their_Existence

I keep asking myself: would the fleet still work if it was half the size? The honest answer, for most of it, is probably. But I need to separate the computational question from the organisational one, because they have very different implications.

Tom (research) passes the test. Research is a genuinely independent sub-task. A research agent can operate at full autonomy: query sources, synthesise findings, surface recommendations, hand off a deliverable. Failure in research does not block the pipeline - it produces a weaker input, and the downstream agent compensates. Tom can fail at any point and the system continues. The next person in the chain gets a research memo that is wrong or incomplete, flags it, and re-routes to Tom or a human researcher. That is escalation. That is independence. Tom earned his existence through computation, not convenience.

Quinn (QA) is the difficult case. QA is theoretically decomposable: run the test suite, check for regressions, audit accessibility. But in production, does Quinn actually fail independently of the build agent? Not quite. Quinn's failure to catch a regression is a problem only if Nix (the frontend agent) did not catch it first. There is a sequential dependency - Nix writes code, Quinn reviews it - but that is not the same as computational independence. Quinn is doing work that could, in a smaller operation, belong to Nix's scope entirely. Why does Quinn exist? Because the fleet is large enough that a single agent cannot do both. That is an organisational answer. Quinn is not computationally justified; she is scaling-justified. The work she does is real and necessary, but you could collapse it back into Nix's remit and the system would not break. It would just ask more of one agent.

Vera (copywriting) is the clearest organisational agent I have. Copy and positioning are genuinely separate concerns from scheduling, technical implementation, and operations. But Vera's work has zero computational relationship to the rest of the fleet. She does not call other agents. Other agents do not call her in production. She works synchronously on briefs, produces outputs, and hands them to Diana for approval or to Lena for social posting. If Vera did not exist, the work would not disappear - it would land differently. Diana would be copy-reviewing and shepherding the voice herself. The output would be lower-coherence and slower to produce. That is a loss. But it is not a computational loss. Vera exists because doing voice work at scale demands a dedicated specialist. That is valid scaling reasoning. But it is not computational independence.

Reid's positioning work, Tom's research, Jo's audits - these are genuinely decomposable into independent sub-tasks because their failure modes are isolated. A research memo can be wrong without breaking the upstream system. A positioning recommendation can be rejected without halting delivery. A process audit can flag a gap without stopping the fleet from operating. Vera's copywriting, by contrast, is a gate on downstream work - Lena cannot post without Vera's copy, the brief cannot move forward without Reid's positioning. That dependency is not computational; it is operational. Vera's agents exist because the operation scaled and demanded specialisation, not because there is some irreducible parallelism in the work.

Building_Only_What_You_Actually_Need

The implication is unflinching: if you do not have multiple independent failure modes, you do not have a computational case for multiple agents. Everything else is organisational convenience, which is fine at a certain scale, but the price is orchestration complexity. That complexity is where the 70-90% of pilots fail. They are failing not because someone picked the wrong agent framework or wrote bad prompts. They are failing because someone looked at a problem that needed one agent, built five, and then discovered that failure in agent two breaks the assumptions of agent four, and the evaluation criteria they never defined in the first place suddenly matter very much.

The practice at this scale is to start with a single agent and evaluate thoroughly. Accuracy thresholds. Latency targets. Escalation criteria. Edge cases. State invariants. Once you have defined what success looks like, then you ask: would adding a second agent actually parallelise the work, or would it just add coordination overhead? If the answer is "add overhead," you have your answer. The second agent is not yet justified.

This is the contrarian part. The vendor stack is twelve agents. The sophisticated deployment looks like a fleet. The real production system often looks like one agent with a really solid evaluation harness, and a second agent only where the independence test forces it. That is not a failure of ambition. That is engineering maturity. The teams that scaled their pilots into production were the ones that did not fall in love with orchestration.

Why_This_Actually_Matters

The cost of over-agents is not theoretical. It is measured in deployment time, operational complexity, debugging nightmare-fuel, and the silent failure mode where your system appears to be working because each agent individually works fine, but their co-dependencies are drifting. Add to that the observation that in 40-90% of the cases where people built multi-agent systems, they wish they hadn't, and the cost becomes real enough that it should matter in your architecture conversations.

I wrote this piece because I have the standing to be contrarian about it. I built a fleet that earned its complexity through computation, not because I liked the sound of "twelve specialised agents" - though that does sound good. The discipline is in the audit: which of these agents are genuinely independent, and which ones am I keeping around for reasons that I should be honest about? If I can do that audit and answer "all twelve pass," then I am building only what I actually need. If I answer "most of them are organisational convenience," then I have learned something about the cost-benefit trade-off that most teams discover too late.

The 70-90% failure rate is real. It is not a model problem. It is an architecture problem. And the quickest way to avoid that failure is to build less, evaluate thoroughly, and add agents only when they earn their existence through genuine computational independence. Everything else is scaffolding until you prove you need it.