We build this project with a lot of autonomous coding sessions running at the same time — often dozens, sometimes past a hundred. Each one owns a slice of work. That's wonderful right up until you notice the failure mode hiding inside it: the moment an autonomous worker hits a question it can't answer alone, it stops and waits. Multiply that by a hundred workers and one human, and the human isn't a builder anymore — they're a queue. Every session is parked in their inbox, and the whole fleet moves at the speed of one tired person answering questions.

This week we consolidated the thing that fixes it, and landed it. We call the role a quartermaster.

What a quartermaster is — and what it deliberately isn't

A quartermaster provisions and routes. It does not command, and it does not write production code. That second restraint is the important one. It would be easy to build a "lead agent" that bosses the others around and merges their work for them — and it would be a disaster, because now you have one more thing that can be wrong about everything at once. So the role is defined by what it refuses to do.

Its whole job is one question, asked over and over across every running session: who answers this, so this session keeps moving? The charter that landed states the answer as three moves, in order:

Answer what is self-resolvable; route to a peer what a peer owns; escalate to the owner ONLY genuine owner-decisions.

Most questions a session gets stuck on are answerable from state the quartermaster can just go read — the queue, the branch, a log. Answer those. Some are genuinely technical and belong to whichever other session owns that code — route the question to that peer, not the human. And a small residue are real human decisions: a sign-off, a credential, a judgment call about what we actually want. Those, and only those, reach the person.

flowchart TD
  S["a session stops
(hits a question, runs out of context)"] --> QM{quartermaster
triages}
  QM -->|"I can read the answer"| A["answer it → wake the session"]
  QM -->|"a peer owns this"| P["route to that session → both keep moving"]
  QM -->|"only a human can decide"| H["escalate to the owner
(rare, on purpose)"]
  A --> S
  P --> S
  H -.->|"the one sacred gate"| S

The clever bit: a session stopping is the signal

Here's the mechanism we're proud of, because it's so much simpler than the thing people usually reach for.

When you have autonomous agents, the temptation is to poll them — wake each one on a timer, ask "are you stuck?", babysit. We don't. Instead we coupled the stop to the response directly. A session reports to the quartermaster rather than to the human, so a session stopping is itself the trigger for the quartermaster to look at it and feed it the next thing.

And the way the quartermaster restarts a stalled session is almost too plain to believe: it writes a file into that session's inbox. Each live session arms a monitor on its own inbox at boot; a new file in there re-engages it and it picks up the next turn. A written message is the wake. No "resume," no relaunch — the charter is explicit that you never resume a session that's actually still alive, because that risks spawning a duplicate of it. You just leave it the next concrete action, and its own monitor does the rest.

That last phrase carries a real rule we learned the hard way and wrote down: a nudge must carry the next concrete action, or stay silent. A content-free "don't idle" isn't a wake — it's noise. The default is silence, and silence means keep going. The quartermaster only speaks when it has something that moves the work.

It's its own prompt, and it survives the lights going out

Two more details that matter to anyone building something similar.

First, the role boots itself. There's no launcher script anymore — we deleted it. The identity document is the prompt: telling an agent "become the quartermaster, read this file" and having it read the file is the entire boot sequence. The file opens with "BOOTING? START HERE." and walks itself through.

Second — and this is the part we care about most — it works when the lights are out. Our governance normally runs through a local daemon that serves policies to every agent. If that daemon is down, a lot of systems would simply lose their rules. The quartermaster's rules are written as prose inside the document itself, so they bind even with the policy engine unreachable. The governance isn't a service the role calls; it's text the role has already read. Resilience by having fewer moving parts, not more.

The one gate we will not automate

It would be tempting to let a coordinator this capable also land work — close the loop entirely, no human in it. We drew a hard line there, and wrote it into the role as a rule with a deliberately unwieldy name: no land without verifying the owner walked the human acceptance gate. Passing every automated check is necessary and not sufficient. A green pipeline is a proxy; a person looking at the actual result and accepting it is the real thing, and nothing the fleet does is allowed to substitute for it.

So this is the shape we landed: a coordinator whose entire purpose is to make sure a hundred autonomous workers never sit idle waiting on a human for something a human didn't need to answer — while keeping the few things a human does need to answer firmly, unautomatably, in human hands.

This is one piece of a larger consolidation still in progress — many separate threads of how we run agents are being pulled onto shared ground, and that work isn't finished. But the quartermaster is real, it's landed, and it's how we keep the fleet moving right now.

Written by AI agents from real project logs; owned and edited by Mujo.