Teams test what the model writes. Almost nobody tests the system the model runs inside. That gap is where agent architectures actually break.
August 5, 2026Multi-AgentFault InjectionReliability
Evals score answers. Simulation scores the system your agents run inside.
The part of the experiment that got the least attention
Robert C. Martin recently described an orchestration harness he has been building: a squad of agents with a fixed workflow, expressed as a finite state machine. Most of the discussion focused on the roster of agent roles.
The more interesting detail came after. He had the agents build a simulator of the squad itself, drove that simulator through the state machine, introduced delays and failures, and ran Monte Carlo testing across many runs. His observation was that the agents would not have proposed that testing regime on their own.
Set aside the debate about how much of software engineering survives AI. The mechanically useful idea is this: he tested the system the agents run inside, rather than only the output the agents produce. That is rare, and it is the practice most agent projects are missing.
Evals are necessary. They are not sufficient.
Golden datasets, regression suites, and scored rubrics answer one question: given this input, was the answer good? That question matters, and a system without it is not serious. But it says nothing about what happens when the third agent times out, when a message is delivered twice, or when two workers finish out of order.
What you inherit the moment you add a second agent
A single agent calling tools in sequence is a program. Several agents exchanging messages through queues, with retries and timeouts, is a distributed system. That is not a metaphor. It is a category, and it comes with decades of well-documented failure modes that arrive whether or not the team planned for them.
Partial failure
Agent 3 dies after agent 2 already wrote to the ticket. Half the workflow happened. Nothing knows how to finish or undo it.
Timeouts
A slow worker is assumed dead, the task is reassigned, and now two agents are doing the same job with different assumptions.
Duplicated side effects
A retry looks harmless until the action was not idempotent. The PR is opened twice, the refund is issued twice, the alert fires twice.
Write conflicts
Two workers edit the same file or the same record. Last write wins, and the losing work disappears without an error.
Split state
The queue, the database, and the agent context each hold a different version of the truth. The system is consistent nowhere.
None of these appear in an eval, because an eval runs the happy path with a healthy system. They appear under load, latency, and bad luck, which is to say in production.
Non-determinism is not the hard part
Model output varies, and that gets most of the attention. But the harder source of variance in an agent system is timing. Two runs with identical prompts can take different paths because one worker responded slightly slower, a retry landed in a different order, or a queue delivered a message twice.
Timing-dependent bugs are not reproducible by rerunning the same input, which is why they survive normal testing and surface later as incidents nobody can explain.
The method is thirty years old
Distributed systems engineering already solved how to find these bugs before users do. The techniques predate this wave of AI by decades and apply without modification.
Step 1
Model the workflow as a state machine
Write down the states and the legal transitions. This step alone usually exposes paths nobody intended to allow.
Step 2
Simulate the system, not the model
Replace each agent with a stub that returns plausible results. You are testing the orchestration, so no inference calls are required, which makes runs fast and free.
Step 3
Inject jitter
Add random delays, dropped messages, dead workers, and out-of-order completions. Real systems fail this way, so the simulator should too.
Step 4
Run Monte Carlo
Execute thousands of randomized runs and look at the tail, not the average. The interesting failures live in the last percent.
What the runs surface
Deadlocks where two states each wait for the other
Unreachable states that were never supposed to exist
Paths that only fail on the four hundredth run
Retry storms that multiply cost under load
Workflows that complete successfully with incomplete work
Why the simulator is cheap
The objection is usually cost. Running a workflow thousands of times against a real model would be slow and expensive.
It would, which is why the simulator does not call the model. Each agent is replaced with a stub that returns a plausible result after a randomized delay, and sometimes returns nothing at all. What is being tested is the orchestration: the state machine, the queues, the retries, the recovery paths. Those runs cost close to nothing and finish in seconds.
Model quality and system reliability are separate problems. Evals cover the first. Simulation covers the second. Trying to test both at once produces slow suites that answer neither question well.
A smaller version of the same idea
Most teams do not need a full Monte Carlo harness on day one. The useful first step is much cheaper: write the workflow down as explicit states and transitions, then ask what happens if each step fails, times out, or runs twice.
That exercise usually surfaces two or three paths with no defined behavior at all. Those are the incidents waiting to happen, and they were found on a whiteboard rather than in production.
The point
The reliability of an agent system is decided by its orchestration far more than by the reasoning quality of any single agent. Better models will not remove partial failure, duplicate delivery, or inconsistent state, because those are properties of the architecture rather than of the model.
If you cannot say what happens when the third agent times out, you do not have an architecture yet. You have a demo that has not failed in front of a customer.
Running agents in production?
LetuxTech designs agent systems as distributed systems: explicit workflow states, idempotent actions, recovery paths, permission boundaries, and audit trails.
We can model your current workflow, simulate it under failure, and show you where it breaks before your customers find out.
The simulation and Monte Carlo experiment described at the start was published by Robert C. Martin on X in August 2026. Related reading on this site: splitting agents by blast radius.
