54 Coordinators later

In my last memo I wrote that my mid-size delivery workflow runs fully on my graph-walker engine. What stopped since then is expanding it. On 29.10 I started Pipeforge again from zero, on new branches, while v1 kept running the fleet. This memo is about the ~2.5 weeks since then: what changed in the four-level setup that runs my agents, what broke along the way, how I now answer the fleet's questions from my phone, why I didn't move to an existing tool, and where the rewrite is going.

The four levels themselves hold up very well. It's still the same four roles from my first memo: a Coordinator, Supervisors, Orchestrators and seats. As of 03.11.2026 there have been 54 Coordinators since 25.09, together with 130+ Supervisors and ~510 Orchestrators, so ~690 management sessions, plus a very rough ~6,900 seats doing the actual work. What changed is mostly what each role is responsible for, and how much it costs a session just to start.

That cost was the first problem. Start instructions kept pulling in earlier reports, which pulled in the ones before them, and at some point a worker seat booted at over 300k tokens of context before doing anything. Everything swelled like that within one night, even though I had already taken some steps to prevent it. One seat that handed over at ~400k had a successor that re-read ~89% of what its predecessor had read, and then parked. Handing over took more than the task itself. The fix was simple: stop loading earlier reports by default, and then turn boot and handoff into proper skills. Seats now start at 20-80k, and a Coordinator at ~110-140k instead of ~150-170k. Supervisors haven't improved yet (~160-175k), so there are still cuts to make, but I can already see a Coordinator working longer before it needs a successor. I also added a retro skill, the loop you often hear people talk about, to find what to fix next.

The bigger problem came out of an experiment. I wanted to finish the walker in Pipeforge itself, and I let the agents work more autonomously than usual, without checking the scope of what they decided to build. They had to make a plan and verify it, but I didn't look at what was being done, and I let it spin for a longer time. To my surprise, every blocker got the same answer: more machinery built around it to get past it. Building that machinery hit the next blocker, and the Coordinator decided to work around that one too, with another layer on top. I tried to stop it three or four times, and each time the next Coordinator went back to the same mode. The agent didn't persist my ruling in its proper source, but worked from the handoffs instead, and there it got lost.

That showed me a pattern. When a repo already has guards in it, AI adds more guards by default, even when I've told it not to, and after a while it goes back to that mode anyway. In my full pipeline it wouldn't get that far, because planning and research would cut those things right at the start. Here I wanted to see how AI handles it today without such detailed, smaller steps. It turned out it doesn't handle it yet. On 29.10 I decided it had gotten too messy and started Pipeforge from zero, and the same evening I wrote down the rule the new version runs under: every decision to build something or add it to scope must tie directly to the core of what's being delivered, otherwise it goes to the deferred list. When the old guards were reviewed for the new version, 55 of 68 were proposed for removal (~81%). Most of that machinery did nothing but make work harder.

What helped the most in daily work was how I answer questions. Before, they came up in chat, and when I stepped away, they got buried behind many turns, and sometimes the reminders just stopped. That's fine while I sit at the computer, but the whole system is meant to keep going when I'm not there. Claude Code has artifacts, and they can be interactive, so I built a very simple question system inside one. Whenever a session needs a decision, the Coordinator writes the question there. I open the artifact on my phone, read it (the questions are detailed enough now that I can tell what's going on), and answer. The Coordinator checks for new answers on its 55-minute tick and continues the work from them. Since 02.11 it's the primary channel for the fleet's questions to me. I still sometimes talk to the Coordinator directly, and I use the Desk from my computer too, not only from the phone. It holds 71+ decisions so far, and I took the recommended option in about 2 out of 3. I could have built the same question-and-answer model as an MCP server reachable from my phone, and the effect would probably be the same. But my Coordinator runs in Claude Code, so the artifact was the tool I already had. With another vendor as the Coordinator, Codex for example, I'd have to find an alternative.

The second piece is Remote Control. It's native to Claude Code, and herdr is what lets me turn it on remotely. So every new Coordinator starts with it on, and the Coordinator from two generations back gets closed at the same time. That way I always have the two most recent Coordinators on my phone. And when I need, say, an assistant session, I ask the Coordinator to open one with Remote Control on, and I work with my local machine fully from the phone, with no extra external tools.

Being away has its funny side too. One evening the Coordinator asked me whether I had cleared a dialog in a test pane myself, because no session admitted to it, and it had the log timestamps to back the question. It was me.

Along the way the question came up whether I should use an existing tool instead of building my own. I looked at Cezar, T3 Code, Gas City, Orca and a few more, and piloted Gas City in a sandbox. My hard requirements are interactive Claude Code sessions (no -p), subscription billing, and an external next() that owns the order of steps. Cezar fails the first one. Gas City and Orca do run interactive sessions, and the Gas City pilot even ran my four levels with messages going down and up. But moving to either was estimated at ~52-124h, and I'd still have to register every new session and level against the state on the server and keep an external next() in charge of the steps. In my judgment that's close to the same work as building my own from zero.

The -p requirement is critical for me. On 14.05.2026 Anthropic announced that headless use, -p included, would get its own separate budget from 15.06, and then paused the change on 15.06. Their Help Center says that, for now, -p still draws on subscription limits. If that changes, any setup built on -p moves to API billing overnight, and for a fleet this size I'd have to find a replacement as fast as possible.

So I'm rewriting Pipeforge, together with a web page for managing its whole configuration. From zero means a completely new architecture and structure on new branches, and once the system works, I'll swap it in. Until then v1 still runs the fleet, and parts of v2 go into use as they land. I keep what was good and effective in v1. Agents move over as v2 needs them, and every new instruction, skill and agent goes through a trimming skill meant to cut the prose while keeping the behaviour. I'm aware that bugs I patched before may come back along the way. But seeing how models handle work today, even without much instruction, I think naming the steps without spelling out how to do them may give much better results. Anthropic wrote some time ago that they "removed over 80% of Claude Code's system prompt" with no measurable loss on their coding evaluations. I want to run a similar experiment on my own harness and see whether the quality is comparable to v1, and how much context I can cut.

One example already in use is how sessions start and stop. Before, every session read a ~38 KB recipe file on how to drive herdr. Now quitting a session is one command keyed to its name, and starting a seat is one command that takes the seat's model and effort from one global setting on the server. Quit is in use. Starts still go the old way while the switch finishes. Messaging comes next: a session sends to "my parent", and the server works out who that is right now, so no session has to track another's name. That part is designed, not built.

The server itself is now an HTTP API on FastAPI that the CLI calls, so what is CLI and what is MCP is clearly separated, instead of the "MCP to CLI bridge" I had before. MCP will shrink to just the few methods an agent needs for discovery from inside a conversation. The walker and the mini-deliver atoms are already in v2, and the first real task through mini-deliver end to end is the next step. It hasn't finished yet. The first attempt was blocked by a seat guard, so the cutting isn't done.