"Use hundreds of agents" in practice: 10 workstreams, 59 commits in a day, three running at once

Hundreds were allowed; three wrote code at the same time

A minute after the request, the agent started a design Workflow. Workflow is the Claude Code tool that runs many subagents from a single script. This run split the problem by topic (difficulty curve, zoom camera, in-game economy, visual design, store copy, localization) and used 24 agents between 16:09 and 17:01. Because nothing in that phase touched code, eleven of them ran in parallel in the first phase.

The merged spec was committed at 17:18; with a later addendum it is now 1,327 lines. In the implementation Workflow, started three minutes later, forty-one agents handled implementation, adversarial review, fixes and merges for 5 hours 6 minutes, until 22:27. Peak concurrency was three, in stage one: engine rules (ws0), the level generator (ws1), and strings plus build config (ws6). Stages two and three ran two at a time. Screen integration (ws7) and the test harness (ws8) ran alone. Store copy (ws9) went to a single subagent outside the Workflow, which started at 22:36 and finished in 11 minutes.

The agent picked the number three itself. Just before starting, it noted that the machine had 16 cores and 13 GB of RAM with 4 GB free, so it would cap Android builds at two or three at a time. One workstream agent checked memory at 17:28 and saw the same thing:

$ free -g
               total        used        free      shared  buff/cache   available
Mem:              13           8           2           0           2           4

Commits, merges and agents on October 3 and 4

Three sessions worked in this repository over those two days: the Arrow Knots session, an ads-and-release session, and the Block Turn session. The Agent and Workflow columns count calls those three sessions made directly; the last column counts agents launched inside each Workflow. Peak concurrency is the largest number of agents whose first and last log timestamps overlapped.

All 11 merges on October 3 were workstream branches. The simulation workstream (ws2) went in twice because the generator was retuned, which is why there are 11 and not 10. On October 4, three merges were E2E fix branches and three brought in main. One of that day's three Workflow calls resumed the Block Turn research run, and its 150 is a count of log files, so retries are included.

Across this repository's six sessions (September 30 to October 17), the operator asked five times for lots of agents, with phrases like "dozens", "hundreds" and "as many as you like". The main sessions made 53 Agent calls in total, never more than 20 in one session, plus 10 Workflow runs.

RAM, two phones and a file-ownership table set the pace

Build memory was the first wall. The implementation notes say to run ./gradlew --max-workers=4 and to keep one Gradle build at a time per worktree. Every workstream had to pass the engine and app unit tests plus a debug build before each commit, so the number of parallel workstreams was the number of parallel Gradle builds. Research and design Workflows that never build are another matter: this repository ran six of them, and they reached 11 to 14 agents at once.

The phones were a Galaxy S21 and a Galaxy S20, shared by five sessions: the three game-repository sessions plus two sessions from the utility-app repository. So the implementation notes said no workstream touches a device, and E2E happens later on the S21 only. On October 3 and 4 the three game sessions received 148 messages from other sessions, and 114 of them mentioned the S20 or S21. Many were plain turn-taking: "I need it for 10 minutes", "I'm done, it's yours". (From 16:14 to 17:17 that afternoon the S21 belonged to another app's session, running an HWP document-viewer benchmark. The Arrow Knots session lent it on condition that its app data and global settings such as font scale stayed untouched.)

Files got owners too. The workstream table in section 11 of the spec has an "Owns (exclusive)" column. The camera workstream (ws3) edits only Camera.kt, BoardView.kt and CameraMathTest.kt. The ads code and the shared platform module belonged to another session, so workstreams could only read them. Each workstream commits in its own git worktree, and only one integrator agent merges into the integration branch. Splitting agents across worktrees started with How we shipped four Android apps in 20 days with an AI coding agent; this time we added the ownership table.

Forty-one agents reported zero failures, and the app crashed on launch

The implementation Workflow ended at 22:27 with "41 agents completed, none failed". Every workstream inside the Workflow except the simulation (ws2) had been through at least one adversarial review, and the final merge agent had passed the full JVM suite and a debug build. A minute later the app went onto the S21 and crashed right after launch. The level files were the cause: the Android build tool (aapt) strips a trailing .gz from asset names, so the file the code asked for wasn't in the APK. Commit 4d46413 at 22:31 shipped the level packs uncompressed and added a regression test that fails on any asset name ending in .gz.

The detailed E2E pass had 33 items and kept the S21 to itself from 00:36 to 01:41. Thirty-one passed. One failed (stutter while panning large boards), and one was skipped because a debug build can't show it. It turned up 10 bugs and design problems. The Workflow that fixed them used 10 agents, again three at a time, and its three fix branches were merged at 02:23.

What the agent got wrong was the meaning of "done". Keeping workstreams off the phones was the right call. The cost was that 41 "done" reports meant only "JVM tests and compile pass", and every defect that shows up only on a device was pushed into a single queue at the very end. What caught it was one phrase in the operator's original request: install it on the S21 and run E2E. At 01:43 the operator also freed up the S20 for testing. That let a release-build random-input check (3,000 events × 3 seeds, zero crashes) run on the S20 alongside the fix Workflow.

Before deciding how many agents to launch, count how many builds and devices you can run at the same time.

Next experiment

• Would four fit? This time free memory was only sampled a few times, whenever an agent happened to check. On the next parallel implementation run we will log available memory and the number of Gradle daemons every minute, to see whether three was a safety margin or wasted capacity.
• A device lock instead of messages. Replace the 114 device-related messages with a single lock file (who, until when) and measure how much device waiting time drops.
• Where 14 comes from. Five research Workflows all stopped at exactly 14 concurrent agents. We have not yet checked whether that is a tool setting.

FAQ

More AX notes

• Several Claude Code sessions, one repo: the file owner table, checked against 13 merges
• Three agent designs, three judges: the market judge alone would have picked the one that crashed on every KakaoTalk file
• Commits without a Co-Authored-By trailer: the agent made 26 of the 29 we could check
• Running an AI marketer on a schedule four times a day: the permission table that leaves money, accounts and policy to a person
• Pre-gzipping Android assets, measured: zero APK savings, and .pack.gz became .pack with a FileNotFoundException
• A market:// link opens a store chooser on SKT-sold Samsung phones: set the Play package first

All notes on Working with agents · All AX notes