Orchestrating many agents with Firstmate
- YT :: https://www.youtube.com/watch?v=MSbacZ99E14
- Original title :: High Throughput Agentic Engineering with ex-Meta L8 Principal
Kun Chen, formerly an L8 principal engineer at Meta, Microsoft and Atlassian, walks through his high-throughput agentic workflow live: one conversation with a single orchestrator agent that spawns and supervises everything else. Over the session he drives seven to ten agents in parallel across several of his 36 projects, reviews their work through interactive HTML artifacts, and never opens a worker session. The recurring theme is that human attention, not tokens or context, is the binding constraint - so everything in the setup exists to stop him from context-switching.
The setup
Herder is his multiplexer, a replacement for tmux that manages agent sessions - including sessions on remote machines. Firstmate is his open source orchestration layer: clone the repo, launch an agent inside it, and that agent becomes the one you talk to. It dispatches "crewmates" to do the actual work. He drives it by voice, only typing when he needs to enter something like a URL.
His harness choice is pragmatic: Claude Code for Anthropic models, Pi for everything else because it switches models freely. He is currently on Grok 4.5 rather than the newer 4.6 - 4.5 is faster, more efficient and more to the point, while 4.6 has the same oddly non-human personality he dislikes in Opus 5. His general advice: never assume a new model beats the last one, use it yourself and read what others have found.
A custom Pi extension called calm hides all tool calls and shows only a small floating boat indicating the agent is alive. He does not want to watch file reads and tool invocations - it is noise that costs him the attention he needs for deciding what to build. The details toggle back on when he actually wants them.
Model routing by quota
Dispatch decisions come from a rules file (config/crew-dispatch.json), which he does not hand-edit - he tells Firstmate his preferences and it writes the config. The rules match on task shape: new feature work on his paid iOS app goes to Fable for UI quality; anything needing image generation goes to Codex with GPT-5.6 Soul, since Codex has a native image tool; genuinely hard design, architecture or planning work goes to Fable, Kimi K3 or Astra; well-defined bug fixes with known root cause go to cheaper models like Luna, Sonnet or Cursor's Grok 4.6; everything else falls through to Opus and Cursor Grok 4.6 high.
Where a rule lists several models, Firstmate picks whichever has the most quota left, using Quota Axi - another of his projects, with a TUI for humans and a CLI intended for agents. With Claude, Codex, Cursor and Grok subscriptions running at once, and quotas that reset unpredictably, delegating that bookkeeping removes a task he would otherwise be doing constantly.
He can also override: asking explicitly for Fable crewmates when he knows that quota is plentiful and the task is visual.
Working the queue
A typical exchange is a long spoken ramble of ideas - for his procedurally generated flying game, better snow-capped mountains, randomly appearing northern lights, and a choice of bird species, each idea prototyped in three variants by a separate Fable crewmate in parallel. Firstmate figures out which project this is, finds any pre-existing plan, and spawns the workers.
Two input modes matter: pressing enter steers the orchestrator immediately, alt-enter queues a follow-up that runs only after the current batch. Queuing keeps Firstmate from being derailed mid-dispatch. Because Firstmate never does the work itself, it is always available to talk, so he keeps stacking prompts rather than waiting.
Once the orchestrator is saturated with dispatch work, he scales out with second mates - each a full Firstmate owning one domain, with its own memory, instructions and crewmates. Work for a given app routes to its second mate instead of consuming the top-level agent's attention. He can talk to a second mate directly or let Firstmate relay. Most second mates run on a headless Mac Mini on a shelf, which has more hardware headroom than his MacBook.
Reviewing without reading code
Instead of terminal output, crewmates deliver work as Lavish artifacts - interactive HTML pages with screenshots of the current state, previews of each variant, side-by-side comparison, explanations of the key differences, and a decisions-for-the-captain section at the bottom. He picks birds, rejects a mountain shading study, and asks the agent to go find photos of Everest and K2 and match those peaks - feedback that goes straight back to the crewmate. When the next board arrives it includes the reference photos, proving the agent understood what he meant.
Two built-in skills handle the bookkeeping. Bearings snapshots every active task across the fleet - what is charted, what is underway, what recently landed, and open "captain's calls" that were discussed but never decided. He runs the Lavish variant and works through a dozen pending decisions in a few minutes. Ahoy summarizes everything Firstmate has said since his last message plus any decisions still open - a cheap call he spams whenever he suspects he missed something while reviewing an artifact, because chat UX makes it genuinely unclear whether you read everything.
Guardrails per project
A policy file assigns each project its own risk posture. His toy game is direct PR + yolo: Firstmate makes its own judgment calls, raises a PR, and merges it if it looks good, because nothing depends on it. Other projects require no mistakes - a heavy adversarial validation pipeline - and only some of those also allow auto-merge, typically where a merge does not immediately reach users.
His heuristic for when to spend the tokens: would you have asked another human to review this change? If not, you do not need the pipeline. If the change is risky enough that you would want a peer reviewer, turn it on.
A no-mistakes PR is structured for review without reading the diff: the original intent, a summary of what changed, a risk assessment, and a testing section listing live end-to-end scenarios validated against the running product, with evidence and logs. On the treehouse PR he walks through, nine of ten scenarios ran live and the skipped one was documentation. Low risk plus solid live validation means he does not open the code at all; anything above low and he reads it.
Funnelling work in from everywhere
Firstmate is reachable as a bot on Discord and on X. Mentioning it in a bug-report thread relays the message into his single local session; it investigates via crewmates and replies in the thread. He demonstrates both: a Discord report about a hook not firing, and an X complaint about a confusing settings message. The Discord investigation comes back with a real finding - the hook was not broken, repository-level hooks are deliberately discarded for safety but dropped silently - which he closes out by shipping a warning and having Firstmate post the explanation back to the thread. The point is that every surface funnels into the one session that holds all his intent and context, which is what makes it a useful coordinator.
The orchestrator also absorbs operational friction: when GitHub returned a 500 while creating a PR, Firstmate authorized the retry itself and only mentioned it afterwards.
On context windows
Asked constantly whether to manage context manually, his answer is no. You can save tokens and sometimes improve agent performance by trimming context, but doing it yourself spends the one resource that actually limits you. Set a threshold and let auto-compaction handle it - 500k is reasonable for Grok, and Claude Code's 1M default is too high, so he sets CLAUDE_CODE_AUTOCOMPACT_WINDOW to 500k in his dotfiles. Accept some waste; tooling will close the gap. If your brain is on the context window all the time, you are not thinking about what to build - and getting that right returns far more than these optimizations save.