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

**Topic:** agent orchestration · **Published:** October 2026 · **Reading time:** 8 min

At its peak in 2026, more than 45 AI agents worked at the same time on one product: a regulated crypto platform with 9 apps that I was rebuilding as CTO. Some were long-running agents with fixed jobs. 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, each one approved by an independent reviewer agent.

This article explains why the large team stopped working, what replaced it, and the numbers behind each step.

## Why I scaled up first

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 finance screens, one for accounting, several for review, several for QA, one to talk with the staff in their chat groups, and one for tooling.

Specialists learned their area. Adding an agent felt like adding capacity, the same way adding an engineer does.

## What broke

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

By the end of September, these problems had shown up:

- **Steps with two owners, or none.** The lead, the QA agent and the builders all moved tickets after a deploy. One agent both scoped requests and assigned them, so nobody checked its scope.
- **Builders without a reviewer.** Two builder agents had no reviewer assigned, so their changes waited, then bounced.
- **Stale rules.** One builder still followed a check that I had already retired, because its instructions were older than the change.
- **Collisions.** Agents in different areas edited the same shared files and blocked each other's merges.
- **Machine load.** Type checks and test suites from many agents at once starved the build machines.

None of these was a model failure. Each model did its job well. The failures were in coordination, and coordination cost grows faster than the team.

## Step 1: one owner per step

I wrote a table with one row per step of the delivery flow and exactly one owner per row: intake, scope, assign, build, review, land, verify, retest, team relay and tooling. An agent that gets a request outside its row sends it to the owner and does not do it.

The table gave each problem on the list one owner. It also showed that many lanes existed only because nobody had asked whether their step needed a dedicated agent.

## Step 2: fewer builders, bigger batches

Next I limited new work to four builder lanes, split by risk area: compliance and sign-in, tooling and tests, product screens, and finance. The other builders finished their open changes, 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.

## Step 3: builders became small and cheap

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: 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 | What changed | Round-1 misses | Rounds to approval | Builder cost |
| --- | --- | --- | --- | --- |
| 1 | Haiku replays 3 shipped tickets | 7 | 1–2 | $0.02–0.43 per ticket |
| 2 | Planner splits 2 tickets into 45 items | 4 | 2 and 3 | $0.65 in total |
| 3 | Same as 2, at maximum reasoning effort | 5 | 2 and 2 | about 20× pilot 2 |
| 4 | Same harness, 41 items, three builders | 4 / 5 / 6 | 2–3 | $0.015 / $0.306 / $0.238 per item |

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 arm.

The pilots showed where the misses came from: mostly the planner and the briefs, not the builder's model or effort. The planner forgot pages that used the same pattern, and briefs left out 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.

With that result, a builder no longer needs a strong model or a long memory. In two days, 15 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.

## Step 4: remove extra layers

I also removed two layers that I had built myself:

- **A decision-model router.** A typed judgment model decided which agent took each request and whether to hold it for a check. It was accurate on owner choice, but about two in three of its holds were unneeded. I describe that benchmark in a [separate article](/writing/benchmarking-decision-models/).
- **A second-model-family review lane.** For one day, Codex agents did reviews, so a different model family checked Claude's work. The next day I moved all review back to the Opus reviewers.

## What the 10+ lanes look like now

- **Planners and small-model builders.** The lead or a planner splits each ticket into small, briefed items. Four small-model builder lanes take them one at a time, and one planner starts a short-lived builder for each item.
- **Independent reviewers.** A reviewer never wrote the code it reviews. Changes that touch money, identity checks, sign-in, security or migrations stay with the strongest model, as builder and as reviewer.
- **One lead.** It orders the queue, settles collisions and lands approved changes in batches. A staging build is verified after each batch.
- **A few service lanes.** Team intake, QA and tooling.

Hard limits keep the machines healthy: at most three heavy jobs at once on the main build server, one build worker per lane, and at most four background helpers per lane. When an account reaches 90% of its five-hour usage window, a guard holds new helpers until the window resets.

## What I would tell a team starting with agents

1. **Count coordination cost, not agent count.** Every extra standing agent adds handoffs, shared files and stale instructions.
2. **Give every step one owner.** Write it down in a table that agents read.
3. **Put the strong model where judgment is: planning and review.** Use the cheapest builder that passes review, and measure it. In one 41-item test, our cheapest builder missed fewer items than options that cost 16 to 20 times more.
4. **Give builders one item at a time.** Each item comes with its own short brief, so stale rules have less room to carry over.
5. **Re-test your structure when models change.** The team that was right in August was wrong in October.

Want a team like this set up in your repository? Email [hello@jeffkent.dev](mailto:hello@jeffkent.dev).