Why I'm Building an Agent Orchestrator
Or: How I Learned to Stop Tab-Switching and Let the Robots Work
I have a confession.
I’ve been running multiple Claude Code sessions manually. Like some kind of air traffic controller using Post-it notes.
Terminal 1: auth refactor.
Terminal 2: API pagination.
Terminal 3: that bug I said I’d fix last week.
Tab. Check. Tab. Check. Tab. “Wait, which one was working on the tests?”
Nobody should have to live like that.
Hey, I’m Lakshmi — I help developers build, deploy, and distribute their SaaS without hiring a team. I also run Stacksweller and Supabyoi.
New here? Start with Why Your AI Wakes Up Every Morning With No Memory or Clean Code Is Dead.
The One-Session Bottleneck
Here’s the thing about Claude Code: it’s incredible at focused work. Give it a well-defined task, point it at the right files, and it’ll churn through code faster than you can review it.
But “focused” is doing a lot of heavy lifting there.
One session means one task. One context. One thread of execution. While Claude is refactoring your auth system, it’s not touching your API. While it’s writing tests, it’s not fixing that bug.
You, meanwhile, are the bottleneck. The dispatcher. The human scheduler running tmux attach -t session-3 forty times a day.
I tried to solve this the obvious way: more sessions. Three terminals. Four. At one point, six.
My M2 Mac doesn’t have fans. It just gets warm and sad. The UI started lagging. Keystrokes took a second to register. Activity Monitor looked like a stock chart during a crash.
I Tried Gastown
Steve Yegge built Gastown - a full agent orchestration system. Polecats, refineries, convoys, molecules, mayors, witnesses, deacons. It’s ambitious. It’s thorough.
I wanted to love it.
I really did.
I spent a week trying to wrap my head around the abstraction layers. Rigs containing polecats containing worktrees. Routes pointing to mayors pointing to beads. Molecules with formulas that become protomolecules that become digests.
Then I spawned 6 polecats for 6 well-groomed tasks.
My system hung. Not “slow” hung. “Is this thing even on?” hung.
Turns out each polecat is a full Claude session. Six sessions competing for API calls, memory, and CPU cycles. The parallelism I wanted was theoretical. The system thrashing was very, very real.
The core issue? Gastown is a coordination layer, not an executor. You still manually gt sling each task. There’s no “run these 6 serially while I do other things.” The dispatcher is still you.
I’m not knocking it. The persistence model is solid - sessions can crash and recover context. The beads integration works. The architecture is thoughtful.
But for my brain, the complexity-to-benefit ratio didn’t compute. I needed something simpler.
What’s Actually Non-Negotiable
After a month of manual orchestration and a week of Gastown experimentation, I’ve landed on what actually matters:
1. Beads Integration
This isn’t optional. Beads is how I track work - git-backed issues with dependencies, labels, and full history. Every task is a bead. Every worker needs to know which bead it’s working on.
No beads, no deal.
2. Worktree Isolation
Each worker gets its own git worktree. Not a branch. A worktree.
Why? Because when Worker A is refactoring auth and Worker B is adding pagination, they cannot be stepping on each other’s files. Worktrees give you physical isolation - separate directories, separate working states, zero merge conflicts during work.
When they’re done, you merge. Not before.
3. Reliable Prompt Delivery
This one took me a while to figure out.
You spawn a session. You send it a prompt. Simple, right?
Except tmux send-keys doesn’t care if Claude is ready. It just blasts text into the pane. If Claude hasn’t fully initialized, your prompt arrives before there’s anything to receive it.
The fix: detect when Claude is actually running (not just a shell), wait for UI initialization, then send with proper debouncing and retry logic.
Sounds obvious in retrospect. Cost me hours of “why isn’t this working?”
4. Visual Monitoring Without Babysitting
I need to see what’s happening across all workers. But I don’t want to tab through terminals.
A dashboard. Live status. Which worker is active, which is idle, which is stuck. One glance, full picture.
And critically: switching to a worker shouldn’t kill the dashboard. The monitoring should keep running while I’m working.
Early wt screenshot with wt watch on the side.
wt watch - All workers, one glance. No tab-switching required.
5. Simplicity
One binary. Tmux (which I already use). Beads (which I already use). Git worktrees (which are just git).
No mayors. No deacons. No protomolecules. No routing tables pointing to other routing tables.
If I can’t explain the mental model in 30 seconds, it’s too complex.
So I’m Building It
It’s called wt (worktree). The core workflow:
Grooming is sacred. I run dedicated Claude Code sessions where I don’t write code - I think out loud. “We need pagination on this API. The auth middleware is getting messy, let’s refactor it. Oh, and that bug from last week.”
Claude helps me turn those thoughts into beads. Sets priorities. Adds dependencies. The interaction is conversational, not CLI gymnastics.
me: "let's break down the user dashboard feature"
claude: [creates 4 beads with dependencies, P1 for the data layer, P2 for the rest]
me: "the caching one blocks the others"
claude: [adds dependency links]The better the grooming, the more autonomous the workers can be. Then execution is just:
wt ready # What's unblocked?
wt new proj-123 # Spawn a worker
wt hub # Watch them workBut it grew legs. Session lifecycle (wt done, wt abandon, wt signal). History and resumption (wt seance - yes, you can talk to dead sessions). Autonomous batch mode (wt auto). Context handoff (wt handoff, wt prime).
wt project list showing registered projects with their paths and bead counts. wt itself is built using wt, I know, so meta.
Multiple projects, one tool. Each with its own beads, worktrees, and workers.
The commands multiplied, but the mental model stayed simple: projects contain beads, beads spawn workers, workers live in worktrees, hub watches everything.
Next post: I’ll walk through the architecture - why tmux, why worktrees, and the surprisingly tricky problem of “how do you know when Claude is ready to receive input?”