Answer
How many agents is too many?
When you can no longer say which one produced a given result, or when the handovers cost more than the division saves.
When you can no longer trace a result to the run that produced it, or when the summaries passed between runs cost more than the division saves. Both limits arrive well before any technical one.
The count is rarely limited by what the machine can do. It is limited by two things that degrade quietly: the ability to attribute a result to its source, and the accumulated cost of the summaries passing between runs. Both worsen with each addition and neither produces an error at any point, so the arrangement gets worse without announcing that it has.
Traceability is the first limit and the more important. When something is wrong, the question is which run produced it and from what input, and answering that requires reading the logs of every participant that could have contributed. At two or three that is feasible. At eight it is a project, and in practice nobody does it, which means the system is no longer being debugged so much as adjusted until the symptom goes away.
Handover cost is the second. Every boundary between runs is a summary written by one party and read by another, and every summary loses something unannounced. Adding a participant adds at least one summary, so information loss grows with the count while the benefit of division does not, and there is a point where the last addition is subtracting.
There is a third limit that is easy to miss: review capacity. Runs producing work that needs human attention are bounded by the attention available, and exceeding it produces a queue of results reviewed lightly, which is worse than fewer results reviewed properly. This binds much earlier than people expect and is the practical constraint in most businesses rather than any of the technical ones.
A useful test before adding another: can you say what this one will do that no existing participant does, and can you say where its output goes and who checks it. If either answer is vague, the addition is structure rather than capability, and structure without a corresponding division of the work makes the system harder to operate for nothing.
The number that survives contact with practice is small — a main run, a small number of workers for evidence-heavy pieces, and possibly a verification pass. Arrangements substantially larger than that exist and generally belong to teams that built the observability first, which is the actual prerequisite and the part that gets skipped.
The number of agents you can run is a compute question; the number you can operate is a question about how many logs you will read.
Siddharth Sharma, Context Theory
Related questions
Does it matter if the agents are identical rather than specialised?
For traceability, yes and favourably: identical workers doing partitioned work are easier to reason about because the question is only which partition, not which behaviour. Specialised participants with different instructions are harder, because a wrong result could be a wrong division of labour rather than a wrong execution.
What should you build before adding more agents?
A way to see what each run received and returned, and a way to attribute a final result to its inputs. Without that, each addition makes the system less operable, and the point at which it becomes unmanageable arrives without warning. This is ordinary observability work and it is the prerequisite that most enthusiasm skips.
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 |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Firms that never responded to a web enquiry at all | 23% | Category-wide |
2026 speed-to-lead benchmark · verified
Oldroyd, McElheran & Elkington, "The Short Life of Online Sales Leads", Harvard Business Review (March 2011) · 1.25M inbound leads across 2,241 US firms · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | Agent count is bounded by traceability and handover cost rather than by compute, and both degrade continuously without producing an error, so the arrangement worsens without any signal that it has. | Attempting to attribute a specific incorrect output to the run that produced it in an existing multi-run arrangement. |
| Software | Each additional participant adds at least one summary boundary, so unannounced information loss grows with the count while the benefit of division does not, producing a point at which the last addition reduces overall quality. | Tracing a required detail through each handover and identifying where it was dropped. |
| Buying behaviour | Review capacity binds earlier than any technical limit, because runs producing work needing human attention are bounded by the attention available, and exceeding it yields lightly reviewed results rather than more throughput. | Comparing the number of results produced per period against the number reviewed at full depth. |
| Response | Identical workers on partitioned work are more traceable than specialised participants, because a wrong result can only be a wrong execution rather than also a wrong division of labour. | Comparing time to locate the source of an error in a partitioned arrangement and a role-specialised one. |
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