Agents vs sub-agents: what they are and how they work together
If you have been building with AI agents, you have run into "agent" and "sub-agent" as separate concepts. In most frameworks, though, the underlying code is nearly identical. The distinction is about relationships, not implementation. But it matters once your system needs to do more than one thing well.
What is an agent?
An agent is an LLM with a loop. It receives a task, reasons about what to do next, optionally calls a tool, looks at the result, and repeats until it thinks the job is done. The difference between an agent and a regular prompt-response call is that the agent decides its own next step.
This loop is the same whether you are using LangGraph, CrewAI, AutoGen, or the OpenAI/Anthropic SDKs. The frameworks differ in how they dress it up, but the core cycle is identical.
What is a sub-agent?
A sub-agent is an agent that gets called by another agent. No special class, no separate interface. The "sub" just describes the relationship.
When an agent hits something that would be better handled by a specialist, it hands that piece off to a sub-agent. The sub-agent runs, returns a result, and the parent keeps going.
The parent agent is the orchestrator. It splits the request, routes pieces to the right sub-agents, collects results, and puts together the final response.
How they differ
| Aspect | Agent | Sub-agent |
|---|---|---|
| Called by | User or system | Another agent |
| Scope | Owns the full task | Owns one piece |
| Context | Broad, session level | Narrow, task specific |
| Tools | General or mixed | Specialized |
| Lifetime | Often long running | Usually short lived, spun up per task |
It really comes down to scope. An agent owns the conversation. A sub-agent owns a slice of work inside that conversation.
What this looks like in practice
Imagine you are building a coding assistant. A user says "fix the login bug." The orchestrator agent does not try to do everything itself. Instead:
Each sub-agent gets a narrow job with only the tools it needs. The code search agent has no business writing files. The test runner does not need a search tool. Keeping tools scoped this way means the LLM is less likely to get confused and reach for the wrong one.
When sub-agents make sense (and when they don't)
Sub-agents add orchestration overhead, so they are not free. They pay off when the task splits into independent pieces that need different tools or prompts, when you want failure isolation so one broken step does not tank the rest, or when a single agent's context would get too bloated.
They are not worth it when the task is simple enough for one agent, when the overhead would cost more than it saves, or when the steps share so much context that splitting them just creates a serialization headache.
Common patterns for wiring them together
Three patterns show up the most:
Sequential works when each step depends on the one before it. Parallel works when the pieces are independent and you want speed. Hierarchical is for bigger systems where you need multiple levels of delegation.
Most real systems mix these. You might fan out two sub-agents in parallel, wait for both, then feed the combined result into a third one sequentially. Pick the shape that fits the problem.
The short version
Agents and sub-agents are the same machinery. The difference is just who spawns whom. Split when a single agent is juggling too many tools or its context window is getting stuffed. Don't split before you actually feel that pain. The orchestration overhead is real.