A team buys the fastest model on the market and six weeks later nothing has really changed. The tool answers in seconds. The work still ships on the same schedule it always did, and the queue of things waiting for a decision is longer, not shorter.
The disappointment has a clean diagnosis. The team bought speed, and speed is the wrong axis. A faster tool makes one thread faster. The change that rewrites how organizations work is not fast threads. It is many threads: parallel, simultaneous, steered by one person. Conflating the two is why every capability multiple you have ever heard quoted in a meeting has failed to show up in someone's quarterly numbers.
Two axes, one confusion
Speed and parallelism are different axes, and every capability number sits on one or the other:
- A model writing at 2,000 tokens a second is a speed number. It describes one thread going quickly.
- A thousand phone calls happening at the same moment is a parallelism number. It describes a thousand threads at once.
Speed improves the experience of waiting. Parallelism changes what can be attempted. Reading a draft in one second instead of ten is pleasant and changes almost nothing. Reading ten thousand drafts overnight, each one checked, is a different working life.
The confusion is expensive because the two axes need opposite investments. Speed wants better tools. Parallelism wants contracts, verification capacity, and ownership, which is to say management. A team that buys speed and expects parallelism is confused about what it purchased.
Why the fast thread disappoints
A fast thread still feeds the same downstream queue. The draft arrives in one second and waits six days for review. The analysis finishes in minutes and waits a week for a decision. The work moved to where the constraint always was, and the constraint is bored now, not busy.
The METR trial made this measurable in early 2025: experienced developers, on their own real repositories, finished 19 percent slower with AI tools in the loop. Not because the tools were slow. Because the speed landed upstream of the real constraint, which was understanding the codebase, and the extra flow just accumulated downstream.
Speed added at the wrong node does not multiply a system. It decorates it.
Where parallelism is real
Parallelism is not a slogan either. It shows up where the work has a shape:
- The task splits into independent pieces. Research across many sources, outreach across many leads, variants of a design, tests across many cases. A lead agent spawning three to five subagents, the pattern Anthropic described in 2025, is the natural shape of this work.
- Each piece can be verified against a standard. Parallel work without a shared definition of done is parallel guessing.
- Nobody has to hold all the pieces in one head. The moment the pieces need one shared context to make sense, the swarm thins out, because agents should not share a brain.
When those conditions hold, the multiples are real, and they arrive with their bill. Anthropic's multi-agent system beat a single agent by 90.2 percent on broad research evaluations and used about fifteen times the tokens doing it. Parallelism is bought, and the price is paid in verification capacity and in money, not in adjectives.
The one test worth running
Forget the benchmarks for a week and run the queue test instead:
- Pick the work you hope to multiply.
- Follow one unit of it end to end and mark every place it waits. Waiting for review. Waiting for a decision. Waiting for access. Waiting for a meeting.
- The longest wait is your constraint. That is the only place where new capacity, human or machine, changes the output.
If the wait is at generation, the fastest tool on the market will feel like magic for a quarter. If the wait is anywhere else, the same tool will feel like noise, and the fix is a management fix: contracts, verification capacity, decision rights.
FAQ
So should we stop caring about model speed?
Care about latency where a human is waiting in the loop, because there speed is the experience. Care about it much less in batch and background work, where the thread runs while nobody watches. Past a few hundred tokens a second, faster output mostly means the human eye becomes the bottleneck, and the eye was never the problem you were solving.
Is parallelism just for big companies with budgets?
The 15x token bill is real, but so is the trend of unit prices falling roughly ten times a year, dated a16z, November 2024. The cheaper gate is not money. It is management shape: can the task be split honestly, does each piece have a definition of done, and is there one named person who reads the results? Small teams with that shape run circles around big teams without it.
We added parallel agents and quality dropped. What happened?
That is the verification constraint announcing itself. Parallel threads produce parallel answers to the question of what done means, and nobody agreed on the answer. Pause the multiplication, write the contract and the checks for one thread, and only then add the second. Parallelism without a shared standard of done is how a team industrializes its disagreements.
What is the fastest way to find our constraint?
Ask where the work goes to die. Every team knows its pile: the review backlog, the unanswered decision email, the staging environment nobody signed off. The pile is the constraint. New capacity anywhere else is furniture.
Related reading
- Date-Stamp the Numbers
- The Desk Assumption
- Ten People, One Hundred Agents
- The Review Bottleneck Is the Real Cost Center in AI Teams
- From Pull Requests to Proof
- The Desk Assumption
If your tools got faster and your output did not, book a discovery call.