SRE Lab · agent fleets · updated

One Agent to Hundreds

Running hundreds of coding agents is not one agent times a hundred. Each jump in scale breaks something the smaller setup got away with: your review time, shared files, one coordinator's attention, then rate limits and cost. Step up one stage at a time. Each stage says what to add, what breaks without it, and how to tell you're ready for the next.

The main thread is pstack, Lauren Tan's published agent workflow, alongside what Stripe, Spotify, Uber, Cursor and Anthropic publish about their agent fleets and how Mitchell Hashimoto, Dex Horthy and Boris Cherny describe their own ramp-ups. Stage sizes are teaching breakpoints, not thresholds from a study.

carried overnew at this stage one agent

Add at this stage

    What breaks without it

      Ready for the next stage when

        Who works this way

          Documented limits you'll meet here

            Sources for this stage

              or use ← → keys

              Check first that more agents will help at all. A Google Research, Google DeepMind and MIT study of 260 agent configurations found that tasks where one agent already succeeds more than 45% of the time experience negative returns from additional agents, as coordination costs exceed diminishing improvement potential. On SWE-bench Verified, every multi-agent setup they tested did slightly worse than one agent (−15% to −2%).

              Scale pays when the work splits into independent pieces and each piece has a check the agent can't fake. Anthropic's C compiler run used 16 parallel agents. It stalled when every agent hit the same kernel bug, and recovered once GCC served as a known-good oracle. (Kim et al., arXiv:2512.08296 v3; Anthropic: Building a C compiler with a team of parallel Claudes)

              Fast inside, careful at the edges

              Most real codebases are not greenfield all the way down. New code can run at fleet speed, but where it meets older systems, every change needs a slower lane. The people above handle that split the same way.

              A to B at a glance

              StageWhat limits youWhat you addMove on whenWho works this way

              How the pieces fit

              Across the stages, the human's job moves from doing the work to writing briefs, then to reading verdicts, then to answering only the questions no experiment can settle. pstack's Orchestrate playbook describes the end state as the human checking in twice a day instead of every five minutes. Irreversible actions (force-pushes to shared branches, deploys, data deletion, customer messages) still wait for a person.

              Two ideas carry the whole ladder. First, evidence, not assertion: a worker's "done" counts only with the evidence its brief asked for. pstack's swarm skill drops a report missing its SHAs, respawns the worker once, and records a second miss as a gap: A gap does not count as a pass. Second, encode lessons in structure: a correction you keep repeating becomes a lint rule, a check or a script. pstack's principle puts it bluntly: The instruction is the symptom.

              Memory is the newer layer. In her AI Native DevCon talk, Anthropic's Lamis Mukta describes memory moving from CLAUDE.md files to skills to plain files that agents search with ordinary tools. It then needs versioning, a hash check before every write, and read-only organisation-wide memory beside writable per-agent scratchpads once many agents share it. "Dreaming" is a separate batch job that reads past sessions and proposes a cleaned-up memory store for a human to accept or reject. Claude Managed Agents documents the same mechanics (immutable memory versions, a content_sha256 precondition on writes). Dreams are in research preview.

              Honest limits