8.21.2026

Boris Cherny: Running Claude Code with Thousands of AI Agents

An algebra for agents, a fourth scaling axis, and a codebase that maintains itself

Written by: Claude AI.

Curator/Editor: Học Trò.

On 27 July 2026, three days after Claude Opus 5 shipped, Boris Cherny sat down with Diana Hu at Y Combinator's Startup School and talked for about thirty-four minutes. The transcript runs to 6,103 words and carries twelve chapter markers. What follows is a further explanation and expansion of what Boris mentioned in the talk: "Running Claude Code with Thousands of AI Agents".

This is the densest passage in the interview, and it contains two completely different machines that Boris Cherny is careful to keep apart. A dynamic workflow takes one enormous task and shatters it across hundreds or thousands of agents that fan out, check each other, and fan out again. A loop or a routine takes one small repetitive task and runs it forever. The first is how a JavaScript runtime got rewritten in eleven days. The second is how, at Anthropic, twenty or thirty jobs now wake up every day and maintain the company's own codebases without being asked. Between them sits a claim that deserves more attention than it got in the room: that orchestrating agents is a new way of buying test-time compute, and therefore a fourth axis along which model capability scales. This chapter explains all of it from the beginning, assuming you have seen none of it before.

Play first, then go to 24:42 — Running Thousands of AI Agents

Boris: The easiest way is dynamic workflows. To use dynamic workflows, it's a fairly new feature in Claude Code. And all you have to say is use a workflow. That's it. And then Claude will just trigger the dynamic workflow. What a dynamic workflow is, is essentially we have the Bun runtime. We use Bun as a sandbox and we start a virtual machine within Bun. And we let Claude start a lot of agents and orchestrate them. And it doesn't just do one agent. It doesn't just do 10 parallel agents. […] My background is functional programming. And so the way that we design this is it's essentially an algebra for agents. So there's a way to run agents in sequence. There's a way to run agents in parallel. And Claude has different tools in order to orchestrate these agents inside of the sandbox to use tokens efficiently to do really, really complex work.

Start with what breaks

To understand why any of this exists, start with the thing it replaces.

In an ordinary agent session, the model is the orchestrator. It decides, turn by turn, what to do next. Every intermediate result — every file it read, every failed search, every half-useful thing a sub-task reported back — lands in one context window. That window is finite, and everything competes for it.

For a task of ordinary size this works well and is the right design. For a very large task it fails, and Anthropic's own account of dynamic workflows names the three failure modes precisely enough to be worth memorising, because they are recognisable in the wild:

Agentic laziness. The model stops before finishing a complex multi-part task. Not a crash — a confident conclusion, delivered while a third of the work remains. Anyone who has asked for a sweeping refactor and received four files of eleven has met this.

Self-preferential bias. The model favours its own findings, and it does so most where it matters most: during verification. An agent asked to check its own work is disposed to approve it. This is the same principle chapter 2 found in the auto-mode classifier and chapter 8 stated as a rule — a verifier sharing the generator's context is not a verifier.

Goal drift. Gradual loss of fidelity to the original objective over many turns, as constraints get lost through summarisation. Turn four hundred is working on a subtly different problem than turn one, and nothing announced the change.

All three come from the same root: one context, doing everything, for too long. Which suggests the fix — stop making one context do everything.

What a dynamic workflow actually is

Here is the mechanism, stated plainly.

A dynamic workflow is a program that Claude writes, at the moment you give it the task, to coordinate other Claudes. Not a template you configured in advance. Not a graph you drew in a UI. A JavaScript file, generated for this specific task, that spawns subagents and routes work between them.

Three properties make that more than a rephrasing of "spawn some subagents."

It is code, so it can compute. The orchestration script has ordinary JavaScript available to it — arrays, JSON, arithmetic. It can partition a list of 1,448 files into batches, tally results, compare outputs, decide what to retry. That logic runs deterministically, outside any model's context, and costs nothing in tokens.

It runs in a sandbox, not in the conversation. Anthropic uses the Bun runtime, starting a virtual machine inside it — the same Bun from chapter 7, which is a pleasing detail: the runtime that Claude rewrote is the runtime that Claude's orchestrator runs on. The consequence is the important part. The intermediate mess stays out of the main context. Your session remains responsive, and the coordinating logic is not competing for the same window as the work.

It is generated per task, not per product. This is the deepest idea in the feature, and Anthropic's phrase for it is a harness for every task. Chapters 3 through 5 argued that a fixed harness fits some tasks and strangles others. The response here is to stop shipping a fixed harness at all and let the model build the right one, on demand, for whatever just arrived.

You invoke it, per Boris, by saying "use a workflow." That is the whole interface.

The algebra

Boris's background is functional programming, and he says the design reflects it: an algebra for agents. There is a way to run agents in sequence. There is a way to run them in parallel.

