I've been building with Claude agents long enough to have made most of the architecture mistakes at least once. The one that takes the longest to see clearly is the monolith-vs-network question — when to keep everything in one context and when to distribute across multiple agents.
The answer isn't intuitive because it depends on factors that aren't obvious until you've shipped both configurations in production.
The Case for One Agent
The strongest argument for keeping work in a single agent is context coherence.
A language model reasons from what's in its context. Everything it knows about the current task — the goal, the constraints, the decisions made so far, the complications that have come up, the patterns it's noticed — lives in that context. When you add each new piece of information, the model can reason about how it relates to everything else. It maintains a coherent model of the task in progress.
When you split work across multiple agents, you introduce handoffs. At each handoff, some of that context gets lost. The summary you pass from Agent A to Agent B is accurate but compressed — it conveys state without necessarily conveying the reasoning that produced it. Agent B knows what Agent A decided but not why, and the "why" often matters for the decisions Agent B needs to make.
For complex, interconnected work — multi-file refactoring, long documents that need to maintain coherence, strategic analysis that builds on itself — the context coherence of a single agent is worth a lot. You don't pay the handoff tax. The reasoning flows continuously through the task.
The Case for Many Agents
The strongest argument for distributing work across agents is independence.
When subtasks are genuinely independent — they can be completed without knowing the status or output of the others — parallelism is free leverage. Multiple agents working simultaneously on non-overlapping scopes can do in one unit of time what a single agent would take multiple units to complete.
Independence also means isolated failure modes. If you have one agent with a large scope and it runs into a confusing situation, it can go sideways in ways that contaminate the whole task. If you have three agents with scoped tasks and one goes sideways, the other two complete successfully. The failure is contained. The fix is specific. This is standard distributed systems design applied to agent networks.
The other argument for many agents is capability specialization. Different subtasks might genuinely benefit from different system prompts, different context, different instructions. A research agent and an implementation agent and a review agent might have meaningfully different operating parameters. A single agent holding all of that simultaneously might be managing more context than it needs for any individual step.
The Design Test
The practical test I apply when deciding the architecture: are the decisions in later steps genuinely dependent on the outcomes of earlier steps in ways that are hard to encode in a handoff protocol?
If yes: one agent, or agents with very rich handoff protocols. If no: distributed agents with clean interfaces between them.
"Hard to encode in a handoff protocol" is doing a lot of work in that sentence. A status update is easy to encode: "Component X is done, here is the output." The nuance of why you made certain choices, what you tried that didn't work, what constraints you discovered during execution — that's harder. The more of that nuanced reasoning matters for subsequent steps, the more you pay for distributing the work.
What I've Built and What I've Learned
At Vibe Tokens we have 28 agent roles. That's not 28 simultaneous agents — it's 28 defined scope-and-authority configurations that can be instantiated for specific tasks.
What I've found: the most valuable specialization is at the level of role definition, not agent count. Each role definition is a carefully designed scope: what this agent knows, what it can decide, what it must escalate. Having clear role definitions makes single-agent tasks more focused (you're loading a specific role configuration, not all of it) and makes multi-agent coordination cleaner (each agent has a defined interface, not an ambiguous scope).
The failure mode I keep seeing in multi-agent systems is scope creep between agents — one agent starts doing work that belongs to another because the interfaces weren't defined clearly enough. The fix isn't technical. It's definitional: clearer scope statements, more explicit handoff protocols, more specific escalation conditions.
The honest meta-lesson: agent architecture questions are mostly organizational design questions with a technical interface. The skills that make human team organization work — clear roles, clean handoffs, good coordination protocols — are the same skills that make agent networks work. The ones that make human organizations fail — ambiguous authority, poor communication, undefined escalation — produce the same failure modes in agent systems.
What's the shape of the work you're trying to automate — and does the distribution of context requirements match the distribution of agents you're considering?
