Run Agents Longer. Then Run More of Them.

Two numbers decide how much work your agents do for you.

The first is length: how long one agent works before it needs you. The second is width: how many agents work at the same time. Multiply them, and you get the work that happens while you think about the next decision.

I wrote about length in June, in Set the Goal, Walk Away. I wrote about width in September, in Stop Running Just One Agent. Since then, the whole industry has moved on both numbers, and so have we. In October, I made 4,526 commits across all of my repositories, about 156 a day, and I wrote none of them by hand.

This post is about both multipliers together: what works, what breaks, and what is left for the human.

How long an agent can work

In March, METR found that an early Claude Mythos could finish software tasks that take a human expert at least 16 hours. That is two workdays of senior engineering in one run. METR puts the doubling time of that horizon at about four months.

The examples since then are longer still:

• Google said this week that its internal teams saw Gemini 4 Carbon run for days, persisting through dead ends to find and fix subtle bugs across large codebases.
• Axiom ran swarms of dozens of agents for 24 days and produced about 43.1 million lines of Lean, a formal proof of the Classification of Finite Simple Groups.
• OpenAI said in September that it reached its goal of an automated research intern. Its next goal is an automated AI researcher by March 2028.

But the labs are honest about the limit. OpenAI said that more than half of the successful 4–8 hour agent tasks still needed at least one human intervention. Anthropic wrote that “Claude is not operating fully autonomously for any measured subset of AI R&D work,” and that direction-setting was the only meaningful role that a human played.

So agents can work for days. They still need someone to decide where they go.

Our longest runs

Our longest runs this month were on the EarthBucks 2.0 mine, the Rust server that will run the next version of the network.

On October 4, I opened an issue with one goal: at least 8,000 finalized transactions per second across mines, with 70 milliseconds of simulated delay between them. The agents ran 181 experiments in two days. 67 passed and 114 failed. They did not reach the goal. So I stopped it. The last experiment restored every changed file to the 4,000-per-second baseline, and the issue closed as unsuccessful, with every failure on the record.

On October 6, I opened a new issue with a different plan: rewrite the mine so that consensus runs in memory and the database records only the final result. The agents ran 135 experiments in two days. On the last step, in a local test, the mines finalized 504,000 payments at more than 8,300 a second, each one within one second.

That was a test on one computer, not a network that spans the world, and EarthBucks 2.0 is not live. I explain what is left in The State of EarthBucks 2.0. But look at the shape of the work. Over four days, 316 experiments, each with a design, evidence and a result. My part was a few decisions: the goal, when to stop, and which plan to try next.

The failed issue taught me as much as the one that passed. A long run is only useful if it ends. A run with no end burns tokens all night, and in the morning nobody can say what happened.

What makes a long run work

In We Are All Managers of Super Intelligence Now, I listed four things that an agent needs to work for hours: a goal it can check, checks it can run, a reviewer that is not you, and tools it can reach. This month added two more.

An end. Every run needs a stopping condition. Stripe gives its Minions at most two rounds of CI, then sends the work back to a person. Anthropic gives the same advice: limit the number of iterations. In our factory design, each work item gets three chances to pass review, and then it stops in a state called “human required”. An end is not a failure. It is a place where a person can pick up the work with its full record.

A record outside the agent. A long run is longer than any one context window. The agent forgets. The record must not. Each of our issues keeps its goal, its experiments and its evidence in the repo. On issues that use checkpoint commits, the agent commits each change after it passes its checks, so a crash or a reset loses minutes, not hours. When an agent starts fresh, it reads where the last one stopped.

How many agents can work at once

Width grew even faster than length.

• Anthropic says about 30,000 agents do research and engineering work there at any one time.
• OpenAI researchers used 3.1 agent-workdays for each human workday by mid-August.
• Cursor Projects has a coordinator agent that starts other agents and pull requests, instead of one agent for each task.
• Decagon used one orchestrating Devin with parallel subagents, and reported up to 2.5 times more throughput per GPU.
• Grok Build runs up to eight subagents in parallel.

Most of this runs in the cloud. At Ona’s Background Agents Summit in May, almost every company system ran in isolated cloud sandboxes. The cloud gives you many machines, a fast start from warm snapshots and a small blast radius when an agent makes a mistake. Even Macs are now a cloud resource: Amp rents a cloud Mac with Xcode in about 30 seconds, for $2 or $4 an hour.

Our parallel setup

Ours still runs on one Mac. As I write this, it has 18 branch worktrees, each one a separate checkout for a separate line of work. One command, ah branch, creates a worktree, moves between them, merges main into a branch and merges a finished branch back. Each worktree knows its current issue, so when I switch to it, I know what it is doing.

I run three harnesses: Codex, Grok and Claude Code. Named profiles keep the sessions of each subscription separate, and every agent reads the same rules from the same AGENTS.md files. Inside a session, an agent can also start its own subagents: for research, for a fresh-context review, or for work that does not depend on anything else.

On September 13, after I built the first version of this, I made 175 commits in one day. On October 11, I made 380. Commits are not features: they include plans, results and bookkeeping. But the trend is real.

And width does not stop at the Mac. We now run 14 Grok Bots, each with one job, one schedule and one report. They work every day, whether or not I open my laptop.

What breaks

Length and width each fail in their own way.

Long runs drift. An agent that is wrong at hour one is still wrong at hour ten, only more so. That is why the reviewer matters, and why the end matters. Our failed throughput issue did not need more tries. It needed a different plan, and only a person decided to change it.

Wide runs collide. Two agents that change the same interface under different assumptions make more work than they finish. Builds compete for the same CPU and memory. Merges pile up. Each parallel task needs a clear boundary, its own workspace and its own check.

Both run into me. This is the real limit. Each agent eventually needs a decision: is this good, what next, should we stop? With one agent, I make one decision at a time. With twenty, I make twenty. Today I am also the router: I start the agents, I move work from stage to stage, and I tell one bot when another bot is done. The agents are fast, and the whole system still runs at the speed of my attention.

What comes next

The answer is the same for both multipliers: move the human one level up.

The first step is agents that manage agents. Boris Cherny of Anthropic said that in most Claude Code sessions, “it’s actually another Claude that does the prompting.” When one agent can split a goal, start the workers, review their results and merge them, I manage the manager.

The second step is the factory. In our design, agents ask the factory for work. Each work item moves through a graph with no cycles and ends as deployed or human required. The factory, not my memory, knows where each item is. Then an agent can run anywhere: on my Mac, in a Grok Bot or in the cloud. Length comes from the reviews and the ends. Width comes from the queue. I wrote the full version earlier today, in Inside the Software Factory That Writes All My Code.

Go long, go wide

If you want to try this, start with one agent and make it run long:

1. Write a goal that the agent can check by itself.
2. Give it the checks, the tools and a reviewer in a fresh context.
3. Give it an end: a limit on tries, and a place to stop for you.
4. Keep the record in the repo, not in the chat.

Then go wide:

1. Split work into tasks that do not share an interface.
2. Give each task its own branch and worktree.
3. Make a new workspace cheap enough that you actually make one.
4. Watch what holds you up next. Then fix that.

Your intelligence is not the limit anymore. Your attention is, and the way to stretch it is to make each decision count for more work.

Go long. Go wide.