Building an Autonomous Coding Fleet That Actually Scales
A reference architecture, the sizing math, and the one number that determines how many agents you can run
Brian James Curry | Vector1 Research
A team where humans review everything with weak automated gates can sustain about one coding agent. A team routing 15% of changes to humans with decent gates can sustain thirteen. Same models, same orchestrator, same budget. The difference is entirely architecture, and it follows from a queueing result that most fleet designs never compute.
Everything needed to run a fleet of coding agents now exists off the shelf. Orchestrators spawn agents into isolated git worktrees. Sandbox providers advertise fifty thousand concurrent sessions with gVisor or Firecracker isolation. GitHub’s Agent HQ runs agents side by side, and Codex is architected around parallel long-running tasks. Google reported at Cloud Next 2026 that 75% of new code at the company is AI-generated and engineer-approved, up from about a quarter in late 2024.
The tooling question is closed. Every remaining hard problem in fleet operation is a sizing problem, and almost nobody is solving it, because the industry has been asking how many agents it can afford to run rather than how many it can afford to supervise.
This piece builds the thing end to end: the reference architecture, the model that tells you how large the fleet can be, and a controller that enforces the answer at runtime. Your fleet size is set by the fraction of changes that require human attention. It scales as the reciprocal of that fraction. If you have not engineered that fraction down, you are running a fleet of one or two agents regardless of how many you started.
Research note. This is an architecture paper with a quantitative sizing model. The queueing derivation is standard. The feedback term, the bifurcation, and the routing scaling law are the contribution. Every parameter is stated, the code runs, and the sensitivity sweep is reported. I did not collect original telemetry. Industry figures are attributed to their primary sources, and where a figure reached me via a vendor synthesis I say so.
1. What you are actually building
Strip away tool names and a production fleet has six layers. Addy Osmani’s tiering is a useful entry point (subagents in a single session, local orchestrators managing 3 to 10 agents across worktrees, cloud-VM agents that drain a backlog overnight), but tiers describe where the agents run. The architecture that matters is what surrounds them.
- Task admission. Decompose, bound scope, reject unbounded work.
- Isolation. Worktree, sandbox, and a scoped credential per agent.
- Orchestration. Deterministic coordination, with no model in the loop.
- Verification. Machine gates, then automated review, then human review.
- Merge control. Provenance-tagged, non-bypassable, policy-routed.
- Supervision. Capacity measurement and admission throttle.
Layers one through five are well covered in the current tooling. The sixth barely exists, and it is the one that determines whether the other five scale. Build the first five without it and you have a fleet that runs beautifully until it doesn’t.
Before building any of them, size the thing.
2. Sizing: the supervision ceiling
Work in reviewer-hours per working day. Let N be concurrent agents, a the changes each produces per agent-day, s the mean reviewer-hours a change consumes, and R the reviewer-hours per day genuinely available for review. Arrival rate is lambda = Na, so utilisation and the hard ceiling are:
rho = N · a · s / R N* = R / (a · s)
Calibrate against the public telemetry. An agent working a full day produces perhaps 3 reviewable changes. A senior engineer has maybe 3 hours a day of real review attention, not 8, because review competes with meetings, incidents, and their own work. Mean review cost 0.4 reviewer-hours, which is generous given what we know about size.
N* = 3.0 / (3.0 × 0.4) = 2.5
Two and a half agents per reviewer. Note that N* is invariant to inference cost. Cheaper agents raise a, which lowers the ceiling.
Delay approaching that ceiling follows Pollaczek-Khinchine, where c² is the squared coefficient of variation of review cost:
E[Wq] = rho · s · (1 + c²) / (2 · (1 - rho))
The c² term is where the character of agent-written code enters the math. The dominant complaint in Stack Overflow’s 49,000-respondent survey is code that is nearly right but not quite, which is a statement about variance rather than mean. Most agent changes are cheap to verify. An unpredictable minority are expensive. At rho = 0.8, moving from c² = 0.5 to c² = 4 triples the mean wait, from 1.2 hours to 4.0, with no change at all in average review effort. “Our agents are right 90% of the time” is not the reassurance it sounds like. The 10% is a variance term, and variance is what fills queues.
The term that changes the answer
The model so far assumes the queue discipline holds. It doesn’t. Faros telemetry across 22,000 developers found 31% more pull requests merging with no review at all, alongside median time in PR review up 441% and PR size up 51.3%. Waving changes through is the system’s actual response to load, and modelling it changes the analysis qualitatively.
Let p(rho) be the probability a change merges unreviewed, increasing and convex, because teams tolerate a queue and then break. Let q be the probability such a change carries a defect that escapes, and r the reviewer-hours to remediate one. Remediation is done by the same senior people who review, and that is the whole mechanism:
rho = g(rho) = lambda · s · (1 - p(rho))
------------------------------
R - r · lambda · p(rho) · qSkipping review removes work from the queue and destroys capacity at the same time. Both effects run through the same convex p(rho), so g is non-monotone. With q = 0.45 (Veracode’s defect rate for unreviewed AI-generated code) and r = 6 reviewer-hours (three redeploy cycles, per Lightrun’s survey of 200 senior SRE and DevOps leaders), the stable and unstable branches collide and annihilate in a saddle-node bifurcation.
Three consequences follow.
The critical fleet size is 1.21, not 2.5. The feedback loop costs 52% of the arithmetic ceiling. Across the sweep, with q from 0.25 to 0.55, r from 3 to 16, and the skip parameters varied over their plausible ranges, the ratio stays between 0.37 and 0.62.
The failure is discontinuous. Above the critical point there is no stable state at all, not a worse one. The system leaves the basin and runs to the point where review has effectively stopped.
It happens at rho of roughly 0.60, or 0.48 to 0.71 across the sweep. Every capacity heuristic in engineering management, staff to 70% and leave slack, reads as satisfied at the moment the fleet is one agent from collapse.
3. The scaling law that makes a fleet possible
If that were the whole story, fleets would be a bad idea. It isn’t, because N and R are not the only levers.
Introduce f_H, the fraction of changes routed to a human. The human-facing arrival rate becomes N · a · f_H, and the ceiling becomes:
N* = R / (a · s · f_H)
Fleet size scales as 1/f_H, exactly. Solving for the bifurcation under routing confirms it holds for the feedback model too. Halving f_H doubles the critical fleet size to three significant figures.
A team where humans review everything with weak automated gates sustains one agent. A team routing 15% of changes to humans with decent gates sustains thirteen. Same models, same orchestrator, same budget, and an order of magnitude apart in sustainable fleet size, entirely from architecture.
Note what happens in the right-hand column. With strong gates the feedback term stops binding and the plain queue bound takes over again. The constraint migrates. At that point, and only at that point, hiring another reviewer actually buys fleet capacity, because you are no longer adding people to a system that can lose its fixed point.
So the design target is not “run more agents.” It is:
f_H ≤ kappa · R / (a · s · N_target)
with kappa of about 0.5 as the bifurcation safety factor. Everything below is engineering in service of driving f_H down without driving q up.
4. The architecture
Full article on my substack here: https://brianjamescurry.substack.com/
About the Author
Brian Curry is a Kansas City–based Machine Learning & AI Strategist, Marketing Economist, and Applied Researcher. He drives Vector1, a personal open-source research initiative advancing marketing economics, causal inference, cognitive AI architectures, and the economics of intelligent automation.
He has led advanced data science and analytics initiatives across major enterprises including Koch Industries, Tractor Supply, Hallmark, Garmin, and AT&T. His work applies economic thinking and causal inference to connect marketing investment to outcomes, operational decisions to economic value, and AI adoption to competitive advantage.
Key Research & Open-Source Projects (GitHub: @Bodhi8):
- PyCausalSim — A Python framework for causal discovery and inference through simulation. Enables testing of counterfactual scenarios to identify true structural drivers.
- Papilon — A complex system and causal discovery library for Media Mix Modeling (MMM) and adaptive systems.
- Regimecast — Applied research and tooling for time-series regime detection and forecasting.
- CarryNet — Open-source research and modeling focused on commodity carry trade analysis.
- Foodmesh-ml — Machine learning, optimization, and simulation framework for modeling distributed food systems.
- Memory-Node Encapsulation (MNE) — A cognitive AI architecture and novel data structure for artificial episodic memory.
- The Autonomy Economy — A macroeconomic framework projecting the dual impacts of massive productivity growth and extreme price deflation in an AI-automated world.
- Meaning-Flow — Research focused on semantic content modeling and automated coverage gap analysis.
Contact: brian at vector1.ai | Vector1 | GitHub | LinkedIn
This article may be shared with attribution under Creative Commons Attribution 4.0 International (CC BY 4.0).
