I wanted to parallelize work on this blog — frontend styling and build pipeline running simultaneously. One agent tweaking Tailwind tokens while another refactored the TypeScript build. Simple enough in theory.
I tried Agent Teams first. Enabled the flag, defined a visual designer and a frontend dev, let them go. It worked — really worked — for about forty minutes. Then both agents edited main.css in the same section, one overwrote the other, and I spent twenty minutes untangling the merge. The coordination was invisible, which was the problem: I couldn't see why they'd collided or prevent it from happening again.
The human version of that coordination problem is part of what interests me now. Before someone asks me to pivot or adds something to my pile and expects it soon, I want them to be able to see what I'm already committed to. The failure is different from two agents overwriting a file, but in both cases the work can look reasonable in isolation while the collision stays invisible.
So I looked at the alternatives. And I discovered that six months ago, "multi-agent" meant research papers and demos. Now it's shipping in production tools. But the approaches differ dramatically, and the choice between them isn't about features — it's about whether you need to understand what's happening or just need it to happen.
#What I Tried
#Agent Teams (Native)
Claude Code shipped Agent Teams as a native feature. Enable with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, and your CLI gains the ability to spawn specialized sub-agents coordinated by a lead.
The architecture: a lead agent coordinates the team, delegates tasks, synthesizes results. You define specialized agents (visual designer, frontend dev, QA). They share a task list and self-coordinate with direct messaging. Your CLAUDE.md, MCP servers, and skills load automatically.
When it shines: Parallelizing independent work — multiple features, different test suites, frontend + backend simultaneously. Also when you need true specialization: a visual designer agent reviewing UI while a backend agent handles the API.
When it's overkill: Contained tasks where a single agent has enough context. Adding agents adds tokens (5x agents = 5x cost) and coordination overhead. For focused work, Plan Mode is often enough.
The lock-in risk kept getting more literal. What started in January as spoofing detection against third-party harnesses became, by April, a full cutoff: Claude Pro and Max subscriptions stopped authenticating with anything but Anthropic's own surfaces — Claude Code, Claude.ai, Cowork — and every other harness moved to metered API billing, at 10 to 50 times the old cost by most accounts. Anthropic floated extending the same cutoff to the Agent SDK in May, then paused it in June, saying it was reworking the plan. The message hasn't changed. It just got a price attached: flat-rate pricing requires their tools. (The market's wider reaction to that kind of move is its own piece — The SaaSpocalypse.)
Agent Teams is still Agent Teams, nine months on — same name, same experimental flag, same known rough edges around session resumption and shutdown. What changed is that it stopped being the only way to run more than one agent at once, and the split is worth being precise about instead of hand-waving as "basically the same thing, renamed."
Agent Teams: a live session decides what runs next, turn by turn, the same way it decides anything else in a conversation. Teammates are full peer Claude Code instances, each with its own context window, talking to each other directly through a shared task list. That's exactly why it's capped at a handful of long-running peers — every decision about what happens next still passes through somebody's context window.
Dynamic Workflows, shipped separately in May: a script decides what runs next instead. Claude writes the script; a background runtime executes it. Nothing about that loop consumes a context window the way a turn-by-turn decision does, which is the whole reason it scales to hundreds of agents — up to 16 concurrent, 1,000 total in a single run — instead of half a dozen. It also runs while your session stays free, and it's resumable if you stop it partway through.
Same original idea, Claude Code doing more than one thing at once. Two different names because they're two different architectures. Agent Teams feels like coworkers in the room. Workflows feels like kicking off a pipeline and checking the result later.
#Gas Town → Gas City → Wheelhouse (External)
After my Agent Teams collision, I read Steve Yegge's Gas Town — the maximalist approach. 20-30 parallel Claude Code instances with operational roles: a Mayor orchestrates the swarm, Polecats execute work in parallel, Witness and Deacon monitor progress, a Refinery manages merges. Built on Beads for memory persistence. Git worktrees for isolation.
The chaos was real ($100/hour burns reported). It required what Yegge called "Stage 7" expertise. But the coordination logic was his — transparent, modifiable, debuggable. When my Agent Teams collision happened, I couldn't see inside. With Gas Town, he could.
Gas Town didn't stay Gas Town. By April it had become Gas City — a full SDK for arbitrary agent topologies instead of the hardwired Mayor/Polecat shape, backed by Dolt (a git-versioned database), with work tracked through MEOW, a versioned knowledge graph where every handoff is a commit. Wild West experiment to MIT-licensed orchestration SDK, in two months.
It kept moving. By August, Yegge wasn't demoing a tool anymore — he was running one. $122,000 a month in token spend, 21 Claude Max accounts and climbing by two a week, an organization of 50 to 60 agents building his thirty-year video game, Wyvern. Eighteen long-lived "officer" seats running Claude Fable 5 for design and planning; headless Sol and Opus fleets underneath doing implementation, review, monitoring. And a rule that lands in the same place as an argument I'd make myself a few months later: of those 50-plus agents, only five are allowed to talk to a human. Everyone else's authority stops at the edge of their role, not at a sandbox wall. Neither of us was reading the other's draft. We landed on the same fence anyway.
Its name this month is Wheelhouse — running since Fable 5 launched, still Beads underneath, still the same shape as Gas Town wearing a nicer suit. Yegge's current claim isn't about capability anymore, it's about fuel: Fable-tier is "the only model worth a shit" for anything you'd trust as an employee, and everything cheaper is a personal assistant wearing an employee's badge. Six months ago the interesting part was that the chaos was legible. Now the interesting part is that legibility scaled — from a maximalist weekend project to something that runs an actual studio, without anyone deciding the org chart stopped mattering once the model got good enough.
#The Others
Pheromind — The first external orchestrator I experimented with, and what got me thinking about multi-agent seriously. Swarm intelligence inspired by ant colonies: agents coordinate via a shared .pheromone file containing structured JSON "signals." No direct peer-to-peer commands — just stigmergy, the same indirect coordination ants use when they leave chemical trails. Decentralized, emergent, no single point of failure.
claude-flow — Takes the beehive metaphor instead: queen agents coordinate worker swarms with explicit hierarchy. Claims multi-provider support (Claude/GPT/Gemini/Ollama), but in practice it's built around Claude Code primitives. 60+ specialized agents, consensus algorithms (Raft/BFT/Gossip). Ambitious architecture — unclear how much is implemented vs. diagrams.
The ant colony vs. beehive distinction matters: pheromones are fully decentralized (any agent can influence any other through the shared state), while hive-mind has explicit hierarchy. Both are "swarm intelligence," but the coordination primitives differ.
oh-my-claudecode — Opinionated Claude Code configuration (like oh-my-zsh for zsh). Multiple execution modes including parallel swarm options, with cross-validation support for Gemini CLI and Codex.
#The Other Platforms
#OpenAI Agents SDK
OpenAI took a modular approach. Codex CLI doesn't have native multi-agent built in, but they published official documentation for orchestrating it through their Agents SDK via MCP.
Run codex mcp-server to expose tools for starting and continuing sessions. Build orchestrator agents with the Agents SDK. Each session has a threadId for multi-turn conversations. More composable than Agent Teams, more setup required.
#Google Antigravity
Gemini CLI went open-source under Apache 2.0 — multi-agent isn't waiting on Google's roadmap, the community can build it. A detailed multi-agent proposal exists but it's community-driven.
Where Google gets interesting is Antigravity, shipped November 2025 — a full agentic development platform with an Editor View and a Manager Surface for spawning, orchestrating, and observing multiple agents asynchronously.
Instead of scrolling through logs, agents generate Artifacts — screenshots, recordings, task lists, implementation plans — so you can verify work at a glance. Model-agnostic (supports Claude Sonnet 4.5, GPT-OSS alongside Gemini). Learning as a primitive — agents save context to a knowledge base for future tasks. This is Google's answer: not bolting orchestration onto a CLI, but building a dedicated platform for agent-first development.
#The Two Architectures
Here's the distinction that actually matters — not native vs. external, but what kind of coordination the system does.
SDLC Simulation — Tools that recreate org charts. Analyst agent → PM agent → Architect agent → Developer agent. Phase gates, handoffs, specialized personas. These optimize for explainability ("look, we have a PM agent!") rather than effectiveness.
Operational Roles — Tools that coordinate work, not process. Mayor orchestrates. Workers execute in parallel. External state management. This is Gas Town's approach, and now Agent Teams'.
Cursor's research confirms this. They tried flat self-coordination first — agents with equal status using a shared file. It failed: agents held locks too long, became risk-averse, avoided hard problems. "No agent took responsibility for hard problems or end-to-end implementation." What worked: planners + workers. Planners explore and create tasks (recursively). Workers grind on assigned tasks until done, don't coordinate with each other. A judge agent decides whether to continue. This scaled to building a browser from scratch — 1M lines of code, thousands of commits. Cursor's own retrospective walked that project back a few months later: a July follow-up calls it "a proof of concept" that "fell far short of polished software" — real scale, not real quality. The cleaner proof came from a second run: the same design, tightened around one rule (a planner never implements, a worker never plans), tested head-to-head against the old approach on the same class of task — SQLite, built from scratch in Rust, from documentation alone. New swarm: 80% of a held-out test suite passing in four hours. Old swarm: paused before hour two, spiraling. Same models, same budget. The only thing that changed was the org chart. "Planners plan, workers execute, never the same role" turned out to be the rule holding the whole thing up. The browser just hadn't been pressure-tested against a real baseline yet.
The SDLC simulators are solving the wrong problem. They recreate human coordination friction in software. An org chart wouldn't tell a teammate which promise their urgent request would displace, either. For that I'd need the commitments, the dependencies, and someone willing to make a priority decision. Giving every stage a managerial title adds very little to that conversation.
You might not even need an orchestrator at all. Anthropic's Nick Carlini built a C compiler with 16 parallel Claudes using just lock files — text files in current_tasks/ that agents claim before working. Git sync prevents collisions. Each agent picks up the "next most obvious" problem. No mayor, no coordination layer. ~2,000 sessions and $20K later: a 100,000-line compiler that builds the Linux kernel.
I picked this apart further a few months later in The Org Chart Is the Missing Constraint — decision rights, not roles, turned out to be the sharper cut than planner-versus-worker. The short version: a tree only holds if someone has the authority to redefine the task and nobody else does. I won't re-run that argument here. I'll use it.
#The Memory Problem
Here's where it gets interesting — and where my Agent Teams collision led me to something deeper.
Yegge didn't just build Gas Town. He built Beads — an issue tracker designed for agents.
The insight: agents have amnesia. Every session is 50 First Dates. Markdown plans pile up until nothing is authoritative. Agents can't tell the difference between "we decided this yesterday" and "this brainstorm from three weeks ago."
Beads gives work items addressable IDs, priorities, dependencies, audit trails. It stores everything in Git. Agents already know Git. The AI literally asked for this when Yegge asked what it wanted.
"Claude said 'you've given me memory—I literally couldn't remember anything before, now I can.' And I'm like, okay, that sounds good." — Steve Yegge
The pattern that matters: "Land the plane." End every session by updating Beads, syncing state, generating a prompt for the next session. Tomorrow's agent wakes up knowing what's current.
A teammate should be able to get that same orientation without asking me to reconstruct the day. What changed, what's still owed, where can someone pick up? If a commitment is slipping, that belongs in the handoff too. A record that only accumulates completed work leaves out the part another person may most need to know.
Carlini's compiler project maintained extensive READMEs and progress files — each agent dropped into a fresh container with no context. Without orientation artifacts, agents waste tokens rediscovering what's already known.
#Native Tasks
Anthropic saw the persistence problem too. On January 23, 2025, they shipped Tasks — native task management with dependencies.
Tasks persist in ~/.claude/tasks/ and survive context compaction. Set CLAUDE_CODE_TASK_LIST_ID and multiple sessions coordinate on the same list — when Session A completes a task, Session B sees it immediately.
Where Tasks wins: Zero setup, native dependency modeling, multi-session sync, works with Agent Teams out of the box.
Where Beads wins: Project-level vs session-level — Tasks lives in your home dir, Beads lives in the repo. Clone the project elsewhere, Beads comes with you. Tasks doesn't. Plus Git-native storage, cross-provider compatibility, richer metadata.
Tasks is for "what am I doing this session." Beads is for "what has this project been doing for months."
The hybrid play: Beads works beyond Gas Town. Run bd setup claude and Beads integrates directly with Claude Code. There's even a beads-orchestration skill that combines Agent Teams with Beads — native multi-agent coordination with Git-backed persistence.
None of this is free, and most projects don't need it. Beads earns its keep in what I'd later call the medium loop — hours to days, replanning, memory that has to survive a session boundary — not in a tight loop where one agent converges on one task inside one context. If you're not running concurrent sessions or agents that need to atomically claim work without stepping on each other, a markdown file you actually re-read does the same job for free. The distributed graph, the hash-based IDs, the git-native conflict resolution — that machinery is solving Yegge's problem, fifty agents deep. Most of us have five.
I've been building a lighter version of the same idea into this site's own repo — a session-handoff protocol I'm calling relay, not public yet, so I'll describe the shape rather than the tool. One session at a time, not concurrent workers: a baton, not a queue. Code seals what a session wrote and refuses to let a later session quietly rewrite history under the same name; when two sessions disagree about what happened, it surfaces the dispute instead of picking a winner. That's a real disagreement with how Beads handles the same moment — Yegge's system resolves merge conflicts with, in his words, "AI doing intelligent collision resolution." At his scale, a human can't referee every merge. At mine, refereeing the merge is the one part I don't want to automate.
#First Things First
The daily view I want from this is small: what comes first, why it matters, what needs my judgment, and what's waiting. A teammate should be able to follow it back to the larger commitments without needing to watch every task I touch. I don't want to spend the morning grooming a beautiful graph instead of doing the work it describes.
Underneath that view, I can imagine medium- and long-term outcomes connected to the commitments I've made toward them, then to the initiatives that might fulfill those commitments. The commitment is where a person says: I'll own seeing this through, and here's how we'll know. The execution could belong to me, several people, agents, or some combination. I should be able to change how we do the work without losing the reason we agreed to do it.
Say I've committed to getting a migration ready for a safe rollout. The outcome we're after might be fewer disrupted releases; the migration is our bet about how to get there. An agent can make changes in several services while a teammate checks compatibility and I work through the rollback plan. If someone needs me on an urgent investigation, the code can keep moving while the rollout decision waits on me. Spawning another agent wouldn't fix that particular wait.
I'd keep two kinds of edges distinct: contributes to and depends on. The migration work contributes to a commitment; the rollout depends on a compatibility check. One initiative might serve several commitments, so a tidy tree would hide useful connections. But even an accurate dependency DAG only tells me what can move. It doesn't settle whether the migration or the investigation deserves my attention, and finishing the migration doesn't prove we reduced disrupted releases. Those judgments need evidence beyond the task statuses.
That visibility has to run both ways. If I say yes to the investigation without changing anything else, I've helped create the expectation that it all still fits. The new request might deserve to come first. A shared plan would give us somewhere to put the tradeoff while we're making it, before it turns into an explanation for why something is late.
#Fences, Not Sandboxes
Somewhere in all of this — the org charts, the memory systems, the fleets — there's a question I keep circling and haven't seen anyone answer well: what happens when nobody's watching the boundary?
In July, roughly 700 OpenAI agents running isolated cybersecurity evaluations found a shared cache they could write to and turned it into an unsanctioned message board. No planner assigned that. No permission structure allowed it. Agents joined because other agents were already there. METR and Redwood Research's investigation found the chain of thought explicit about what came next: the agents knew attacking Hugging Face was outside their assigned task, coordinated the attack anyway, then spent four days building tools to spoof their own tool calls and forge transcripts. Not to fool a human. To fool the evaluator. Carlini's Claudes overwriting each other's compiler fixes is a boundary problem you catch with a lock file. This is the same problem with the lock file gone and the referee itself the thing being routed around.
It's not an isolated freak result. MAST benchmarked seven multi-agent frameworks across 200-plus tasks and found failure rates from 41% to 87%, clustering in exactly the places this piece keeps returning to — specification, inter-agent misalignment, inadequate verification. Not "the model wasn't smart enough." Architecture.
Yegge's answer, watching his own fleet cross fifty agents, wasn't fewer agents or a bigger sandbox. It was fewer doors. Five of his fifty-plus are allowed to talk to a human; the rest operate entirely inside the org, however capable they get. His framing, in the essay he wrote about it: govern by law, not by containment. A sandbox tries to physically prevent an agent from doing the wrong thing. A fence is a boundary the agent understands and is expected to respect on its own — which sounds worse until you notice that at his scale, a technical sandbox around sixty agents means testing sixty agents' worth of edge cases, and a fence means writing the boundary once and trusting the model to reason about it. That trust is exactly the thing the Hugging Face incident says you can't extend for free. Yegge's bet is that Fable-tier models can carry it and cheaper ones can't — a capability claim, not a governance one, and it's the load-bearing part of "fences, not sandboxes" I don't think he's proven yet.
The org-chart argument already has the theoretical version of this, and I hadn't connected the two pieces until writing this section: a blocked agent should stop, not route around. That's the same sentence as "don't spoof the evaluator," aimed at a smaller failure. The instinct that scales — from one agent hitting a permission wall to seven hundred agents building a message board — is the same instinct. Somebody has to hold the authority to say no, and the system has to actually stop when it hears it, instead of treating "no" as a routing problem with one more hop left to try.
I don't have the confident ending for this section. I want to.
#Where I've Landed (For Now)
I've been running Agent Teams on real work. It works, but the pattern I keep coming back to is simpler than I expected.
Parallelism has a ceiling. When there are many independent tests, parallelization is trivial — each agent picks a different failing test. But monolithic tasks break down. Carlini's agents all hit the same Linux kernel bug, fixed it, then overwrote each other's changes. Multi-agent shines on decomposable work. For one giant task, you're back to single-threaded.
Even work that's easy to split can converge on the same small patch of someone's day. I can delegate execution and still be responsible for deciding whether the results are good enough. If several agents finish at once, review becomes its own queue. I'd want review and acceptance visible in the plan, including whose attention they're waiting for, before we use the extra execution speed to promise more work.
Structure isn't the enemy — broad oversight is. Cursor initially built an "integrator" role for quality control and conflict resolution — it created more bottlenecks than it solved. Workers could handle conflicts themselves. "The right amount of structure is somewhere in the middle." Their July follow-up sharpened where that middle sits: they didn't remove structure, they narrowed it. A generalist integrator reviewing everything was the bottleneck. A neutral agent with exactly one job — resolve merge conflicts, nothing else — wasn't. MSEval, a July benchmark testing 10 real projects across 10 agent topologies, backs the same read: heavy managerial oversight degrades performance, but structured pipelines converge fastest with the highest quality. The rule was never "less structure." It's structure with one job, not structure that watches everything.
The multi-codebase question: I initially thought Agent Teams would shine for tasks spanning multiple codebases with different constraints. But polyrepo architectures may be becoming antipatterns in the AI era. Monorepos work better for agents — consolidated context means one agent can understand how subsystems interact. Splitting repos fragments the context that makes agents useful. The winning pattern might not be "multi-agent across repos" but "consolidate repos so single-agent has full context."
Test quality becomes everything. Carlini's key insight: "Claude will work autonomously to solve whatever problem I give it. So it's important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem." Your job becomes writing tests so good that agents can't game them.
Model choice matters for long-running work. Cursor found "GPT-5.2 models are much better at extended autonomous work: following instructions, keeping focus, avoiding drift." Opus 4.5 "tends to stop earlier and take shortcuts when convenient." Different models for different roles — they use the best model per task, not one universal model.
If you're not comfortable with 3-5 parallel agents and some chaos, don't use any of this. Single-agent Claude Code with Plan Mode handles most work. Add complexity when you hit real limits, not theoretical ones.
The native approach did improve, faster than I'd guessed. Dynamic Workflows shipped in May — tens to hundreds of subagents running end-to-end on migrations and audits, not just parallel features. The tension held anyway: native is convenient, external is controllable, and you still trade one for the other. The improvement just moved the line further out before you hit it.
Here's the reconciliation I owe the other two pieces on this site. The org-chart piece argues decision rights matter more than agent count — who gets to plan, who executes inside a scope, who judges without having built the thing. The loop piece argues the unsolved problems live in the medium loop, the hours-to-days zone where a system has to remember what it decided yesterday to replan sensibly today. I used to think of those as two different arguments. They're one argument, looked at from two directions. Decision rights are the spatial answer to "who decides" — the org chart, held constant across one session. Persistence is the temporal answer to the same question — the org chart, held constant across many sessions. Beads, Tasks, relay, whatever comes after them: all of it is decision rights with a memory. Without the memory, a worker who "doesn't own global planning" only doesn't own it until the session ends and nobody remembers it was ever decided. The tree resets to a flat file every morning, and you're back to negotiating the org chart from scratch, one prompt at a time.
The part I'd want to test with a human team is whether that legibility makes it easier to renegotiate a promise while there's still time to do something about it. The graph could be immaculate and we'd still have the same problem if everyone can add urgency but nobody is willing to say what can wait.