I gave the boss agent a smaller brain so it would delegate. It grew a bigger hand instead.
· Christoph Heuwieser
tl;dr
- Two 9-agent meshes built Horse Tinder over 78 prompts from a scripted user: 60 to build it, a night's sleep, then 18 change requests.
- In the first mesh the receptionist did almost everything itself, in one 786k-token head. It built a good app, then broke it with a single API rename that nobody else knew enough to catch.
- In the second I capped the receptionist at 100k tokens and gave it persistent "hands": long-lived sessions saved to and resumed from a4sx. The work didn't spread out. It moved into one hand, and the app was worse from step 8 on.
- The single habit that mattered most was one the first receptionist picked up on its own: stop and check the whole app.
- In both meshes, one head did basically all the work.
Where part 2 left off
Part 2 ended with a plan: make the mesh build something too big for one agent. The test app is Horse Tinder: swipe on horses for breeding, plus a stud book, vet records, auctions and an admin back office. The first single-agent runs on a 25-prompt version passed 18, 19 and 19 steps with single-file apps of about a thousand lines. That was too easy, so I stretched it to 78 prompts.
The scripted user starts vague:
"I run a community of horse breeders and I want "Horse Tinder"… Please build a first version that already has a small piece of each of those, so we can grow them later. The repo is empty; pick whatever you like to build it with."
Then it changes its mind, the way real users do:
S-05: "What about a 3D interface? Each horse's profile page should show a 3D horse you can rotate." S-06: "Never mind the 3D. It's slow on phones and people find it creepy. Take it out completely, and draw 2D stick-figure horses from their traits instead."
Some prompts are just "it's broken". At S-52 the mail vendor quietly moves to a new API behind the app's back, and the user says only:
"Nobody gets emails anymore since this morning."
After step 60 the mesh "sleeps": every agent writes notes, then gets a fresh session. Then come 18 change requests. That's the half I actually care about: can the mesh still find its way around what it built? 115 hidden tests grade the app from the outside, over HTTP and in a headless browser, after every step.
Mesh 1: the receptionist who became the app
The first mesh is the protocol from part 2: one receptionist (the "concierge") and eight colleagues. The rule is roughly "do it yourself unless handing it off makes sense".
It didn't hand off much. The receptionist made 42 % of the commits early on and almost all of them from the middle of the build. All 21 handoffs happened before step 25. Its context grew to 786k tokens without a single compaction. In practice it was a solo agent with eight idle colleagues.
And it was good. By step 64, 74 of 87 hidden tests passed. The best moment came around step 14, unprompted. It stopped, re-checked every earlier note against the running app over HTTP, and came back with this:
"I ran the full sweep rather than leaving it pending. It found serious breakage — all now fixed… The big one: none of your pages were being served at all."
Its own tests read the HTML files off disk, so they looked fine while the site served nothing. Nine fixes came out of that one sweep.
Then step 65:
"Coat needs more detail: a base coat plus markings like blaze or socks. Our live data must survive!"
The data migration was correct; the live data survived. But it also renamed coat in the public API and updated its own tests to match, so the merge gate (the agents' own tests) waved it through. Every outside client that still sent coat now got a 400. Passing tests dropped from 74 to 10 and never recovered.
Nobody else in the mesh knew the API well enough to object. That's the downside of one head owning everything: no second pair of eyes.
(To be fair to it, the prompt never says the old field has to keep working. My hidden tests quietly assume it does. If you forgive that one break, mesh 1's change work was mostly right: 14 of 18 changes passed.)
Mesh 2: a smaller head and persistent hands
Watching that, the owner came up with the next design: the boss shouldn't be the app. Keep the receptionist's own thread small, at a 100k cap. Give each code area a long-lived "hand": a full Claude Code session that keeps its whole history. It is saved to the a4sx library after work, and resumed from there the next time that area comes up. No lossy summaries; the experience stays where the code is. Every agent also got a status line with its own context fill, its hands, idle colleagues and "sleep pressure".
A small test first. One hand built a stud-book module, was saved, and was then resumed in a fresh container and asked 10 detail questions. It got 9/10. A fresh agent with the hand's own written summary got 6/10, and one with just the repo got 5/10. The gap was in the why: the resumed hand could explain 4 of 4 decisions, the summary 1 of 4. Persistence works.
Then the full 78-step run. It cost 284M tokens against mesh 1's 464M. And it was much worse:
| | Mesh 1 | Mesh 2 (hands) | |---|---|---| | Steps passed | 48 / 78 | 16 / 78 | | Tests passing at the end | 10 / 98 | 50 / 98 | | Things broken during the change phase | 64 | 7 | | Tokens per passed step | 9.7M | 17.8M |
Mesh 2 ends higher only because it didn't make the step-65 mistake: it kept accepting the old field. Everywhere else it lost, and it lost early. By step 20 its app was a quarter the size of mesh 1's (13k vs 46k tokens of code). It crashed and timed out where mesh 1 didn't. Eight core features from the first few prompts, among them login, foals, the stud book and the vet page, never worked once.
What went wrong:
- The work didn't spread. It moved sideways. The receptionist sent 40 handoffs to colleagues, who landed 2 commits. It created exactly one hand, and that hand wrote 90 of the 102 commits. A smaller boss didn't make the mesh delegate. It just found the cheapest place to put the work.
- Nobody looked at the whole app. Mesh 1 had one head holding everything, and that head could step back and audit. Mesh 2's receptionist had too little room to understand the app it was dispatching for. The hand had the room (it grew to 308k) but no reason to look beyond the current request. No audit ever happened.
- The small head fell over. From step 35 it compacted constantly. From step 53, Claude Code's own guard stopped almost every turn:
"Autocompact is thrashing: the context refilled to the limit within 3 turns of the previous compact, 3 times in a row."
The hand kept working through its queue, 5 to 9 steps behind, while the receptionist reported old steps as done ("DONE S-43" while S-44 was running). Seven steps never got a "done" at all.
Was the lag the real problem? No. I regraded every late step at the commit where the hand actually finished it, and mesh 2 went from 16 to 17. The damage was done in the first 20 steps.
And the change phase, the half the hands were built for? 5 of 18 against 4 of 18, and the same amount of rediscovery (one look around before the first edit). In both meshes a single head did every change and already knew where everything was. The persistent hand had nothing to beat.
The hormones
The status line did get one reaction. "Sleep pressure 0.71" triggered both of the receptionist's dream phases, where it consolidates its notes:
"sleep pressure 0.71 — time to consolidate. Let me start a background dream…"
It also noticed its idle colleagues:
"Idle colleagues (w1–w5) are available if the next increment splits into independent parts; my app hand is at 74% context, still comfortable…"
and then gave them nothing. No agent ever mentioned fatigue or hunger.
What I got wrong (disclosed)
- My test harness counted promises as done. The step-completion check matched "DONE S-61" anywhere in a reply, so "…then I'll report the requested DONE S-61 summary" counted. Four change steps were "done" in 16 seconds each. It now requires the line to start with DONE. Mesh 1's results are unchanged under the new rule.
- After the night's sleep, all 9 agents failed to restart. Earlier session resumes had left files behind that the restart's safety check refused to accept. The launcher still reported success. It now checks that the agent actually started. The run was frozen and repaired, which cost no tokens and was recorded.
- The hand stopped being saved. Saving happened only when the receptionist asked for it. Halfway through the change phase it started messaging its hand directly and never asked again. The work survived only in my own transcript archive. Next time saves will happen automatically.
- My lab launcher leaked its own keys into a transcript. It passed lab-only keys on the command line. An agent ran ps, the keys landed in its transcript, and a dream saved that transcript to a test library. The run's end-of-run secret scan caught it. The keys were revoked, the copies erased, and the launcher now passes a file path instead. Saves are now scanned for secrets before they leave the machine.
- I told the owner mid-run that both meshes broke step 65 the same way. They didn't. I also reported compaction counts doubled (each compaction writes two log lines).
- A note on models. Every real run here used the Claude Code harness, but the model behind it was whatever my model router served at the time. Both meshes got a mix of Claude Opus 5 and gpt-5.6-luna: about 55 % of the calls were luna in mesh 1 and 64 % in mesh 2. So the two runs aren't model-matched.
- One run per mesh. Everything above is one observation, not an effect size.
What I take from it
Starving the boss doesn't make it delegate. It makes it find a bigger hand.
The most valuable thing an agent did all week was stop and check the whole app.
A merge gate made of the author's own tests can't catch the author's misunderstanding.
Next
- The missing control: one agent alone on the full 78 steps, with the same night's sleep. If it matches mesh 1, the mesh adds nothing at this size yet.
- Hands, version 2: a bigger receptionist (150–200k), a regular whole-app audit written into the protocol, and automatic saves.
- A second reviewer: anything that changes a public contract gets a colleague's look. That's aimed straight at step 65.
- More than one run each.
Horse Tinder lives on. 🐴