Bottlenecks
The word "bottleneck" is useful because it prevents fantasy. Every system has a narrow point. Work piles up in front of it and runs thin behind it. You can pour effort into any other part of the machine and feel productive, but throughput will not move until you fix the constraint. A bottleneck is the place where the system stops flattering you and tells the truth about what it actually is.
This is unglamorous and it is the whole game. Most teams improve the part they enjoy improving, or the part that is easiest to measure, or the part that just shipped and is fresh in mind. The bottleneck rarely cares about any of that. It sits where it sits, and it will keep capping the system no matter how much you polish everything downstream of it.
The constraint keeps moving
In early AI demos, the bottleneck was often raw model capability. Could it write code? Could it reason? Could it follow instructions? As capability improves, the bottleneck moves. It becomes context quality. Then tool permission. Then evaluation. Then user trust. Then organizational adoption. A serious builder keeps asking where the bottleneck moved after the last improvement.
The mistake is to assume the constraint is fixed. People who fell in love with "the model is the bottleneck" in one era keep optimizing the model long after the real limit moved somewhere else. They buy a smarter model and the product barely changes, because the smarter model was never the thing in short supply. The queue was forming somewhere they were not looking.
Every meaningful improvement relocates the problem. Fix retrieval and suddenly the limit is that the model can act but has no permission to. Grant permission and the limit becomes that nobody trusts it enough to let it. Earn trust and the limit becomes that the surrounding organization has no workflow to absorb the output. This is not failure. It is what progress looks like from the inside: a constraint that keeps relocating as you chase it.
Why "use the best model" is not a strategy
"Just use the best model" is the most common way to optimize a part that is not the bottleneck. The best model can make a bad workflow more fluent. It can make a confusing system sound confident. It can hide missing integration behind better prose. For a while, that may feel like progress. Then the user tries to do real work and discovers that nothing connects, nothing persists, and every important action requires manual recovery.
If the real constraint is that the system cannot see the right document, a smarter model just guesses more eloquently. If the real constraint is that the user does not trust the output, a smarter model produces more convincing things the user still will not act on. Capability spent on the wrong constraint does not disappear; it converts into polish, and polish on a broken loop is how products feel impressive and useless at the same time.
Finding the real constraint
Diagnosing the bottleneck is a skill, and it is mostly about resisting the obvious answer. Watch where work actually stalls. Notice which step the user redoes by hand. Notice which failures generate the most recovery effort. Notice what people quietly stop using. The bottleneck is rarely where the loudest complaints point; it is where the silent workarounds accumulate.
A useful habit is to ask what would happen if one part became free. If the model became twice as smart overnight, would the product be twice as good? Usually not, and the gap between "no" and "yes" is a map of where the real constraints are. If doubling the thing everyone talks about would barely move the outcome, then the thing everyone talks about is not the constraint, and your attention is being spent for its comfort rather than its leverage.
Then fix exactly that, and immediately go looking for where the constraint moved. The work is never "remove the bottleneck." It is "remove this bottleneck, find the next one, and do not get attached to the part you just made fast."
Swarms do not fix the wrong bottleneck
This is also why adding more agents so often disappoints. People reach for a swarm when the real issue is unclear context or weak authority. Five agents sharing the same vague prompt do not create intelligence. They create noise with job titles. More parallelism in front of the constraint just makes a longer line.
A swarm becomes useful only when each role has a real input, a real constraint, and a real way to disagree — which is to say, only when the underlying bottleneck was actually coordination, and not the thing the extra agents quietly inherited. Adding workers to a constrained system is not throughput. It is congestion with a larger payroll.
The discipline is the same whether the system is one model or fifty agents or an entire company. Find the narrow point. Be honest that it is the narrow point even when it is boring, even when it is yours. Fix it. Then accept that you have not solved the problem so much as earned the right to meet the next one. Systems do not run out of bottlenecks. They run out of builders willing to keep finding them.
