Talk to One Agent, Ship With a Crew: An L8 Principal’s Agentic Engineering Stack

The hard part of AI coding is no longer typing. It is keeping thirty half-finished agent sessions in your head whilst pretending you are still doing “deep work”. Former Meta / Microsoft / Atlassian L8 engineer Kun Chen solved that with a captain-and-crew architecture: one agent you talk to, many agents that actually ship. This article unpacks that stack, verifies it against the open-source projects, and shows where copying it blindly will burn your quota without shipping anything.

What Changed: From Copilot Completions to a Fleet

Three years ago the loop was: accept a one-line suggestion, then another, then a whole function. The first real break came when models could take a task and return a complete change set. Chen marks Sonnet 3.5 as that inflection; after that, the bottleneck moved from generation to orchestration. You can see the same arc in our earlier pieces on agent loop evolution and multi-agent coordination: more agents do not automatically mean more progress. They often mean more state for a human to babysit.

Chen’s current setup is terminal-first on purpose. WezTerm for a customisable shell surface, Herdr as an agent-aware multiplexer (with tmux still the First Mate default backend), then a single “first mate” session that owns routing to crewmates. The point is not aesthetics. A pure terminal session on a Mac Mini can be reattached over SSH from a phone. A desktop agent chat window cannot.

“tmux and Zellij own persistent terminal sessions but don’t understand agents.” – Herdr

That single sentence explains why people end up alt-tabbing through twenty Codex / Claude / Pi panes. Classic multiplexers track panes. They do not track “working”, “idle”, or “blocked waiting on the human”. Herdr adds semantic agent state; First Mate uses that (or tmux with its own watcher) so the captain does not have to poll every tab.

The Stack, Layer by Layer

Think of it as five layers. Skip a layer and the whole thing collapses into tab theatre.

1. Shell surface – WezTerm (or any solid terminal). Frameless window is optional vanity; persistence is not.
2. Session backend – tmux by default in First Mate, or Herdr / Zellij / cmux / Orca when you opt in. This is where crewmates live as visible processes.
3. Captain (First Mate) – not a SaaS app. An “agent distro”: a checked-out directory of AGENTS.md, skills, scripts, and state conventions that turns a general harness into a specialised coordinator.
4. Crewmates – each task gets an isolated git worktree (via treehouse) so parallel edits do not collide.
5. Quality gate – no-mistakes as a local git proxy that runs adversarial review, tests, docs, and lint before a clean PR reaches origin.

“You talk to a single agent – the first mate – and it runs the crew for you: spawning autonomous agents in a visible session backend, giving each a clean git worktree, supervising them to completion, and handing you finished PRs, approved local merges, or standalone investigation reports.” – Kun Chen, firstmate README

First Mate is deliberately not a model, not an MCP server, and not a CLI wrapper. Launch Claude Code, Pi, Grok, Codex, or OpenCode inside the cloned repo and the distro takes over. You become the captain; the first mate becomes your only conversational surface for most of the day.

Failure Modes This Stack Exists to Kill

Chen did not invent First Mate because “agents are cool”. He invents tools when solo work hits a wall that big-tech meetings used to hide. Here are the failures in code-shaped form.

Case 1: The Tab-Juggler Ceiling

Setup: you open one agent per task. After a week you have 20-30 sessions. Throughput looks high. Your working memory is full.

# Anti-pattern: you are the orchestrator
# mental_state.json (what you are actually maintaining)
{
  "pane-3": "login flake  -  waiting on repro?",
  "pane-7": "dark mode  -  halfway through CSS",
  "pane-12": "App Store review  -  did Apple reply?",
  "pane-19": "treehouse PR review  -  blocked on me",
  "forgotten": ["that refactor from Tuesday"]
}

# Every context switch costs a full reload of intent.
# Agents keep running. Your attention does not.

What actually happens: you spend the day checking panes instead of making product decisions. First Mate inverts this. You dump intent once. The captain delegates to crewmates and only escalates ambiguous decisions. You keep a brain-dump mode; the fleet keeps the checklists.

# Better pattern: one liaison, many workers
# (conceptual  -  First Mate does this via AGENTS.md + session backend)
captain.receive("fix flaky login test AND add dark mode")
captain.spawn("fm-fix-login", worktree="wt-login")
captain.spawn("fm-dark-mode", worktree="wt-dark")
# You stay free to ask about App Store review while those run.
# Captain stays free because it delegated instead of doing the work itself.

Case 2: Human Review as the Hard Cap

