Most multi-agent advice gets the hard part wrong. The hard part is not making agents talk to each other. It is deciding what they are allowed to touch, and making sure the orchestrator — not the workers — owns every irreversible action.
I say that as someone who runs agent teams in production, not as a demo. The SEO remediation pipeline on this blog is a literal multi-agent system: an orchestrator session holding a dependency graph, ten research agents triaging 581 posts, and ten rewrite workers running as spawned subagents. This article is my working playbook — when teams beat a single agent, how I structure them, and the coordination pattern that matters more than agent-to-agent chat.
What agent teams actually are (and are not)
A quick vocabulary check, because three different things get called "agent teams":
- A single agent is one Claude Code session with one context window. One brain holds the whole picture.
- Subagents are workers a session spawns for a scoped task. Each gets its own context, does its job, and returns a result. They are parallel but isolated — they do not see each other.
- Agent teams add coordination: named agents that can list each other and pass messages, so the frontend worker can ask the backend worker what the API contract is instead of guessing.
The pitch for teams is obvious. The failure mode is just as obvious once you have lived it: three agents building the same app with no shared contract produce three incompatible pieces of software. A React UI wired to mock data, an API whose endpoints match nothing, tests written against an interface that exists in neither. Technically impressive, practically useless — the classic "three freelancers in separate rooms" outcome.
Coordination fixes that, but coordination is a tax. Every message between agents costs tokens and time. A team should only exist where the integration risk is more expensive than the tax.
The team I actually run: an orchestrator and disposable workers
Here is a real structure, not a hypothetical. In August 2026 I rebuilt this blog's indexation strategy after Google refused to index most of the corpus. The pipeline that did the work:
- One orchestrator holds a
graph.json— twelve named nodes (corpus inventory, URL audit, triage, rewrite, critic, publish) with explicit states and two human approval gates between phases. - Ten research agents each triaged a slice of 581 posts and returned structured JSON: keep, rewrite, or merge, with an evidence angle per post.
- Ten rewrite workers each took ten assignments, backed up the original database row to disk before touching anything, wrote rewrites as local files, and self-scored against a seven-criterion rubric.
- A verifier script — not an agent — ran hard checks on every output: heading structure, link validity, banned phrases, rubric thresholds.
Notice what is missing: the workers never talk to each other. Not once. And the pipeline still behaves like a team, because of three design decisions that do the coordination work conversation would otherwise do.
Asymmetric permissions. Workers can read the production database but are structurally barred from writing to it. They emit files; only the orchestrator, after the verify gate, applies changes. When an agent cannot perform an irreversible action, its mistakes are always recoverable. This is the single highest-leverage decision in any multi-agent setup I have built.
Artifacts over messages. The agents coordinate through the filesystem: a shared posts index every worker links against, per-post backup files, a status manifest that records what is done. When I ran an earlier wave of this — 84 posts rewritten across seven batches — the resume manifest meant any worker could die mid-batch and a fresh one could pick up exactly where it left off. A Slack-style message thread between agents gives you none of that durability. A file on disk survives every crash.
Structured returns. Every worker ends by emitting typed output — IDs, statuses, scores — that the orchestrator merges mechanically. Prose summaries between agents are where detail goes to die; schemas are where it survives. I learned this the expensive way, and I wrote up the lossy-summary failure in detail in my post on forked subagents and the compression tax.
When direct agent-to-agent communication earns its cost
There are cases where workers genuinely need to talk. Claude Code exposes this: spawned agents can be listed and messaged by name, which turns isolated subagents into something closer to a real team. I reach for it in exactly two situations:
Contract negotiation before parallel building. If two agents will build interlocking halves of a system — an API and its consumer — one round of messages to agree the contract beats any amount of after-the-fact reconciliation. But note the shape: it is one negotiation round producing an artifact (the contract), then silence. Not an open channel.
Long-running work with a supervisor. When a background agent runs for an hour, I want it to be able to report a blocking problem to the session that spawned it rather than guessing. Message-on-exception, not message-as-workflow.
What I no longer do is let agents free-form chat. Early on I ran a six-agent team where the DevOps agent sat idle for most of the session, consuming tokens just to stay in the loop, while every decision waited on consensus from agents that had no stake in it. Teams of three or four, with an explicit protocol for who messages whom and when, outperform larger free-form teams every time I have measured it.
When a single agent beats any team
Honest answer: most of the time. If the whole project fits in one context window and one senior developer could hold the architecture in their head, a single agent is faster, cheaper, and — this is the part people miss — more coherent, because one brain holds every decision it has made. The moment you split that brain, you pay to reconstruct shared understanding.
My decision test has one question: would I brief this work to one contractor or three? If the honest answer is one, use one agent. If it is three because the work has genuinely separable domains — and you can write down where the seams are — subagents with explicit briefs. If the seams themselves need negotiating, that is the narrow case for a communicating team.
The corpus triage that produced this very article is the "three contractors" case: 581 posts is far too much for one context window, but each slice is independent, so isolated workers with a shared index were the right tool. No team chat required.
Practical rules from running this in production
- The orchestrator owns state; workers own nothing. Keep a graph or manifest file the orchestrator updates. Workers should be killable at any moment without losing the run.
- Back up before any worker acts. Every rewrite worker in my pipeline writes the original row to disk before drafting a word. It has saved me more than once.
- Gate irreversible actions behind a script, not an agent. My verify gate is deterministic Python. Agents propose; code disposes.
- Spend model quality where decisions live. The orchestrator and anything doing architectural judgment gets the strongest model I have access to; mechanical workers run cheaper. The quality gap on execution-level work is smaller than the invoice gap.
- Cap the team. Three or four agents. Past that, coordination cost grows faster than throughput.
If you want the concrete setup mechanics — config, spawning, monitoring — I keep a separate agent teams setup guide current, and for the swarm-style variant where many agents share a queue, my notes on Open Swarm multi-agent systems cover what changes at larger scale. And if you are still deciding whether terminal agents are the right layer for your work at all, start with Claude Cowork vs Claude Code.
The uncomfortable summary
Agent teams are not a smarter way to code. They are a management structure, and they inherit management's failure modes: meetings that cost more than the work, summaries that lose the detail that mattered, idle headcount. The teams that work are the ones designed like good engineering organizations — clear ownership, durable written artifacts, irreversibility concentrated at the top, and communication as the exception rather than the medium.
Design the permissions and the artifacts first. The conversation between agents is the last thing you add, not the first.
I build orchestrated multi-agent pipelines like this for client codebases and content operations — if you have a workload that is too big for one context window and too risky for unsupervised automation, tell me what you are running and I will tell you honestly whether a team is worth the tax.
