How I cut 45 AI agents to 10+ long-running lanes

At its peak in 2026, more than 45 AI agents worked at the same time on one large product that I was rebuilding. Some were long-running agents with fixed jobs, and I call each of these a lane. The rest were short-lived helpers. They ran on Claude, Codex and Grok.

By late October, 10+ long-running agents did the same work. Over the whole project, the team shipped about 4,000 approved code changes in under six months, and an independent reviewer agent approved each one.

I built the big team on purpose, and then I took it apart.

Why I scaled up

Earlier models needed long, exact instructions. A builder agent that knew only a ticket number made poor guesses about files, patterns and rules. So I gave each agent a narrow area and kept it there for weeks: one for features, one for bugs, one for small fixes, one for each major area of the product, several for review, several for QA and one for tooling.

Adding an agent felt like adding capacity, the same way that adding an engineer does.

What went wrong

A team of 45 agents has the same problems as a team of 45 people, except that the agents do not notice the problems themselves.

Over time, all of these had shown up. The lead, the QA agent and the builders all moved tickets after a deploy, so that step had three owners. One agent both scoped requests and assigned them, so nobody checked its scope. Two builder agents had no reviewer assigned, so their changes waited and then bounced back. One builder still followed a check that I had already retired, because its instructions were older than the change. Agents in different areas edited the same shared files and blocked each other’s merges. And the type checks and test suites from many agents at once starved the build machines.

None of this was a model failure. The failures were in coordination, and I think that coordination cost grows faster than the team does.

Fixing it in steps

First I wrote a table with one row for each step of the delivery flow and exactly one owner for each row: intake, scope, assign, build, review, land, verify, retest, updates and tooling. An agent that gets a request outside its row sends the request to the owner and does not do the work itself.

The table also showed that many lanes existed only because nobody had asked whether their step needed a dedicated agent.

Next I limited new work to four builder lanes, split by risk area. The other builders finished their open changes and then stopped. Builders also moved from one ticket per change to batches of 5 to 50 related tickets per change. One batch needs one review and one merge, not fifty.

The biggest cut came from a model change. In October I ran four pilots with a small, cheap model (Claude Haiku 5.5) as the builder. A strong planner (Claude Opus 5.5) split each ticket into small items with exact briefs. A brief names the files, the shared components and their limits, and the checks that prove the item is done. An independent Opus reviewer approved or rejected the merged result.

Pilot 4 compared Haiku at default effort, Haiku at maximum effort and Sonnet 5.5 at high effort on the same items. The cheapest option had the fewest misses. Maximum effort cost about 20 times more, took about 9 times longer and missed more. The reviewer caught the misses in every case.

The misses mostly came from the planner and the briefs, not from the builder’s model or effort. The planner forgot pages that used the same pattern, and the briefs left out the limits of shared components. So I added two rules: every plan has a “same pattern elsewhere” item, and every brief names the shared-component limits.

After that, a builder no longer needed a strong model or a long memory. Within days, the standing builder lanes closed. Four small-model builder lanes replaced them, and each one takes short, briefed items from the lead. A newer planner lane starts a short-lived builder for each item.

I also removed two layers that I had built myself. One was a decision-model router, which is a typed judgment model that decided which agent took each request and whether to hold it for a check. It chose the right owner accurately, but many of its holds were not needed. I wrote up that benchmark in a separate article. The other was a second-model-family review lane. For a short time, Codex agents did the reviews, so a different model family checked Claude’s work. Then I moved all review back to the Opus reviewers.

What the lanes look like now

The lead or a planner splits each ticket into small, briefed items, and the four small-model builder lanes take them one at a time. A reviewer never wrote the code it reviews. High-risk changes, such as security work or data migrations, stay with the strongest model, both as builder and as reviewer.

One lead orders the queue, settles collisions and lands approved changes in batches. A staging build is verified after each batch. A few service lanes handle intake, QA and tooling.

Hard limits keep the machines healthy. A small cap limits heavy jobs on the shared build server, each lane gets one build worker, and each lane may run only a few background helpers. When an account nears the limit of its usage window, a guard holds new helpers until the window resets.

What I’d tell someone starting out

I would count coordination cost, not agent count. Every extra standing agent adds handoffs, shared files and stale instructions. Give every step one owner and write it in a table that the agents read.

Put the strong model where judgment is, in planning and review, and use the cheapest builder that passes review. Measure it. In one 41-item test, our cheapest builder missed fewer items than options that cost 16 to 20 times more.

And test the structure again when models change. The team that was right a few months earlier was wrong by October.

Want a team like this set up in your repository? Email hello@jeffkent.dev.