In earlier posts in this series, I proposed agentics as a way to study artificial agents and agent systems more systematically [1]. I offered a broad working definition:
An agent is an entity capable of selecting and performing actions in pursuit of objectives, within an environment, under constraints [2].
I subsequently suggested that agentic capabilities can be understood along three primary axes:
- Agency: What can the system do?
- Autonomy: Who or what controls what it does next?
- Intelligence: How well does it choose?
Objectives orient these capabilities. The environment affords and constrains them. Governance bounds them. Identity becomes important when an agent persists as the same operational actor over time [3].
That framework largely treated the agent as an individual actor.
Subagents, however, complicate the picture. A research agent might delegate market sizing to one worker, competitor research to another, and source verification to a third. A coding agent might ask one subagent to inspect an unfamiliar codebase while another runs tests. A customer-service agent might transfer a conversation to a billing specialist.
Once agents can delegate objectives to other agents, agent architecture starts to shade into organizational design.
That, I think, is the more interesting way to understand subagents.
What Is a Subagent?
The term subagent is widely used, but it does not yet have a stable technical definition.
In current implementations, a subagent typically has its own model invocation or reasoning loop, its own context, specialized instructions or tools, and a bounded task delegated by another agent. Anthropic’s Claude Code subagents, for example, operate in separate context windows with their own prompts, tools, and permissions. LangChain’s subagent pattern similarly has a supervisor call specialist agents that work in isolated contexts and return their results [4,5].
A useful working definition is:
A subagent is an agent system that receives delegated responsibility for a bounded objective and exercises some local autonomy in pursuing it, while remaining within the authority or orchestration structure of another agent system.
The same analytics agent could serve a user directly in one system and act as a subagent inside a larger business assistant in another. So subagent is best understood as a relational term. It tells us where an agent sits within a structure of delegation and authority.
That shifts the questions we should ask. What objective was delegated? What information and tools came with it? Which decisions can the subagent make on its own? And who remains responsible for the outcome?
These questions are more revealing than simply asking which model powers the subagent.
Tools, Skills, and Subagents
Not every specialized capability needs to become an agent.
A tool exposes an operation. A calculator calculates. A search API retrieves information. A database interface executes queries. The calling agent generally decides why and when to invoke it.
A skill gives an agent procedural competence: instructions, examples, scripts, resources, or tool-use conventions for performing some class of work. The reasoning locus can remain the same agent.
With a subagent, responsibility for an outcome moves to another reasoning process.
Instead of teaching the parent agent how to investigate a problem, the system can delegate the problem itself:
Investigate these possible causes and return your diagnosis.
The subagent can decide what to inspect, which tools to use, how to revise its approach, and when it has enough evidence to report back.
One compact way to express the distinction is:
A tool performs an operation.
A skill equips an agent to do a kind of work.
A subagent is given responsibility for a result.
The boundary is not clean, nor does it need to be. OpenAI supports an “agent as tool” pattern in which a manager invokes a specialist agent through what externally looks like a tool call [6]. A sufficiently elaborate skill can also reproduce behavior that another framework packages as a separate agent.
The architecture matters less than where meaningful decision-making, context, and responsibility actually reside.
Why Use Subagents?
The popular image of multi-agent systems is often a collection of intelligent specialists debating, negotiating, and collaborating.
In practice, some of the strongest reasons to use subagents are much more prosaic.
One is context isolation.
Complex tasks generate large amounts of intermediate material: search results, source code, documents, logs, failed attempts, database records, and partial hypotheses. Keeping all of that in one context can eventually become counterproductive.
A subagent can consume task-specific material in a separate context and return only what the parent needs [4,8]. Two agents using the same underlying model may therefore still be useful because they are attending to different information, not because they possess different intelligence.
A second reason is parallelism.
Some problems divide naturally into independent workstreams. A research task may involve several markets or hypotheses. A software task may allow the frontend, backend, tests, and security to be investigated independently.
Anthropic reports that parallelizing subagents and tool calls reduced elapsed research time by as much as 90% on complex queries in its internal system [8]. That is a vendor result for one architecture, but the principle is intuitive: parallelism pays when the task itself is parallelizable.
Subagents also create useful capability and permission boundaries.
A search worker may use a fast model with web access. A reviewer may see the artifact but not the author’s reasoning. An execution agent may be able to prepare a transaction without being allowed to approve it. The system as a whole can therefore possess broad agency without every component possessing all of it.
Supervisor, Workers, and Nested Autonomy
For most production systems today, the most useful default remains hierarchical.
A supervisor receives the overall objective, decides whether it needs help, delegates bounded pieces of work, and integrates the results. Workers have freedom over how to perform their assignments, while the supervisor retains responsibility for the larger task.
Anthropic’s research system follows this orchestrator–worker pattern. LangChain’s subagent architecture centers on a supervisor calling specialists. Google’s Agent Development Kit supports coordinator–subagent workflows. OpenAI distinguishes between specialists invoked as tools and specialists that receive a handoff [5,6,7,8].
This creates a form of nested autonomy.
The supervisor decides what should be delegated, to whom, and how the returned work will be used. The worker decides how to pursue the delegated objective within the authority it has been given.
A worker can therefore have substantial freedom over its next action without having authority to redefine the user’s overall objective. It may decide how to do the job without deciding whether the job should exist.
Delegation and handoff also need to be separated.
In delegation, the parent keeps ownership of the overall result. It asks another agent to perform a bounded task, receives the output, and decides what happens next.
In a handoff, another agent takes over the next stage of the interaction. OpenAI explicitly distinguishes these patterns [6].
The difference affects more than control flow. A handoff raises questions about memory, context, identity, policy, and accountability. Which agent is now representing the system to the user? Which rules govern the interaction? What information travels with the handoff? Who is responsible if the task is left incomplete?
These are organizational questions as much as technical ones.
Subagents Through the Agentics Lens
Subagents make two aspects of the earlier framework especially important: agency becomes partitioned, and autonomy becomes nested.
The collective may have broad capabilities, but individual agents can receive different tools, permissions, data, and action spaces. Delegation itself becomes part of the parent agent’s agency: one of the things it can do is create or invoke another decision-making process.
Autonomy becomes layered because control is exercised at different levels. The parent can retain authority over the overall objective while workers control local execution. Deterministic software may still sit above or around both, enforcing budgets, approvals, retries, or termination conditions.
Several other consequences follow.
Objectives become hierarchical. The user’s goal is translated into sub-objectives, and the quality of that translation becomes part of the system’s intelligence. A worker may execute its assignment perfectly and still contribute little if the parent decomposed the problem badly.
The environment also becomes partly social. Messages from other agents, delegated tasks, shared artifacts, approvals, disagreements, and status changes become inputs to which an agent responds.
Governance now has to address relationships among agents, not just individual permissions. Who may delegate? Who may create another worker? Which information may cross boundaries? Which actions require approval? Where does final authority reside?
Identity can become layered as well. Some subagents are ephemeral processes that exist for a single task. Others may be persistent services with stable permissions, memory, and organizational roles.
The resulting system is no longer well described as a single actor operating in an environment. It is a structured collection of actors with differentiated objectives, information, authority, and responsibility.
More Agents Are Not Necessarily Better
Every additional agent creates a coordination cost.
Tasks must be decomposed. Context has to be selected and transmitted. Results must be interpreted. Dependencies have to be synchronized. Conflicting conclusions need to be resolved. Errors can propagate across boundaries.
Communication is lossy as well. A supervisor generally receives a summary of what a worker found, not the worker’s complete internal state. The compression that makes context isolation valuable can also discard something important.
Anthropic has described early versions of its research system spawning as many as 50 subagents for simple queries, duplicating work, chasing nonexistent sources, or continuing long after useful research had been completed. It responded with clearer task descriptions, effort budgets, better tool interfaces, tracing, evaluation, and tighter operational controls [8].
Controlled research shows a similarly mixed picture.
A 2026 preprint studying 260 configurations across six agentic benchmarks found outcomes ranging from an 80.8% improvement on decomposable financial reasoning to a 70% decline on sequential planning. Tool-heavy tasks suffered additional coordination overhead, while centralized verification helped limit error propagation [9].
The exact numbers should not be generalized too far from one study. The more durable lesson is that multi-agent performance depends heavily on the shape of the task.
If several regions of a problem can be explored independently, parallel workers can help. If the task depends on a tightly coupled chain of reasoning in which each step needs the full state produced by the previous one, splitting that chain can make things worse.
There are also cases where a separate agent is unnecessary.
Suppose four “agents” all use the same model, act sequentially, and differ mainly in their prompts. A single agent that loads different skills at each stage may be simpler and cheaper.
A 2026 preprint found that, for several small and serializable systems, a single agent equipped with skills achieved similar performance while reducing token use by 54% and latency by 50% on average [10]. The advantage diminished as the skill library grew and semantically similar skills became harder to distinguish; hierarchical routing helped recover performance [10].
A practical progression is therefore:
| Need | Usually the simplest pattern |
|---|---|
| Add procedural knowledge | Skill |
| Invoke a fixed capability | Tool |
| Select one specialist | Router |
| Isolate and delegate a complex subtask | Subagent |
| Transfer ownership | Handoff |
| Explore independent work in parallel | Parallel workers |
| Enable peer coordination | Agent team |
| Enforce a predictable sequence | Workflow |
These are not mutually exclusive categories. A supervisor may invoke subagents through tool interfaces; those subagents may themselves load skills; a deterministic workflow may surround the entire system.
The useful question is whether a new organizational boundary buys something concrete.
Some Practical Defaults
I would start with one agent.
A second reasoning locus is worth adding when it creates a real boundary in context, permissions, capability, verification, or parallel work [14,15].
When work is delegated, the assignment should define an outcome rather than a vague topic. “Research semiconductors” is underspecified. A useful task tells the worker what question to answer, what evidence is expected, what scope to observe, and when to stop. Anthropic reports that vague task descriptions produced duplication and gaps in its research system [8].
Context should be selective in both directions. Workers need enough information to succeed, but not necessarily the parent’s entire history. Likewise, they should return what the parent needs for the next decision rather than dumping everything they encountered.
Parallelism should be reserved for work that is genuinely independent [8,9]. Where the stakes justify it, production and verification can also be separated: a writer need not be its own reviewer, and an implementer need not be its only tester.
Finally, delegation needs limits. An agent capable of spawning workers can expand cost, latency, permissions, and effective agency. Fan-out, recursion depth, tool use, time, and budget therefore become governance parameters.
The object being evaluated is increasingly the organization rather than any one worker. A system can fail even when every individual agent appears competent—because the decomposition was wrong, critical context was lost, work was duplicated, or the final synthesis was poor.
From Subagents to Agent Teams
Subagents usually imply a vertical relationship: a parent delegates, and a worker returns.
Agent teams allow richer horizontal interaction.
Anthropic distinguishes Claude Code subagents from agent teams in which independent agents maintain their own contexts, share work, and communicate directly [11]. Google’s Agent2Agent protocol addresses a broader case still: independently implemented or remotely hosted agents exchanging tasks and results across technical or organizational boundaries [12].
Experimental systems are beginning to explore persistent workers, peer communication, recursive delegation, shared task boards, remote agents, and long-running work across many sessions.
Anthropic has described an experiment in which 16 agents operating across nearly 2,000 Claude Code sessions produced a roughly 100,000-line Rust C compiler capable of building Linux 6.9 for several architectures. The experiment consumed about $20,000 in API costs [13].
What is striking is how quickly the vocabulary used to describe such systems begins to resemble organizational theory: roles, teams, delegation, authority, budgets, communication, supervision, memory, and accountability.
We may be rediscovering organizational design inside software architecture.
That raises a set of questions that go beyond implementation.
How good are agents at deciding when to delegate? Can they divide an objective into sub-objectives that are neither redundant nor incomplete?
How should context be allocated across agent boundaries? What gets lost when one agent compresses its work for another?
How much authority should delegation carry? May a worker gather information, modify artifacts, spend resources, make commitments, or delegate again?
When does centralized supervision outperform direct peer coordination?
And when several agents contribute to a consequential outcome, where does responsibility ultimately reside?
These problems sit at the intersection of computer science, distributed systems, organizational theory, economics, cognitive science, HCI, and governance—the same cross-disciplinary territory that motivated the idea of agentics in the first place [1,2].
Summary
Subagents are often described as a technique for making agents more capable. As we have seen, that is not quite accurate.
Once an agent can delegate objectives to other agents, capabilities and information can be partitioned, autonomy can exist at several levels, and authority has to be allocated explicitly.
Sometimes that organization improves performance. Sometimes it merely adds expense, latency, and coordination failure to something a single agent could have done more reliably.
So the central design question is not how many agents a system should contain. It is how agency, autonomy, information, and authority should be organized around the task.
At that point, we are no longer designing only agents.
We are designing agentic organizations.
Onward !
—SriG
References
- Madhvanath, S. “Agentics: Toward a Science of AI Agents.” SriG’s Blog, December 19, 2025.
- Madhvanath, S. “What Is an Agent, Really? A Cross-Disciplinary View.” SriG’s Blog, January 28, 2026.
- Madhvanath, S. “Agency, Autonomy, and Intelligence: What Makes an Agent Agentic?.” SriG’s Blog, May 4, 2026.
- Anthropic. “Create Custom Subagents.” Claude Code Documentation.
- LangChain. “Multi-Agent Systems” and “Subagents.” LangChain Documentation.
- OpenAI. “Orchestration and Handoffs.” OpenAI API Documentation.
- Google. “Collaborative Workflows” and “Multi-Agent Systems.” Agent Development Kit Documentation.
- Anthropic. “How We Built Our Multi-Agent Research System.” June 13, 2025.
- Kim, Y., et al. “Towards a Science of Scaling Agent Systems.” arXiv:2512.08296, version 3, April 2026. Preprint.
- Li, X. “When Single-Agent with Skills Replace Multi-Agent Systems and When They Fail.” arXiv:2601.04748, 2026. Preprint.
- Anthropic. “Orchestrate Teams of Claude Code Sessions.” Claude Code Documentation.
- Surapaneni, R., Jha, M., Vakoc, M., and Segal, T. “Announcing the Agent2Agent Protocol.” Google Developers Blog, April 9, 2025.
- Carlini, N. “Building a C Compiler with a Team of Parallel Claudes.” Anthropic, February 5, 2026.
- Anthropic. “Building Effective Agents.” December 19, 2024.
- OpenAI. “Agent Definitions.” OpenAI API Documentation.
SriG's Blog 
Leave a comment