True Agent Swarming in Claude Code
Steve Yegge is building something called "Gas Town" for multi-agent orchestration. It's impressive work, and it got me thinking. But here's the thing: my workflow doesn't look like Steve's. I'm juggling multiple coding projects at once. Burning my entire Anthropic token allocation on a single project? Not an option.
The Sub-Agent Problem (And Why Native Doesn't Cut It)
Yes, Claude can run sub-agents natively. But the tasks have to be small enough that the sub-agent won't blow through its context window. That doesn't work with how I break out sprint tasks.
I tried this. Instructed Claude to create sub-agents for tasks defined in Beads (where I document my sprint tasks). About 50% of the time, I'd get these "Context low, run /compact" messages. The problem? I couldn't run /compact within the agent context.
Oh, and it turns out, sub-agents can't compact their own context.
Think about what that means. You want to delegate meaningful work to sub-agents, but they're constrained to tasks small enough to fit in a single context window without compaction. That's not swarming. That's micromanagement in a robot costume.
I needed workers that could handle real complexity. Tasks that might take 30 minutes of autonomous work, not 30 seconds of simple execution.
Headless Claude Instances
After a lot of arm wrestling with my /session:parallel skill, I got Claude to launch headless Claude instances via Bash. Everything clicked.
From the command line, Claude can:
- Specify the model each instance uses
- Assign the Sprint Worker agent persona
- Pass a prompt that includes the specific Beads issue to work on and how to report back
Each headless instance is a fully autonomous Claude session. Its own context window. Its own ability to compact. Its own capacity to handle complex, long-running tasks.
The Orchestrator Pattern
My main Claude thread becomes the orchestrator. It can:
- Launch its own swarm of worker agents
- Monitor their progress through the reporting mechanism
- Fix things when swarm workers fail (and they do fail sometimes)
- Keep the main thread running throughout implementation
Bonus: my main thread context window doesn't compact as often. The orchestrator stays lean because it's delegating the heavy lifting to workers with their own context space.
But here's where it gets interesting. This only works if you're smart about which tasks you parallelize.
Why Dependency Awareness Prevents Agent Chaos
I updated my /session:plan command to track dependencies between features in each sprint. The plan explicitly states: here's where we can parallelize, here's where we single-thread.
This isn't about throwing more agents at a problem. It's about intelligent orchestration: understanding which tasks can truly run concurrently and which ones need to wait for upstream work to complete.
Without dependency awareness, your agents become a circular firing squad.
What This Means for Your Workflow
Let me be direct: this approach isn't for everyone.
Working on a single focused project? Steve Yegge's Gas Town approach might serve you better. But if you're juggling complex projects with multiple independent workstreams, this is how you actually leverage parallelism.
Instead of babysitting a single Claude session through a long implementation (and losing valuable information to context compaction), you have an orchestrator managing multiple workers. You can context-switch to other priorities.
Swarm workers handle their own context management. They report back when they're done or when they hit blockers. The orchestrator synthesizes their work. The sprint keeps moving.
Get the Slash Commands Now
I've open-sourced my slash commands workflow, including the swarming capabilities.
→ Get the Claude Code slash commands collection
The key insight isn't technical. It's a mindset shift. Claude isn't your assistant. It's your orchestra waiting for a conductor. The tooling finally makes that practical.
Remember dependency awareness? That's your sheet music. Without it, you're just making noise.