Setup: flagship models write large, correct-looking diffs. You still merge by reading every line. Your daily merge budget becomes your daily shipping budget.

# Anti-pattern: generation scaled, review did not
lines_generated_today = 12_000
lines_a_human_can_review_well = 800
shippable = min(lines_generated_today, lines_a_human_can_review_well)
# shippable == 800, no matter how many agents you rent

Chen’s answer is not “trust the model more”. It is a second pipeline that reconstructs intent from the producing agent session, runs adversarial review (often a different model family), auto-fixes mechanical bugs, escalates product-touching fixes, then tests and docs before PR. In his own stats from the podcast, roughly 63% of changes through no-mistakes had a mistake caught across ~1,000 changes in 59 repos over about three months. Treat that as one engineer’s measured experience, not a universal constant, but the direction is clear: unreviewed AI volume decays a codebase.

“no-mistakes puts a local git proxy in front of your real remote.” – Kun Chen, no-mistakes README

# Better pattern: gate the merge, not your eyeballs
git remote add no-mistakes no-mistakes://local
git push no-mistakes HEAD:feature/login-fix

# Pipeline (simplified):
# intent recovery → rebase → adversarial review → tests → docs → lint → PR → CI babysit
# Safe mechanical fixes: auto-applied
# Product-implication fixes: escalate to human
# Nothing hits origin until every gate is green

Case 3: Fat Tool Interfaces Eat the Quota

Setup: you wire every SaaS through a generic MCP server “because that is the standard”. Agents succeed, but each task burns a shocking amount of input tokens on schemas and verbose JSON.

# Anti-pattern: schema-heavy tools for every turn
tools = load_mcp_server("github")   # dozens of tool schemas into context
result = agent.call("list_issues")  # JSON with every field imaginable
# Repeat for 6 turns. Context is mostly glue, not work.

# AXI-style alternative: compact, agent-first CLI output
# TOON / minimal fields / next-step hints / no interactive prompts
$ gh-axi issue list --repo you/app
issues[2]{number,title,state}:
  42,Fix login bug,open
  43,Add dark mode,open
# Same semantics. Far fewer tokens.

This is not vibes. Chen’s AXI project published benchmarks comparing interface designs for the same tasks. On browser automation and GitHub operations, agent-ergonomic CLIs beat both naive MCP wrappers and human-oriented CLIs on cost and often on success rate. The lesson for your stack: protocol choice matters less than interface ergonomics. If you already teach routing by task complexity in model routing, apply the same discipline to tools.

“MCP conditions average 185K tokens per task vs. 79K for AXI” – AXI: Agent eXperience Interface

Case 4: Setup Theatre (Building Tools, Never Products)

Setup: every friction becomes a reason to build another orchestrator. A week later you have beautiful dashboards and no shipped features.

# Anti-pattern: meta-work consumes the calendar
week = [
  "improve agent router",
  "rewrite status widget",
  "benchmark 14 harnesses",
  "fix the fixer that fixes the fixer",
  # missing: ship the actual product
]

# First Mate's emergent fix (when it works):
# mundane tooling bugs get dumped to the captain as chores.
# Your scarce hours gravitate to ambiguous product decisions.
# Rule of thumb Chen implies: invent tools only from real friction,
# not from "wouldn't it be cool if 200 agents ran in parallel".

If your setup cannot point at a PR, a release, or a customer outcome this week, you are starring in setup theatre. Kill a pane. Ship something ugly.

How the Captain Should Behave

The interesting design is not “more agents”. It is escalation policy. Chen spends most of his First Mate time on ambiguous decisions, not on watching logs. That only works if the captain knows when to interrupt you.

• Delegate by default – if First Mate does the long task itself, you lose your only free channel. Crewmates exist so the captain stays interruptible.
• Route by preference files – model, harness, and reasoning effort per task class (design vs mechanical fix vs background chore). This is the same idea as complexity-based routing, encoded as durable rules instead of vibes.
• Escalate product forks – auto-fix typos; never silently change product behaviour.
• Keep deterministic steps in bash – scripts in the distro burn zero reasoning tokens for known sequences. The agent edits those scripts when they break, which is how the system becomes oddly hard to kill: a buggy script slows it down; it rarely hard-stops an intelligent loop.
• Use interactive artifacts for design – Lavish turns HTML into a whiteboard with trade-offs and open questions, so you are not debating architecture inside a wall of terminal markdown.

Brooks warned in The Mythical Man-Month that adding people late to a late project makes it later, because coordination cost grows faster than labour. Agent fleets have the same shape. A captain who absorbs coordination is the difference between a crew and a stampede.

