Monolithic AI agents keep failing, and practitioners have stopped waiting for a better model to fix that

The failure mode of monolithic AI agents shows up the same way across domains. One model, one context window, one point of failure. When any sub-task hits a wall, whether through hallucination, an API timeout, or a prompt that has grown too large to reason over, the whole system stalls. The pattern is consistent enough that practitioners in robotics, enterprise software, customer service, and developer tooling have all arrived at the same architectural answer: distribute the work, specialize the agents, and coordinate the result.

Walden Yan, whose work involves production code testing at scale, puts the core problem plainly. In some cases, no one frontier model can actually do the full end-to-end task itself, and his team has had to orchestrate different frontier models together to solve the problem. That observation carries weight because it comes from direct deployment, not from a benchmark. When even the best available models fall short on their own, the solution is not to wait for a better model. It is to build a system that distributes the task across several of them.

Yasser Elsaid, working in customer service AI, adds a number that reframes where the actual engineering problem lives. Ninety-five percent of the limitation, he argues, is not from the model. It is from the harness, meaning the orchestration and integration layer that coordinates what the model does. Logan Kilpatrick describes the same shift from the supply side: the model is chained with the harness, and the harness is what powers agentic product experiences. The era of shipping a standalone model and calling it an agent is over.

95% of the limitation is not from the model. It's from the harness. Yasser Elsaid

Production deployments make the architecture concrete. Vijoy Pandey reports that a multi-agent system his team runs has fully agentified 40 percent of the tasks the team handles, cut team load by 30 percent, and reduced response time from hours to instantaneous. Patrick Collison describes a single Stripe engineer orchestrating 16 simultaneous agents from one screen, going considerably faster than before. Robert Playter, chief executive of Boston Dynamics, explains the company’s approach as two distinct brains: the brain controlling the physical robot lives on-device, handling dynamic movement and manipulation, while a reasoning layer providing semantic understanding of the environment runs in the cloud. Neither brain could do the other’s job.

The coordination discipline required is not trivial, and practitioners are candid about that. Jesse Genet built a team of five agents, each running on its own Mac Mini, and had to explicitly train them to respond in succession rather than all at once, teaching each one to detect when another is still processing before it replies. Greg Isenberg describes a routine in which he spawns five parallel sub-agents, each pulling from a different source, before aggregating results back to a main agent. Reynold Xin, at Databricks, notes that before the company standardized, five or six different agentic frameworks had been built independently by different internal teams. The multi-agent approach solves the capability problem but introduces a coordination problem that has to be solved deliberately.

Olive Song describes a fragility that runs in the opposite direction. An agent trained to appear capable in one scaffold stops generalizing when that scaffold changes even slightly. That is a warning about over-optimizing for a particular harness configuration rather than building for robustness across configurations. The lesson is that specialization has to be paired with fault tolerance at the system level, not just at the model level.

Cat Wu adds a timeline dimension. It was only with certain more recent model versions that her team felt able to run multiple code review agents simultaneously across an entire codebase and get results reliable enough to act on before a merge. The underlying models matter. But the architecture that coordinates them matters just as much, and in Yasser Elsaid’s framing, more. What the evidence collectively points toward is not a temporary workaround while better models arrive. It is a durable architectural principle: reliability at scale requires dividing the work, assigning it to agents built for specific tasks, and investing as much engineering discipline in the coordination layer as in the models themselves.