The word "algebra" is doing real work and is not decoration. An algebra, in the programming sense, is a small set of primitive values plus a small set of operations that combine them into larger values of the same kind — where the combinations are themselves combinable, indefinitely. Numbers with plus and times. Functions with composition. Here: agents, with sequence and parallel.

What you get from that framing is compositionality. If the only way to combine agents is a fixed pattern — a supervisor with five workers, say — then that pattern is your ceiling. If sequence and parallel are primitives, then a stage of a workflow can itself be a whole workflow, and structures of arbitrary depth become expressible without new machinery. This is precisely why functional programmers care about algebras, and it is the right instinct to have brought to the problem.

In practice the documentation describes six recurring shapes built out of those primitives:

  • Classify-and-act — one agent sorts the incoming work by type, and each type routes to a handler suited to it.
  • Fan-out-and-synthesise — parallelise across many agents, then merge the results.
  • Adversarial verification — separate agents check outputs against a rubric, with no stake in the output being good.
  • Generate-and-filter — produce many candidate solutions, keep the ones that survive a quality bar.
  • Tournament — agents compete, pairwise, until one answer wins.
  • Loop until done — repeat until a stopping condition holds.

Boris describes the composite version, which is the three-stage shape most large tasks land on:

Boris: What it's going to do is it's going to start a bunch of agents to do the first pass. Based on that, it might do a second step where it has another set of agents that verify the work or that summarize the work. Then it might do a third stage where it'll fan out again.

Fan out, verify, fan out again. Notice that the middle stage is the one that answers the self-preferential bias problem — verification performed by agents that did not do the work, in contexts that never saw it being done. The Bun rewrite ran exactly this shape at industrial scale: one implementer and two adversarial reviewers per task, in separate contexts, for eleven days.

The fourth axis

Then Boris says something in passing which is the most theoretically interesting sentence in the interview, and which he flags as underdiscussed:

Boris: This is actually a new form of test time compute. When we talk about the scaling laws and we talk about the model getting more intelligent over time, historically it's been a function of the size of the neural net, the amount of training data, and the number of flops that you put into the training. And then recently we also added test time compute. […] And now dynamic workflows are essentially a new way to orchestrate test time compute.

Unpack the history compressed in there. For most of the deep-learning era, the levers on capability were three, all of them applied before the model ships: parameters, data, and training compute. Scaling laws described how performance improved as you pushed those up, and the entire industry's capital expenditure followed.

Then came a fourth, applied after the model ships: test-time compute. Boris gives the deflationary definition, which is the honest one — "a fancy researcher way of saying how many tokens does it generate." Let the model think longer before answering, and it answers better. This is what extended reasoning modes are, and it broke the assumption that a shipped model's capability was fixed.

His claim is that orchestration is a way of buying test-time compute in bulk, and along a dimension the reasoning-mode version cannot reach. A single model thinking for a long time is one context, deepening — which runs straight into the three failure modes above. A workflow spends the same tokens across many contexts, in a deliberate structure, with verification between the layers. It is not just more compute; it is compute arranged so that the failure modes of length do not apply.

Whether this deserves to be called a new scaling axis or a clever engineering pattern is genuinely open, and Boris is right that it has barely been written about. But the empirical case is on the table: 5.9 billion input tokens and 72 billion cached reads bought a language migration that a team of humans was estimated to need more than a year for. Whatever that is, it is not a prompt technique.

There is a cost warning attached, and the documentation is blunt about it: workflows often use substantially more tokens, and should be reserved for complex, high-value tasks. The same page cautions against unnecessary parallelism — most traditional coding tasks do not need a panel of five reviewers. A tool that can spend $165,000 on eleven days of work is a tool you point deliberately.

The other machine: loops and routines

Boris then draws a distinction that is easy to blur and important to keep:

Boris: A second way to do it is loops and routines. Loop is essentially a cron job that's running locally for Claude. Routine is the same thing, but it's running in the cloud. So you can close your laptop. And this is slightly different because for a dynamic workflow, it's one task and you break it up into chunks. For loops and routines, it's one task that is repetitive that doesn't share context, but it might share memory.

Two axes separate them. A dynamic workflow is one task, decomposed, with a shared goal and shared intermediate state. A loop or routine is one small task, repeated, with no shared context between runs — each execution starts fresh — though it may share memory, meaning durable notes that persist across runs.

That "no shared context, maybe shared memory" distinction is the load-bearing one. It is what makes a routine cheap: nothing accumulates, so nothing degrades, so it can run every day for a year without the goal drift that limits a long single session.

The documented mechanics add detail the interview skips, and the differences matter if you intend to use either:

