Building Thrawn

The Problem

Coding agents are good now. Genuinely good. But the way most of us use them hasn’t caught up: one agent, one terminal, and you sit there watching it work like it’s 2024. The bottleneck has stopped being the typing and become the orchestration. Deciding what to build, keeping more than one agent busy at once, reviewing what comes back and stopping any of it shipping before a human has looked at it.

There’s also a cost and fit problem nobody talks about enough. Running your biggest, most expensive model on every task is lazy. Renaming a function does not need the same brain as designing a schema. What I wanted was a workflow that plans with a model strong enough to be trusted, then farms the actual work out to whatever model each task deserves. These days that means planning on Opus with the top-tier model one config line away for the rare ticket that earns it, and a proper ladder underneath: Sonnet for ordinary work, Haiku for the mechanical stuff, Codex and Pi when the task belongs on the other subscription’s quota.

So I built Thrawn. Named for the Grand Admiral, because the whole point is that it wins by planning and delegation rather than brute force.

How It Works

You give Thrawn a ticket number, several at once (thrawn 42 43 45 becomes one run planned together) or a markdown brief. From there:

1. A strong model deep-thinks a plan, exploring the repo read-only. No writes at this stage, just understanding.
2. The plan gets split into parallel tasks, each routed to the right model for its complexity. Design work goes to a heavyweight, mechanical work goes to something cheap and fast.
3. One agent spawns per task, each in its own isolated git worktree. They can’t stand on each other’s toes because they’re not in the same working copy.
4. The task branches get merged back together. An integrator agent resolves conflicts and runs the project’s checks.
5. Shipping is gated behind a one-time code. Nothing gets pushed until I’ve seen the green board and typed the code in myself.
6. Only then does it push the branch and open the PR.

That last gate matters more than any of the clever bits. Agents doing work in parallel is a productivity story. Agents pushing to a remote without a human in the loop is a horror story.

There’s also a lightweight swarm mode: no planner, no integrator, just a worktree and an agent per issue with me as the orchestrator. It has quietly become the workhorse.

Herdr Underneath

The agents run inside Herdr, a terminal multiplexer built for exactly this. Each Thrawn task shows up as a pane, and Herdr’s state awareness means I can see at a glance who’s running, who’s waiting on input and who’s finished. My full Herdr setup lives in the same repo, keybindings, workspace definitions and the agent state hooks included.

After years of cobbling together tmux sessions and shell scripts, this is where I’ve wanted my terminal workflow to be. Herdr handles the runtime, Thrawn handles the orchestration, and the two of them together are the closest I’ve got to a proper answer.

The Honest Bit

I’m dogfooding this properly, with a ledger that records every run, and the early data is humbling. Roughly half of my personal tickets don’t actually decompose into parallel work. When a task is inherently serial, the orchestration is pure overhead. And semantic merge conflicts, where two agents both did the right thing but their right things disagree, remain the hardest problem in the whole system.

My suspicion is that my personal projects are the wrong testing ground. They’re small monoliths, and the tasks are chatty with each other. Where Thrawn should earn its keep is distributed work, where service boundaries give you natural task boundaries. I’ll find out when I’ve used it in anger at work.

Then in September the platform made the ledger’s job easier by eating half the roadmap. An audit of my own issue tracker found that event-driven dispatch, intake grooming and the pre-ship review stage had all shipped as native Claude Code features while I wasn’t looking. Twelve open issues became two in a day, and the write-up of that reckoning is The Platform Ate My Roadmap. What survived is the moat: cross-subscription routing, the ship gate and the panes.

The findings have started turning into essays. The decomposition problem became Your Architecture Is the Bottleneck, Not the Model, and a trial of two agent harnesses on the same five tickets became Execution Stopped Being the Bottleneck. I’ve written the design and the findings up properly on my experiments site, including the failure cases. The 30-day trial is running now and the ledger, not my enthusiasm, gets the final say on whether it survives.

Status

Using it daily, and deliberately smaller than it was in August. Two questions stay open: whether the cross-pool routing actually pays (the ledger delivers its verdict in October) and an interactive swarm mode that leans into the panes. Everything else on the old roadmap belongs to the platform now, and it’s welcome to it.

Source

Thrawn lives in my agentic-development repo on GitHub, alongside the Herdr configuration it pairs with.