Fifty Sub-Agents at 95% Gives You a 7.7% Chance

Everyone spawning sub-agents believes the same thing. More agents working at once means the work finishes sooner.

It doesn't. And the reason has nothing to do with models getting better. It's arithmetic you already know from reliability engineering, applied somewhere nobody is applying it.

Say a sub-agent produces correct work 95% of the time. It follows the acceptance criteria. It meets the definition of done. Ninety-five percent feels good.

Chain three of them and you're at 0.95 cubed. Chain ten, which is a normal project, and you're at roughly 60%.

So forty percent of the time, the ten-node version hands you something broken. Not broken in an obvious way. Broken at the end, after everything downstream was already built on top of the mistake.

This is where the belief usually survives. Sequential chains obviously compound. Fan-out feels different, right? The branches don't depend on each other.

They don't need to. They converge.

Say node A creates the database tables. Nodes B through E each build an API endpoint against them. If A is wrong, B through E are all wrong, plus the integration. Same blast radius as sequential.

Now say A is fine but B is wrong. C, D and E survive. The integration still fails.

A fan-out is a ten-piece Lego set. Every piece has to be right for the finished thing to be right. Building them at the same time doesn't change that.

Parallel sub-agents buy you wall-clock time on the individual work items and nothing else. The convergence suffers the same fate as a sequential chain, and now you get to walk backward through five branches to find which one poisoned it.

Which tells you the shape of the graph was never the problem.

Sequential or parallel is the wrong axis. What kills you is the number of nodes, because that's the exponent.

Which leaves two levers. Reduce the node count, or push the base closer to 1.

Reducing node count fights the entire reason you wanted agents. So the base is the real work.

Tight ADRs, PRDs, specifications. Story arcs that cut the build into slices you can actually demo, and work packages bounded by a token ceiling so no single item balloons. All of those push the base up and all of them matter.

But no amount of prompt quality gets an LLM to a reliable 1.0, because prompt quality was never a safety control. You can't prompt-engineer your way to a guarantee.

A node cannot be allowed to declare its own success.

Every work item gets a test node attached. Deterministic validators that must pass before that node counts as complete and before anything downstream is permitted to start. Fail, and it loops. Retry, re-run the validators, repeat until it passes.

The effect on the graph is the whole point. Under the old model, node A silently produces bad work and B through E inherit it. Under a gated graph, A never releases the downstream nodes at all. Failure stays at the node that caused it.

Which means the integration arrives near 100%, bounded only by how good your test suite is.

That last clause is doing a lot of work. It is also where almost everyone breaks this.

Almost everyone doing agentic coding writes tests. Very few write them correctly, and it comes down to one thing.

The test must be created in a different context from the work it is testing. Same context, same blind spot.

If the agent that wrote the code also writes the test in that context, it inherits the reasoning that produced the bug. It will confidently verify its own misunderstanding.

There's a second failure underneath it. Model correlation. If the model leaned a particular way while coding, it leans the same way while testing. The test agrees with the bug.

And the validators have to be deterministic code, not an LLM judging output. A probabilistic checker will sometimes tell you something passed when it didn't. An agent's word is not evidence.

That much I knew going in. The next part I worked out mid-sentence on a call, and it deleted a component I thought was mandatory.

I was walking a colleague through this on a call and said something out loud that I hadn't fully worked out until it left my mouth.

If every node checks its own dependencies before it runs, you don't need an orchestrator.

Think about what an orchestrator does. It watches the graph, decides who goes next, and dispatches. That's it. Now give each agent the ability to read the graph itself.

The agent responsible for the API endpoint wakes up. It knows it depends on the database tables passing their unit tests. It checks. Not done. So it goes back to sleep. Fifteen seconds later it wakes up and checks again. Still not done. Sleeps. Wakes. Now it's done, so it runs.

The gate is not an LLM call. It's "did the tests pass, yes or no." Cheap, deterministic, and it costs nothing while the agent sleeps.

That's the difference between a swarm and a DAG. A swarm pays coordination cost, accumulates entropy, and asks agents to evaluate themselves. A DAG has directed edges that enforce order and no cycles, so nothing can loop forever. The dependency structure does the managing.

Remember, all of this rests on one thing. The gate is only worth what the validators inside it are worth. So here's how those actually get written.

Three passes, all in the human-in-the-loop stage, before any code is generated.

Scenario-based acceptance criteria. Ask the model to enumerate what this piece of code could actually encounter. For a login: wrong username, wrong password, password too short, too long. LLMs are genuinely good at this. The human prunes the scenarios that can't happen.

Red teaming. Take every scenario and attack it. Push it, question it, try to break it.

Requirements traceability audit. This catches the opposite failure. Red teaming can only challenge what you wrote down. The traceability audit asks what your objective was and tells you what's missing from it. One checks what you decided. The other finds what you forgot to decide.

Then it gets red teamed again. The output is coverage high enough that the gate means something, because the entire system is only as good as its validators.

Somebody pushed back on this design and I want to give you their objections, because two of the three are good.

Waking up 70% done sounds worse than waking up finished. It isn't. The alternative is waking to "complete," starting QA, and discovering something broke early enough that everything after it is garbage. Correcting an agent at the moment it fails is far cheaper than unwinding a finished build.

Everyone is asking whether AI can be trusted. That's the wrong question, and it's why so much of this goes badly.

That's why the gate exists, why the test lives in a separate context, and why the validators are deterministic. Every one of those removes a place where a claim goes unchecked.

Chris