Part one of this series made the case that the brief you hand a fleet agent is an interface: a typed, validated contract rather than a paragraph of hopes. You can check a brief automatically, before any work starts. What comes back cannot be checked that way. This post is about what comes back, and about the failures that arrive looking like finished work.
A quick reminder of the cast from part one: the orchestrator authors the briefs and spreads the work across its subagents, while I operate from above as the operator, aiming the system and judging what returns.
A single agent fails in ways you notice. It throws an error, or it stops, or it hands you something so clearly off that you catch it, because you are reading the one answer it gave. A crowd is different. With six agents you are not reading every line of every output, you are skimming six summaries and trusting the rest. That trust is exactly where this class of problem lives: the failures that pass for success. These are the ones that have actually bitten me, each with the guard it forced me to build.
The agent that researches itself to death. This was the empty-folder story from part one, but it is worth naming as a category, because it is the template for all the others. The agent did not fail. It worked hard the entire time and produced nothing. The guard is the reserved write budget, now enforced as a field rather than hoped for as a sentence. The pattern to notice: in a crowd, “busy” and “productive” are not the same thing, and you cannot tell them apart from a summary.
The confident, invented citation. Research agents cite sources. They also make sources up, and they do it more the harder they work. There is real measurement on this now: frontier models’ citation accuracy sits somewhere in the rough range of 40 to 80 percent depending on the task, and, here is what makes it a fleet problem, it gets worse as the number of tool calls climbs. The more an agent does, the more likely its citations are decoration. So I added a step that nobody likes and everybody needs: at synthesis, I sample citations from each agent’s report, re-fetch the actual source, and check that the claim is really in there. Hallucinated citations are not an anomaly to be surprised by. They are the baseline behavior, and the check is mandatory for any report I intend to stake a conclusion on.
The bug that does not exist. When I point a fleet at a real codebase, agents will sometimes report a specific bug at a specific file and line, in confident, precise language. A good chunk of those disappear the moment someone actually runs the code and watches what it does. The agent pattern-matched its way to a plausible defect and described it as fact. The cost of believing it is not zero: I could file that “bug” to an engineer who then builds a fix for a thing that was never broken. So the standing rule is dull, and I keep it anyway. No claim about a specific line of shipped code goes anywhere until someone has run that code and seen the failure with their own eyes. Claims that survive move forward. Claims that do not get written down next to the evidence that killed them, so nobody spends a day next month rediscovering the same false alarm.
The orchestrator forgetting what it launched. This one is structural. The orchestrator is itself a model with a limited context, and on a big dispatch the instructions that sent the fleet out can fall out of that context before the workers return. The orchestrator has, in effect, forgotten which agents it sent and what they were supposed to produce. The guard is to keep that state somewhere other than the model’s memory. Before the fleet goes out, a small manifest file is written to disk: the agents, their output paths, their status. On recovery, you read the manifest, check which output files exist, and relaunch only the missing ones. The recoverable state lives on the filesystem, never in the orchestrator’s head.
Look at what the four have in common. Not one of them is a crash, or an error, or anything that announces itself. Every one is the machine handing me polished work with a flaw buried inside, and the only reason the flaw nearly got through is that it arrived inside a tidy summary from a crowd I could not fully read. The guards are not about making the agents smarter. They are about refusing to trust output I have not checked, and baking the checks into the pipeline so suspicion is never left to my memory.
Which sets up the question a reasonable person should be asking by now. If the workers invent sources, describe defects that were never there, and can burn a whole budget producing nothing, why run a crowd in the first place? Because a crowd, pointed the right way, produces a kind of evidence no single agent can give you. That is the last post in this series.