--- title: "I Stopped Being the Switchboard for My Coding Agents" description: "A decision memo on moving from agent-by-agent coordination to Firstmate and Herdr: isolated worktrees, durable state, supervised loops, decision gates, and evidence-backed PR handoffs." publishedAt: 2026-07-18 updatedAt: 2026-07-21 tags: - agents - coding-agents - ai-workflows - developer-workflow - testing answerSummary: - Firstmate is becoming my single point of contact for multi-agent development, while Herdr is the visible surface where execution and supervision happen. - The reusable operating model is deterministic task boundaries, isolated worktrees, durable briefs and state, bounded loops, explicit authority gates, and evidence-backed PR handoffs. - More agents are not the model. Concurrent work only helps when review, supervision, branch bases, and merge authority can keep up. - "A real CI billing freeze showed the model under pressure: Firstmate coordinated the recovery, while I chose the runner and organization boundaries and kept the final authority." faqs: - question: "Does running more agents create a better development process?" answer: "No. More agents only create useful concurrency when task boundaries, durable state, supervision, authority, verification, and merge discipline are explicit." - question: "What do Firstmate and Herdr change in this workflow?" answer: "I use Firstmate as the single contact boundary for coordinating work and decisions, and Herdr as the visible execution surface for watching progress, gates, and handoffs." - question: "Am I already running thousands of agents?" answer: "No. Larger agent fleets are an ambition for the operating model, not a measured claim about my current usage. Boris Cherny's X post describes an adoption pattern and references a longer artifact with four stages; because that artifact is not publicly readable to me, neither source establishes an agent count or operating guardrails for my workflow." - question: "What happened when this operating model met a real infrastructure problem?" answer: "A weeks-long GitHub Actions billing freeze was recovered in two moves: I added a hardened self-hosted runner on home infrastructure, then consolidated the CI repositories into a GitHub organization with its own Actions minutes. Firstmate coordinated the work through Herdr while I made the boundary and authority decisions." draft: false coverImage: /images/posts/i-stopped-being-the-switchboard-for-my-coding-agents-cover.webp coverImageWidth: 1536 coverImageHeight: 1024 --- I changed the operating model for how I move software work through multiple agents. The old model made me the switchboard. I opened an agent for a task, explained the repository, repeated the branch rules, watched the work, answered the next permission or product question, and then reconstructed the state when another agent or another project needed attention. I could make progress, but too much of the system lived in my ability to remember which conversation knew what. The new direction is Firstmate running through Herdr. Firstmate is becoming my single point of contact. Herdr is the visible execution surface where I can see which work is moving, which work is waiting, and which decision belongs to me. That puts this note in the [AI coding agents reading path](/topics/ai-coding-agents/), but it is not a product announcement. It is a decision memo about the process change and the parts that are still uncomfortable. ## Original assumption I used to think the main constraint was the number of agents I could keep busy. If one agent could work on one task, then several agents should let several projects move at once. That is true only in the narrowest sense. The hard part was not starting another session. It was keeping the work legible after it started. Every additional agent created another stream to coordinate: - What exact task is it responsible for? - Which branch and worktree are safe for it to use? - What context does it need without receiving a private transcript? - What counts as proof that the task is complete? - Who can approve the next irreversible or externally visible step? - How does its result become a reviewable handoff instead of another chat summary? When those answers were implicit, I paid for the ambiguity with back-and-forth. The agent would ask for context I had already given elsewhere. I would ask for progress because the watcher did not make the state obvious. A branch could be correctly named but based on the wrong starting point. A trust gate could be legitimate, or it could just be a sign that the task boundary was underspecified. None of those failures meant the model was incapable of the work. They meant I had not made the work a durable unit. ## What changed The useful unit is no longer "a conversation with an agent." It is a bounded task with a place to work, a brief to recover from, a loop with a stop condition, and an evidence-backed handoff. ```text durable brief -> isolated task worktree -> supervised, bounded agent loop -> explicit decision or authority gate -> evidence-backed PR handoff ``` The worktree is part of the boundary, not just a way to avoid file collisions. One task gets one isolated place to change files. That makes concurrent work possible without pretending that concurrent edits to the same working tree are safe. The brief and state are also part of the boundary. They carry the goal, scope, known risks, proof to run, current status, and next action. I want an agent to be able to resume from that state without requiring me to replay a conversation. That is the same reason I prefer [user-visible, controlled memory over silent accumulation](/posts/dont-give-your-agent-memory-before-user-control/): durable state is useful when its owner can inspect and correct it. The loop is supervised, but it is not supposed to be a live chat that I nurse turn by turn. A bounded loop can work for a while, stop at a known condition, and return evidence. I still need to be available for a product choice, a trust decision, or a boundary the agent cannot safely infer. I do not need to answer every low-value progress question in the middle. Finally, the output is a PR handoff. A useful handoff says what changed, what was actually verified, what remains uncertain, and what decision is next. It does not ask me to trust a green-looking status line. ## Firstmate became the point of contact Firstmate changes my role from direct coordinator of every agent to owner of the task boundary and the decision gates. I can bring a project-level goal to one place, let the work be routed into an isolated task, and return to a durable status instead of remembering which agent was carrying which piece of context. That is the part that matters to me. A single point of contact is valuable because it compresses coordination, not because it hides execution. The boundary still has to stay honest. Firstmate should not become a magical black box that makes authority disappear. I want to know: - which task is active and what its exact stopping condition is - which project and branch base the task belongs to - whether the agent is working, waiting, or asking for a decision - what evidence it produced before the handoff - what remains under human authority That is why Herdr matters in the same design. ## Herdr became the visible execution surface I think of Herdr as the place where the running system becomes observable. It is where supervision has a surface instead of being a feeling that I should check another terminal. The useful visibility is not a wall of logs. It is state that answers the next human question: is this task progressing, waiting on me, blocked by capacity, or ready to review? This is also where the unfinished friction shows up. Watchers can be noisy. A long-running agent can produce little output while still working, or look quiet because it is waiting at a gate. The execution surface needs to distinguish those states without making me open every session. Capacity limits can still constrain what runs concurrently. Trust gates can still create pauses. Better visibility does not remove those constraints; it makes them easier to name. ## The day the model met real infrastructure The clearest test arrived today. My GitHub Actions had been frozen for weeks by an account billing and spending block. Pull requests piled up across several projects, and the work was effectively unmergeable. This was not a demo failure; the shared delivery loop had stopped. Firstmate drove the recovery. It supervised a fleet of coding agents across my projects while I stayed the captain making the decisions that mattered. The agents ran through Herdr, so the work had the same visible execution and handoff surface I had been designing in the abstract. The first move was to build a dedicated self-hosted GitHub Actions runner on my home Proxmox server. I reclaimed disk by retiring an old VM, then provisioned a hardened, unprivileged, single-tenant runner as infrastructure-as-code. CI could now run on hardware I controlled instead of depending entirely on GitHub's billed minutes. We proved the path green end to end. The cleaner structural fix was the second move: I consolidated the CI repositories into a GitHub organization on the Team plan, with its own Actions minutes. The transfers preserved deploys, secrets, and cross-repository dependency references through redirects. That gave CI two useful lanes: the organization's hosted minutes and the self-hosted runner for offload. The payoff was concrete. CI ran again, and a backlog of frozen pull requests thawed and merged the same day. I still made the calls about infrastructure boundaries, repository ownership, and verification. Firstmate coordinated the diagnosis, delegation, and recovery; Herdr made the execution legible. An AI fleet was useful here because it repaired real infrastructure under supervision, not because it made the captain disappear. ## The deeper distinction: agents are not the operating model The tempting metric is the count of agents. The operating model is the set of controls around them. I need deterministic task boundaries so two agents do not quietly own the same change. I need durable state so context survives a pause. I need supervision so long-running work remains observable. I need authority rules so an agent can prepare a change without silently deciding to merge, publish, or cross a trust boundary. I need verification and merge discipline so a completed loop means something beyond "the agent stopped talking." More agents without those controls create more coordination debt. They can make the captain feel busy while the review queue, decision queue, and branch graph become harder to understand. The [rendered HTML check in the AEO approach I trust](/posts/aeo-from-the-jump/) is a useful analogy from the publishing side: source intent is not enough; the assembled output has to prove that the pieces still agree. Multi-agent development has the same shape. A task brief is intent. The worktree, tests, review, branch, and PR are the assembled output. ## The outside signal I trust Boris Cherny's [July 17, 2026 post on X](https://x.com/bcherny/status/2077929379661844559) gave me a useful external check on this decision. He described hearing the same adoption pattern across engineering teams: one person gets dramatically more output from Claude while the rest of the organization has not caught up. He said he keeps seeing the same four adoption steps and linked to a longer artifact. I verified that canonical URL, attribution, date, and public post text through X's public oEmbed endpoint on July 18, 2026. That artifact is not publicly readable without an account, so I am not treating its contents as evidence here. The operating details in this memo are my conclusions from the workflow I have been building: end-to-end verification, explicit permission and authority defaults, interfaces for managing multiple agents, worktree isolation, bounded loops, and evidence-backed review. Those are operating-model decisions, not claims made by the public X post and not an agent-count contest. There is an important source boundary here. The X post does not say that Boris is operating "thousands" of agents, and it does not establish a measured agent count for my workflow. I am treating large agent counts as an ambition for a possible operating stage, not as a result to copy into this article or a number I have measured. His [July 15 post about automation as infrastructure](https://x.com/bcherny/status/2077460395279692197) lands the same lesson from another direction: automate recurring classes of work and encode domain knowledge so every future contributor does not need the same explanation. That is close to what durable briefs, state files, review rules, and task gates are doing here. ## What I would reuse I would reuse five patterns across projects: 1. **Name the task before starting the agent.** The goal, boundaries, and proof should be legible without a private transcript. 2. **Give the task an isolated worktree and explicit base.** Branch-base ambiguity is a small detail until a good change is based on the wrong history. 3. **Make state durable and recoverable.** Progress, decisions, blockers, and next action belong in a handoff artifact that another worker can read. 4. **Supervise by exception.** Longer bounded loops are useful when the stop condition and escalation path are clear. Frequent low-value interruptions are not supervision; they are coordination overhead. 5. **Treat the PR as an evidence contract.** The handoff should make review and merge decisions smaller, not move uncertainty downstream. The [agent workflow I built for AEO work](/posts/i-built-an-aeo-agent-workflow/) made me more skeptical of workflows that report completion without showing what was checked. The same standard belongs here: a fleet should return evidence, not just activity. ## What I am changing next The next version of this process is deliberately less theatrical. I am moving toward longer bounded loops, fewer low-value interruptions, project beads tracked with `br`, and task branches cut from a protected main with an explicit base. I am also moving toward a mixed Codex, Claude, Grok, and Pi/Kimi K3 fleet, choosing a worker for the task rather than treating one model as the identity of the whole system. Those are directions, not claims that every project already uses the same setup. Protected main, project-level beads, watcher behavior, and the mixed fleet are still being brought into one consistent operating model. The next proof I want is measured fleet throughput: how many bounded tasks reach trustworthy PR handoffs, how often they stop for real decisions, and where review capacity becomes the bottleneck. I am not interested in publishing an agent count without that evidence. The goal is not to make the captain look like he commands a larger fleet. The goal is to make more projects move concurrently while keeping authority, state, and merge quality visible. That is the decision: Firstmate owns the contact boundary, Herdr exposes the execution, isolated tasks carry the work, durable state carries the context, and the PR carries the proof. The fleet can grow later. The operating model has to earn that growth first.