01 / OVERVIEW
Agent operations

Running 30 coding agents

We hit real friction running a large fleet of AI coding sessions: nobody knew who was working on what, two agents kept reaching the same conclusion independently, and long efforts outgrew their own memory. This is what we found — including two things we had backwards.

Sessions running
30
across a few repos
Where others stall
~8
every independent report
Fixed cost per session
14.5%
before any work starts
Things we had wrong
2
both corrected here
Agent operations · 2026-07-3101
02 / THE WALL
The wall

Everyone stalls at about eight agents.

This is the most consistent finding in the research, and it comes from people with no connection to each other. The number barely moves.

4–8
schipper.ai — “Around 8 agents is my practical max. Past that, I lose track of what each one is doing.”
3–8
Peter Steinberger — settled on a 3×3 terminal grid; tried worktrees and PR-based flows and reverted.
5–10
Steve Yegge — teams found themselves operating 5–10 instances.
3–5
Multiple practitioner threads report the same ceiling, citing supervision — not tooling — as the limit.
100s
Cursor — the one team that got past it, and only by changing the architecture (slide 07).
We are running ~30 with no coordination layer. The friction we have been feeling is not a broken handoff process. It is the wall everyone hits, arriving on schedule.
Agent operations · 2026-07-3102
03 / CONTEXT
Measured, not estimated

A session starts 14.5% full.

We measured the first token count of eight real sessions before any work happened. They cluster tightly around 145,000 tokens — the project instructions, tool definitions and skill files that load every time.

FIXED BASELINE
145K
Loaded before the first instruction is read. Consistent across every session measured.
PROJECT INSTRUCTIONS
57K
One file. It is roughly 40% of the entire fixed cost.
WHAT THIS MEANS
50%
Half a session's gauge is really about 41% of its usable working room.
The raw percentage is a misleading gauge. Read it against working room, not against the whole window — otherwise every threshold you set is quietly wrong.
Agent operations · 2026-07-3103
04 / MISTAKE 01
What we had wrong — 1 of 2

We handed off a session that had barely started.

A rule intended to prevent context exhaustion fired at 19%. Subtracting the 14.5% baseline, that session had used 4.5% of its actual working capacity — and we replaced it with a fresh one that had to re-learn everything from a document.

THE RULE WE HAD
Trigger on a percentage. It could not tell the difference between “deep into hard work” and “barely begun”, so it fired at the wrong moment and stayed quiet at the right one.
THE RULE THAT WORKS
Trigger on a natural boundary — work merged, task finished, review closed — once past halfway. That is when accumulated detail genuinely stops being useful.
Handing off mid-task is worse than not handing off at all. You pay to write the document and pay again for the next session to ramp, in order to discard context that was still being used.
Agent operations · 2026-07-3104
05 / SUBAGENTS
The lever we were under-using

Delegated work costs the main thread almost nothing.

When a session delegates to a helper, the helper works in its own separate memory and returns only its conclusion. The searching, file reading and dead ends never enter the main conversation. This is documented behaviour, and we confirmed it.

Main session asks a question
→
Helper explores in its own memory
→
Only the answer comes back
This is the real answer to “long efforts outgrow one thread.” Keep one durable session per workstream for judgment and decisions, and push every investigation out to a helper. The thread stays small because the expensive part happens elsewhere.
Agent operations · 2026-07-3105
06 / MISTAKE 02
What we had wrong — 2 of 2

You cannot ask it to condense earlier.

When a session fills up it automatically summarises itself and continues. We assumed this was configurable and that our own safeguard was redundant. Both assumptions were wrong.

01
The threshold cannot be changed. It is on or off — there is no setting for “condense at 80% instead”.
02
It fires very late. We measured one of our own sessions condensing at ~96% full.
03
Quality at that point is undocumented. Nobody publishes whether summarising from a nearly-full session is worse. It is a reasonable worry and an unproven one — we should not state it as fact.
So the safeguard is not redundant after all. A forced early condense is the only way to get this, and we have now built it. Condensing early is cheap insurance against a risk nobody has measured.
Agent operations · 2026-07-3106
07 / COORDINATION
The most important finding

