What actually changes as you scale from one agent to a thousand?

The bottleneck moves before the agent count does

You can tell which step you’re on by what you personally did yesterday. If you sat and watched an agent work, taking each response as it came, you’re on the first step and the thing holding you there is your own attention. If you spent the afternoon reading six streams of output from six parallel sessions, you’re on the second, and its ceiling is already visible from where you’re standing.

The agent counts here are illustrations. They mark roughly where each job stops fitting in a person’s day, and the order matters far more than the numbers do. Boris Cherny’s five-step adoption framework, published 16 July 2026, walks the same order.

Nothing in that table is about the models getting better. Every row is a job that used to be yours and now belongs to something that runs without you.

Why reading every output stops scaling

Once several agents run at once, review becomes the bottleneck. Parallel agents don’t remove the reading work. They multiply the changes one person has to inspect, and that cost grows with every agent you add. If reading is the thing that makes the work safe to ship, then your safe throughput is one person’s reading speed, however much compute you point at the problem.

That ceiling doesn’t move when the model improves. It moves when something other than a person can say the work is fine. Which is why the condition for leaving the first step is a self-verification loop you actually trust: the agent runs the tests, the build, the lint and an end-to-end check against a real environment, and you see the result rather than the raw attempt.

So the interesting question was never how many agents your budget covers. It’s how much of the checking you’ve managed to hand over.

Do you still have to read the code?

There’s a live disagreement here, and it doesn’t resolve with a better model.

One position, argued seriously by people shipping agent-written code every day, is that you remain the judge. You read what the agent wrote, because you’re accountable for it, and because a model’s confidence about a change tells you nothing about whether the change is right.

The other position is this ladder. If reading every change is what makes the work safe, then one person’s reading capacity is your ceiling, permanently.

Both can hold at once, and that’s the useful part. Human reading as the last line of defence and a ceiling set by one person’s attention are the same statement said twice. Everything above that step is a claim about what your checks can prove on their own. Which side you sit on isn’t a matter of temperament; it depends on the work in front of you.

The way past the ceiling is a loop that has earned trust by catching real failures, with the run history to show for it. A stronger model doesn’t settle this. It changes how often the check fires, and the check is still the thing that makes the work safe to leave alone. Keep reading agent output anyway, because the people who stop entirely lose the ability to write good checks.

What has to earn the trust before you look away

Trust here isn’t a feeling about a model. It’s a specific claim that specific failures get caught, and the failures in question are dull. Anthropic’s engineering write-up on long-running agents, from November 2025, is blunt about them. Agents took on too much at once. They left code broken and marked features complete without having tested them. Memory is the other one. A new session starts with no record of what came before, and compacting the old context forward doesn’t reliably carry what mattered.

Read that as a specification for your checks rather than a warning about models. An agent that reports done while the build is broken gets caught by the build. An agent starting cold gets caught by state that lives outside the conversation, in the run’s own record. Loop engineering is where both of those get built properly.

Most of the work that makes output checkable happens before any agent runs, and it isn’t writing tests. It’s drawing the boundary of what a service is responsible for and what it isn’t, naming what has to stay true no matter what changes inside it, and deciding which answers are acceptable and which need a person. Tests are how those decisions get encoded, not where they get made. When someone says a piece of work can’t be checked automatically, usually nobody has written down what a good version looks like, and a check can’t be more specific than the definition behind it.

That’s also why one reviewer isn’t the answer, whether it’s a person or a model. Different angles and zooms catch different things: someone reading the change itself, someone asking whether it fits the system it landed in, someone asking what it can now reach that it couldn’t before. The same angle applied twice catches the same class of problem twice.

The part that belongs to scale is the arithmetic. None of those failures gets cheaper when you run twenty of them at once, and every failure you haven’t automated a catch for comes back to you as reading. So the trap on the way to a hundred agents is adding agents before the loop has earned trust widely. Trust that’s real for one team’s workflow and imaginary for every other one is how you end up with a hundred agents and a lot of people quietly back to reading output.

Adding agents doesn’t add throughput on its own

Agent count is a topology decision before it’s a capacity one, and the topology has a measured downside. Google Research’s January 2026 work on scaling agent systems found that on the Finance-Agent benchmark a centralised multi-agent architecture beat the single-agent baseline by 80.9%. On PlanCraft, whose tasks run in sequence, every multi-agent variant they tried scored 39% to 70% below that same baseline. The difference between those two results is whether the work splits.

Errors follow the wiring too. Independent agents running without communicating amplified errors by up to 17.2 times. Centralised ones amplified them 4.4 times.

So the hundred-agent step isn’t ten copies of the ten-agent step. Work that doesn’t split gets worse when you split it, and agents that can’t see each other’s mistakes multiply them instead. Graph engineering is where that question gets worked through, including how to tell whether a boundary earns its place. For this ladder it sets the order: coordination capacity grows before agent count does.

In practice that capacity is a written-down shape rather than more chatter between agents: stages, what each one can reach, and what has to be true before the next starts. Plenty of things get called a playbook. The kind that helps here is the one the runner enforces, so the shape isn’t something the agents can renegotiate halfway through, and coordination stops being a thing they have to work out between themselves.

Where you end up, and what reaches you

At the top of the ladder, monitoring becomes exception routing, and agent count grows only as fast as ordinary work stops asking for ordinary attention. You steer by intent, and the things that need a decision are the only ones you see. Two things have to be true before that works. Something other than you has to decide what needs you, and those items need somewhere to land that isn’t a chat thread you scroll.

Both of those are boundaries rather than habits. What a stage can reach and what a run can spend get fixed outside the model, so a run heading somewhere expensive stops instead of explaining itself afterwards. Routine actions clear against criteria you wrote down, and the consequential ones wait for a person. Which decisions belong to you covers how those boundaries get drawn, and the attention inbox is where the held items wait with the run behind them.

The last step adds guardrails per type of work. A migration, a fuzzing sweep and a customer-facing fix don’t want the same rules, and one org-wide policy strict enough for the third makes the first two not worth automating. So the enforcement gets written per kind of work, which keeps the strict rule on the customer-facing lane without dragging the migration down to it.

What to build next, from where you are

Locate yourself by the job you can’t put down, then build the thing that takes it off you.

• Still reading every response. Build the check the agent runs before you see output, and a stopping rule that isn’t your judgement. Until something other than you can say a pass helped, the work stays synchronous.
• Reviewing parallel streams. Name the classes of routine action, write down the criteria you apply when you review them, and put those criteria in a judged gate. Review becomes exception handling, or it stays your afternoon.
• Making all the decisions. Move enforcement off prompts and into the runtime: what each stage can reach, what a run can spend, which actions stop for a person. Then start promoting actions from held to judged one at a time, with a written rule for what sends each one back.
• Deciding what to automate. Give each type of work its own guardrails and tune them against run history rather than instinct. The record is the instrument here, so it has to be real before this step means anything.

None of these steps skip. If your checks haven’t caught anything real yet, a higher agent count is a number rather than a capability, and the reading comes straight back the first time something lands that shouldn’t have.