Four Claude Code Agents-Topologies
Claude Code now ships four ways to run work in parallel…
Layers
There is an advantage and also an a danger in the way Claude Code can spin up and configure agents on the fly to accomplish tasks.
So in order to get my head around the inner workings of Claude Code, I broke it down into three usage tiers…you can think of these as three layers of use.
I get the sense that the vast majority of users live in layer one, making use of the automatic configurations of Claude under the hood.
So Claude routes the flow of data and tools used.
Subagents get spawned mid-conversation when a side task would flood the main context.
Claude can propose an agent team when it sees parallel work. You did not pick any of that.
I think of layer two as vocabulary-gated. Agent teams, /batch, and agent view itself are things you have to know exist to ask for.
Claude will not route you into them if you do not request the workflow.
If you do not know /batch is a thing, you will run 30 PRs sequentially.
If you do not know agent view is a thing, you will tab between terminals.
The model cannot recommend a feature you have not unlocked in your own head.
Layer three is where risk and cost becomes major considerations…whether to enable the experimental agent teams flag.
Whether to spend tokens on five teammates instead of one session.
Whether to let /batch open thirty PRs against your repo.
These are not task decisions but rather they are policy decisions and it is best if Claude should not make them for you.
So the honest answer…
Trust Claude for the tactical routing. Subagents, worktrees, the obvious cases. The model is good at that and it gets better.
Own the strategic gestures yourself.
Agent view as a workflow choice.
Agent teams as an experiment you have consented to.
/batch as a deliberate fan-out.
These are vocabulary and risk and the user is the only one who can make those calls.
But I think the four-topology taxonomy is probably a transitional artefact.
Along the same arc as compilers, package managers, frameworks.
Today you have to learn the surface. In two years much of it will be hidden behind one phrase to the model. The taxonomy survives only as the mental model that helps you debug when the routing gets it wrong.
How to choose?
Layer one is automatic
Claude already routes some of this. Subagents get spawned mid-conversation when a side task would flood the main context.
Layer two is vocabulary-gated
There are things you have to know exist to ask for. Claude will not route you into them if you do not request the workflow.
As I have said before, the model cannot recommend a feature you have not unlocked in your own head.
Layer three is about risk & cost
Whether to enable the experimental agent teams flag. Whether to spend tokens on five teammates instead of one session. Whether to let /batch open thirty PRs against your repo.
An unseen shift?
Step back from the four topologies and one pattern is visible across all of them…
Context is the scarce resource. Not compute. Not tokens billed.
I hasten to add the caveat that this is true at a user level.
Obviously on a macro and model provider level it is compute capacity.
Context is the working memory of the conversation you are actually trying to have.
Subagents return summaries because their raw context would poison yours.
Agent view exists because watching everything live is a context cost.
Agent teams pass inter-agent messages precisely so the lead does not have to ingest every teammate’s transcript.
Parallelism in agent systems is, increasingly, a strategy for protecting context and not for finishing faster.
Concurrency in human engineering teams is about throughput.
Concurrency in agent systems is about who has to read what.
The four coordination primitives, in Claude Code CLI
Subagents for context hygiene
You spawn one with the Agent tool. It runs in its own context window, does the work, and hands back a single summary. Your main conversation never sees the raw tool output.
Example: You ask Claude to audit a branch. It launches a subagent with subagent_type: “Explore” to grep the repo. Fifty tool calls happen inside the subagent. You get back a 200-word report.
/batch with packaged fan-out
One prompt at the top, N subagents underneath, each in its own worktree. Results merge back.
Example: /batch over a list of ten files, one subagent per file, each in a separate checkout. They run in parallel. No file conflicts because no two agents touch the same tree.
Agent Teams for peer coordination
Multiple agents in a shared workspace, messaging each other. No auto-isolation.
Example: A planner agent and an implementer agent on the same repo. The planner writes a spec file, the implementer reads it and edits the code.
Chief AI Evangelist @ Kore.ai | I’m passionate about exploring the intersection of AI and language. From Language Models, AI Agents to Agentic Applications, Development Frameworks & Data-Centric Productivity Tools, I share insights and ideas on how these technologies are shaping the future.
Run agents in parallel - Claude Code Docs
Compare the ways Claude Code can take on multiple tasks at once: subagents, agent view, agent teams, and isolated…code.claude.com
Cobus — the three-layer framing clicked something for me. Layer two is the one nobody talks about — "the model cannot recommend a feature you have not unlocked in your own head." That's not a UX problem, that's a knowledge gap that determines whether you're using 20% of the tool or all of it. Most businesses I build AI agents for are stuck permanently in layer one because nobody showed them layer two exists. The context-as-scarce-resource reframe is the real insight here though. Everyone obsesses over compute costs and token limits but the actual bottleneck is keeping the conversation coherent when you're running parallel work. Subagents returning summaries instead of raw output — that's not just an architecture choice, that's a philosophy about what information deserves attention.
I work with Claude Code daily and the difference between spawning a subagent vs cramming everything into one context window is the difference between clear thinking and noise. The prediction that these coordination primitives eventually abstract away feels right — the best infrastructure is the kind you stop noticing. Good piece.