Locking agents out of each other's work fails.

Cursor published three generations of their approach to running hundreds of agents. Two of them failed — and they failed in the way we were about to attempt.

01
Locking — failed. Agents held claims too long or forgot to release them. “Twenty agents would slow down to the effective throughput of two or three.”
02
Letting them race and resolve after — failed. Agents became risk-averse and started avoiding the harder tasks.
03
Splitting planning from doing — worked. Hundreds now run concurrently on one branch with minimal conflict.
The coordination tax is not theoretical. One documented six-agent build spent 54.5% of its commits on claiming, releasing and clearing stale claims rather than on the product.
Agent operations · 2026-07-3107
08 / THE FIX
The structural answer

Only a few agents should decide what to work on.

Our sharpest problem is two agents independently reaching the same conclusion — “the build is broken, let's fix it” — and both starting. That is not a scheduling clash. Both were right. No lock catches it, because neither knew the other existed.

TODAY
Every session both spots work and does it. Two sessions spotting the same thing is then guaranteed to become two sessions doing it — discovered at merge time.
PROPOSED
A small number of sessions may file new work. The rest may only pick up work already filed. Spotting a broken build means filing or finding the item — never starting.
We already own most of this. Our task board plus the start-work script is a claiming system — it is just optional and human-driven today. Making the claim required before work begins is a small change with an outsized payoff.
Agent operations · 2026-07-3108
09 / IDENTITY
Why “v1 → v5” gets confusing

Identity should belong to the work, not the session.

When a session runs out of room we start a successor, so one effort becomes v1, v2, v3… and it stops being obvious which one is in charge. The naming implies a chain, but we were actually running three different relationships under it — a supervisor, a true successor, and an unrelated new scope.

SESSION AS IDENTITY
Sessions are temporary, so the authoritative one keeps moving. “Who owns this?” has no stable answer.
WORK ITEM AS IDENTITY
A durable ticket that outlives every session. Sessions attach to it and fall away; the ticket stays authoritative. The question becomes “who holds it?”
Never start a successor merely because a session filled up — let it condense and carry on. Start one only for genuinely parallel work. That alone removes most of the sprawl.
Agent operations · 2026-07-3109
10 / HONESTY
Being straight about the gaps

Part of this has no existing answer.

We searched the ecosystem properly. Visibility and isolation are well solved. The problem we actually have is not.

01
Two agents converging on the same idea is unsolved. The only tool that names the problem has one user. The only measurement is an unreviewed simulation. The one production answer sidesteps it architecturally rather than solving it.
02
Everything off the shelf de-duplicates on an exact key — a ticket number, a file, a branch. Nothing recognises “these two mean the same thing”.
03
Anthropic hit it themselves. Their own write-up describes agents duplicating each other's research while a third covers something no one asked for.
If we build this, we are ahead of the field, not behind it. Worth knowing before we go looking for a tool that will not be there.
Agent operations · 2026-07-3110
11 / ACTIONS
What we are changing

Four changes, smallest first.

01
Force an early condense. Built and shipped — a session at 80% cannot simply carry on quietly. The only way to get this.
02
Stop starting successors on exhaustion. Write the summary document, keep the thread. New sessions only for genuinely parallel work.
03
Delegate far more aggressively. Confirmed nearly free for the main thread, and the real answer to long-running efforts.
04
Then separate deciding from doing. A real project, not an afternoon — and the only thing that fixes duplicate work.
The open question is scale itself. Thirty sessions with no coordination is past where everyone else stalls. Eight well-coordinated may well ship more than thirty that collide — worth deciding deliberately rather than drifting.
Agent operations · 2026-07-3111

All slides

PropFlow Docs