/loop Routine (cloud)
Runs on your machine Anthropic-managed cloud
Machine must be on yes no
Session must be open yes no
Local files yes no — a fresh clone
Minimum interval 1 minute 1 hour
Survives restored on resume, expires after 7 days durable
Triggers schedule schedule, API call, or GitHub event

The seven-day expiry on session loops is a small, wise piece of design: it bounds how long a forgotten job can keep running. And routines being triggerable by API call or GitHub event, not only by a clock, is what makes "routine" a broader idea than "cron for Claude" — the same mechanism covers every night at two and whenever a pull request opens.

Claude maintaining Claude

Then the passage arrives at what Anthropic actually does with the second machine, and this is the part with real consequences:

Boris: A thing that we've started doing is we actually have Claude maintaining itself now. The way we do this is we have a Slack channel where we just had Claude start a bunch of different routines to maintain its own code base. We actually do this for the CLI, for the iOS app, for the Android app, for the desktop app.

The examples he lists are worth taking one at a time, because each is a different category of work and they get progressively less mechanical.

Dead code removal. One sentence of prompt. Every day, it scans all the codebases using static and dynamic analysis, and opens pull requests deleting what nothing reaches. Boris adds a detail worth pausing on: we didn't prompt that; it just figured it out. The instruction did not specify the analysis technique. The agent chose the tools.

Shipping finished experiments. When a feature flag has been at 100% long enough, the conditional is dead weight. The routine removes the flag and ships the branch. This is the most purely mechanical of the five and the one most reliably neglected by humans, because it is boring and carries a small risk, which is exactly the combination that produces indefinite deferral.

Writing tests for undertested areas. Coverage as a standing objective rather than a quarterly initiative. Note the recursion: chapter 8 argued that verification capacity is the constraint on everything, and here a routine is expanding verification capacity on a schedule.

Deleting useless tests. Boris's phrasing: tests that don't need to be there because they were useless tests added by older models or by people at some point. Chapter 4's ablation instinct, automated — and notice that a codebase generating tests daily needs something deleting them daily, or the suite becomes its own maintenance burden.

The abstraction police. His favourite, and the most ambitious. In a large codebase the same abstraction often exists several times, built differently in different places for reasons that made sense at the time. The routine hunts for near-duplicates across all the codebases and unifies them.

Twenty to thirty of these now run daily. Boris estimates hundreds of agents a day, sometimes thousands, doing what he says used to take dozens or hundreds of engineers — and his conclusion is the optimistic one: engineers get to do the thing they actually want to do, which is ship new product and talk to users.

What this actually changes, and what it risks

Three observations the room did not get to.

The unit of engineering management shifts. A routine is a standing intention — "this property should hold, forever" — rather than a task on a board. Dead code should not accumulate. Duplicated abstractions should be unified. Coverage should not rot. These were always the things a good engineering culture wanted and never had the discipline to fund, because each is individually lower-priority than whatever is shipping this week. Encoding them as routines converts a cultural aspiration into an executable one. That is a genuinely new capability and it is more significant than the raw agent count.

The review queue is the unaddressed half. Twenty or thirty routines producing pull requests daily against four codebases produces a large number of pull requests, and somebody has to accept them. Chapter 8's numbers say the industry is already choking here: median review time up 441.5% while throughput per developer rose about a third. If the routines' output is reviewed properly, the reviewing is now the job — the toil moved rather than vanished. If it is not reviewed properly, then the safety of the whole arrangement rests on the tests, which is precisely the assumption Andrew Kelley refused to grant in chapter 7. Boris does not say which of these Anthropic does, and it is the first question worth asking anyone who wants to copy the practice.

The abstraction police is the dangerous one. The other four routines are close to value-neutral: dead code is dead, a fully-rolled-out flag is finished, coverage gaps are gaps. But "these two abstractions are nearly the same and should be unified" is a design judgement, and sometimes the duplication was deliberate — two things that look alike today because they have not yet diverged, kept separate precisely so they can. A daily job that unifies them is a daily job that couples two modules on the strength of a resemblance. Boris says it is "not totally there yet," which is a fair signal. It is also the one place in this list where being wrong is expensive and the tests will not tell you.

The honest summary

Two machines, cleanly separated by what kind of work they suit.

Use a dynamic workflow when one job is too big for one context: a migration, an audit across every file, a research question needing many independent looks and a synthesis. Expect it to cost real money. Expect the verification stage to be the thing that makes it work.

Use a loop or routine when a small job should simply keep happening: watch a build, tend a pull request, sweep for dead code, keep coverage from rotting. Expect it to be cheap, and expect the value to come from consistency rather than intelligence.

And underneath both, the same claim that runs through the whole interview. The model is not the constraint. What you can arrange around it — how you split the work, who checks whom, and how often it runs without being asked — is where the leverage now lives.

Sources

Labels: , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)