Answer
How do you debug a multi-agent system?
Reconstruct what each run received and returned, in order. Without that record the investigation is guesswork and ends in a rewrite.
By reconstructing what each run received and what it returned, in order. If that was not recorded, the error cannot be localised, and what happens instead is prompt adjustment until the symptom disappears.
The core difficulty is that a wrong final result can originate in any participant or in any handover, and the handovers are where most of it hides. A worker can answer its brief correctly while the brief was wrong; the main run can interpret a correct answer incorrectly; a summary can drop the qualification that made a finding conditional. All three produce the same symptom and require different fixes.
So the first requirement is a record of the boundaries: for each run, the brief it received and the result it returned, in sequence. This is a small amount of data and it is the difference between an investigation that takes ten minutes and one that does not converge. It is also the thing that gets added after the first serious failure rather than before, which is worth anticipating.
With that record, the procedure is ordinary bisection. Read the final result, find the first claim that is wrong, find where it entered — a worker's output, a main-run inference, a summary — and look at what that participant received. Nearly every multi-run failure localises to a single boundary, and the boundary is usually a brief that was ambiguous rather than a run that performed badly.
That last point is worth emphasising because it changes what gets fixed. The instinct is to adjust the run that produced the wrong output. More often the run answered exactly what it was asked, and the fix belongs in the brief or in the division of work. Adjusting the worker in that case makes the symptom go away for one input shape and leaves the ambiguity in place.
Reproducibility is the other structural problem. These systems are not deterministic, so a failure may not recur, and a fix cannot be confirmed by a single successful run. The workable approach is to replay the exact brief that produced the failure against the worker in isolation, which does reproduce reliably enough to be informative, and which also tells you whether the problem was the brief or the run.
Finally, resist debugging by adding a participant. A reviewer added to catch the class of error you just saw is a plausible response and it adds another boundary, another summary and another thing to trace. Where a check is needed, a deterministic one at the boundary — the result must contain these fields, must reference a real file, must cover every input — is cheaper and does not add a participant.
Without a record of what each run was told, debugging a multi-agent system is indistinguishable from redesigning it.
Siddharth Sharma, Context Theory
Related questions
What should be logged at minimum?
For every delegated run: the brief verbatim, the result verbatim, and which participant issued and received each. Everything else is optional. The verbatim requirement matters because a paraphrased brief in a log hides exactly the ambiguity you will be looking for.
How do you test a change to a multi-agent system?
Against a set of recorded past inputs, including the ones that previously failed. A single successful run proves very little given the variability, and a suite of replayed cases is the only way to tell whether a change improved anything. This is ordinary regression testing applied to a system where most teams do not think to build it.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
2026 speed-to-lead benchmark · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | A wrong result can originate in a participant or in a handover, and a correct answer to a wrong brief, a misread correct answer, and a summary that dropped a qualification all present identically while requiring different fixes. | Tracing a known incorrect output back through each recorded brief and result to locate where the claim first appeared. |
| Software | Recording each brief and result verbatim at every boundary is what makes bisection possible, and paraphrased logs conceal precisely the ambiguity an investigation is looking for. | Comparing a logged brief against the text actually sent to the delegated run. |
| Response | Most multi-run failures localise to a brief that was ambiguous rather than to a run that performed badly, so adjusting the run removes the symptom for one input shape and leaves the ambiguity in place. | Replaying the failing brief in isolation and checking whether the result was a reasonable reading of it. |
| Constraint | Non-determinism means a failure may not recur and a fix cannot be confirmed by one successful run, so replaying the exact failing brief against the isolated participant is the reliable reproduction method. | Running the same failing brief in isolation several times and comparing the outputs. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one