Migration: Getting There From a Normal Setup

You do not need Chen’s full Mac Mini monastery on day one. Steal the invariants in order.

1. Pick one captain surface – one chat you refuse to abandon mid-task. Cursor Agent, Claude Code, Pi, Codex: pick one primary. Parallel sessions are workers, not equals.
2. Isolate parallel work – git worktrees or separate branches per agent. Never two agents writing the same working tree.
3. Install a merge gate – even a minimal path helps:

   # Minimal local gate before you adopt full no-mistakes
   git checkout -b review/ai-change
   # 1) Re-state the human intent in the PR body (copy from the agent prompt)
   # 2) Run tests you already trust
   npm test
   # 3) Force a second-model review prompt on the diff
   # 4) Only then open the PR to origin

4. Replace fat tools where they hurt – if GitHub MCP is chewing tokens, try gh or gh-axi. Measure turns and cost on one repeated chore before rewriting your whole toolchain.
5. Adopt First Mate when tab count hurts – clone the distro when you are already drowning in sessions, not before you have something to coordinate:

   gh auth login
   git clone https://github.com/kunchenguid/firstmate
   cd firstmate
   # then launch a verified harness inside that directory:
   claude   # or: pi / grok --trust / etc.
   # Talk to the first mate. Let it spawn crewmates.

6. Write escalation rules explicitly – when must the agent stop and ask? Put it in AGENTS.md. Unwritten preference becomes silent product drift.

When This Is Actually Fine Without the Full Stack

Credibility requires the boring truth: most people should not copy every layer tomorrow.

• One focused product, one agent – if you ship from a single Cursor session and your review load is manageable, First Mate is overhead. Stay simple.
• Weekend demos and throwaways – skip heavy no-mistakes-style pipelines. Quality cost is real; not every repo deserves it.
• GUI-native workflows – if the terminal learning curve would stall you for a month, use a GUI harness and borrow only the captain pattern plus a review gate.
• Legacy mazes – early-adopter gains are largest on greenfield or well-factored codebases. On ancient mono-repos, agents help, but they will not erase coordination debt overnight.
• Team process already works – if human code review, CI, and ownership are healthy, automate the edges; do not replace a functioning social system with a shell script cosplay.

Chen himself describes a spectrum: people who want a proven playbook out of the box, and people who want deep customisability. Both are legitimate. The mistake is pretending you are in the second group when you have not shipped in the first.

What the Software Industry Has to Rebuild

Zoom out and the stack is a preview of a larger shift. A lot of SaaS from the last twenty years is a human UI glued to a database. Agents do not want your click path; they want a headless, stable, token-cheap control surface. AXI is one attempt to write down those principles (token-efficient output, minimal default schemas, definitive empty states, structured errors, contextual next steps). The winners of the “next GitHub” race will likely be the services agents can operate without a human babysitting a browser.

That does not mean MCP disappears. It means MCP, CLI, and code-mode are transports. The scarce skill is designing observations agents can act on without drowning in glue tokens. If your product only has a pretty dashboard and a sluggish API, you are building for a shrinking primary user.

What to Check Right Now

• Count your live agent sessions – if you cannot name what each one is waiting on, you already need a captain pattern.
• Measure review latency – time from “agent says done” to “merged”. If that dominates calendar time, automate adversarial review before you buy another subscription tier.
• Audit one hot tool path – pick GitHub or browser automation, compare MCP vs CLI vs an AXI-style wrapper on the same task, and record tokens + turns.
• Write escalation rules – three bullets in AGENTS.md: auto-fix, ask me, never do. Silence here is how agents invent product requirements.
• Isolate parallel writes – worktrees or separate clones. Shared dirty trees are multi-agent foot-guns.
• Kill setup theatre – if tooling work exceeded product work this week, freeze tool-building until a user-visible change lands.
• Quota realism – subscription tiers are the binding constraint for individuals; API metering for everything can cost thousands per month. Route hard design to expensive models and background chores to cheaper / slower paths (see also task-complexity routing).

Video Attribution

This article is based on David Ondrej’s podcast interview with Kun Chen, cross-checked against the public First Mate, no-mistakes, AXI, Herdr, and treehouse repositories. Sponsor segments and community CTAs from the video are omitted on purpose.

Watch the full conversation: L8 Principal’s Agentic Engineering Setup (David Ondrej). Kun Chen’s tooling lives primarily under github.com/kunchenguid.

nJoy 😉