Look at any team chart and you will see ten people. Ten desks, ten salaries, ten threads of attention.
Now give each person ten agents. The chart still says ten. The working system says something the chart has no box for: a hundred threads of execution, steered by ten judgment layers.
Nothing about the job descriptions changed on paper. Everything about the job changed in practice. This post is about what that team can do, what it cannot do, and why the second list matters more than the first.
The desk assumption
Organizations are woven from a single assumption: one person, one desk, one thread of attention. Processes are shaped around it. Spans of control count it. Planning is done in full-time equivalents, which is a way of saying: how many threads can we afford.
The assumption was so total that nobody had to state it. A thread was a person, and a person could only be in one conversation, make one call, and hold one problem at a time. Every management model in use today, including the good ones, is built on the economics of scarce threads.
The machines did not make threads faster. They made threads cheap and simultaneous, and that is a different event.
The numbers, with their dates
Every number in this post carries a date, because these numbers move monthly. Quote them with dates or do not quote them at all.
| Capability | Number | Source and date |
|---|---|---|
| Human typing | About 40 words a minute on average, about 100 for the fast | Standard measures, stable for decades |
| Human reading | About 238 words a minute, silent reading | Brysbaert meta-analysis, 2019 |
| Machine writing | About 280 tokens a second on mainstream APIs, 2,000 to 3,000 on the fastest, as of 2026 | Published inference benchmarks, 2026 |
| Machine task horizon | Length of task completed unaided doubling about every 7 months, possibly faster for recent frontier models | METR, March 2025 release and updates |
| Swarm gain | Multi-agent system beat a single agent by 90.2 percent on broad research evaluations | Anthropic Engineering, 2025 |
| Swarm bill | About 15 times the tokens of a single chat for the same task | Anthropic Engineering, 2025 |
| Parallel calls | One thousand simultaneous calls at a few hundred milliseconds of latency, for cents on the minute | Voice agent platforms, 2026 |
| The inversion | Experienced developers took 19 percent longer with AI tools on real work | METR randomized trial, early 2025 |
Read that last row twice. It is the most important number on the board. Speed and scale are real, and they do not land where people expect them to. More on that below.
What a hundred threads actually changes
A member of the old team did work. A member of this team steers it. The day acquires a new shape: write the brief, set the contract, launch the agents, read the evidence, decide, escalate, and only occasionally do the thing yourself.
The team's capacity math changes in kind, not just in size. Ten people running ten agents each do not produce ten times the old output. They produce something the old team could not attempt at all: a hundred parallel experiments, a hundred client conversations in the same minute, a hundred drafts reviewed by one judgment instead of written by ten hands.
That is the fabric change. The unit of work was a person-week. It is becoming a steered thread-hour. Anything planned, priced, or managed in person-weeks is measuring the wrong substance.
What does not multiply
Here is the honest half of the post. The multiply lands only where the bottleneck actually is, and most teams misplace it.
The review layer does not scale with generation. A hundred threads produce a hundred streams to verify, and verification is still mostly judgment, and judgment is still human, trained, and slow on purpose. The team that multiplies threads without multiplying verification capacity has not built a hundred-worker team. It has built a hundred-open-loops team.
Judgment itself does not transfer or compress, as the ground series argued: it is trained locally, on real misses, over real time. Ten agents inherit the judgment of the one person briefing them, no more.
And the trial numbers agree. In the METR study above, experienced developers with real repositories got slower, not faster, when the speed was added at the wrong node. Adding a hundred threads to a team whose constraint is decision quality does not multiply the team. It multiplies the queue.
Parallel output without verification capacity is just confident wrong output at industrial scale.
The steering skills
The new member capability is not prompting. It is leading software.
- Write the contract per agent: what done means, what evidence proves it, what the agent may invent, what happens when it fails. The done-contract fields apply to every thread.
- Shadow-run before trusted-run: the first cycle of any agent's work gets human review of everything, and the review tightens as the evidence earns it.
- Read evidence logs the way a lead reads a team's work, weekly, looking for drift rather than incidents.
- Escalate honestly in both directions: the agent escalates thin evidence up, and the member escalates unclear direction up, rather than inventing either one.
That list is a management skill set, applied to software. The teams that already lead people well will recognize it. The teams that managed by proximity will find the gap sharp, because agents do not respond to vibe supervision.
What the fabric change looks like
Follow the numbers to their organizational conclusions:
- Spans of control invert. The old question was how many people one manager can steer. The new question is how many threads one steerer can honestly verify.
- Departments become configurations. A phone team that once meant a floor of trained voices now means a fleet making a thousand calls a minute at a few cents each, with humans holding the edge cases. The team is a file someone owns.
- Planning vocabulary changes. Budgets in FTEs answer how many people. The real question is how many threads, calls per minute, tokens per dollar, and who verifies each class of output.
- The middle layer changes role. When agents execute, the layer that only passed information between floors loses its job. The layer that sets direction, writes contracts, and arbitrates escalation becomes more valuable, not less.
One caution belongs next to the excitement. Concurrency is not relationship. A thousand calls in a minute is reach, not trust, and the part of any organization that runs on village rather than process does not parallelize at any price.
The loop for a ten-by-ten team
- One contract per agent, written before the work: done, authority, failure, evidence.
- Shadow-run the first cycle, trusted-run after the evidence earns it.
- Verification capacity budgeted like payroll, because it is the actual constraint.
- A monthly bottleneck check: where did the queue move this month? Generation, verification, or decision?
- Plan the next quarter in threads, calls, and tokens, with the FTE number as a footnote rather than the headline.
The teams that run this loop will not describe themselves as ten people using AI. They will describe themselves as something the old chart cannot draw: ten judgment layers steering a hundred threads, with the constraint in plain sight and the bottleneck on purpose.
FAQ
Is this just saying AI lets everyone do more?
No, and the difference is the whole point. Doing more keeps the unit of work fixed and adds speed. This change replaces the unit of work: from one attention thread per person to many steered threads per person. Organizations are built from units of work, so changing the unit changes the org, not just the output.
Will ten agents per person not just create chaos?
Uncontracted parallelism is chaos with extra steps. The difference between a fleet and a stampede is the contract layer: what each agent may do, what evidence it must produce, and where it must stop. Teams that skip the contracts do get chaos, and usually blame the agents.
We tried this and saw no gain. What went wrong?
Measure where the queue sits, not how the tooling feels. If output piles up unreviewed, the constraint is verification. If briefs are vague, the constraint is direction. The trial that found experienced developers 19 percent slower did not find that AI is weak. It found that speed added at the wrong node slows the system.
What should a lead measure monthly?
Four numbers: threads actively steered, verification capacity available, where the queue is this month, and what share of agent output carried real evidence when accepted. Those four describe the health of a hundred-thread team better than any headcount report.
Related reading
- The Review Bottleneck Is the Real Cost Center in AI Teams
- Confident Wrong Output Marked Done Is the Agentic Failure Mode
- Agents Should Not Share a Brain
- Judgment Does Not Transfer
- The New Venture Stack: Small Teams and Agent Fleets
- Orchestration Is a Product Surface, Not a Backend Detail
If you are turning a team into a fleet and want the steering layer designed before the threads multiply, book a discovery call.