--- title: "Sub-Agents, Agent Teams and Workflows" description: "Use sub-agents and teams effectively, with the labyrinth analogy for clean delegation, while avoiding the context cliff and runaway cost" type: "lesson" locale: "en" course: "Claude Code Mastery - Becoming a Power User" number: "2.5" canonical: "https://agenticschool.dev/courses/claude-code-mastery/sub-agents-agent-teams-and-workflows" datePublished: "2026-06-12" dateModified: "2026-06-12" --- # Sub-Agents, Agent Teams and Workflows - Course: Claude Code Mastery - Becoming a Power User - Lesson: 2.5 - Duration: 25 min - Level: fortgeschritten - Status: published - Canonical URL: https://agenticschool.dev/courses/claude-code-mastery/sub-agents-agent-teams-and-workflows - Locale: en > Use sub-agents and teams effectively, with the labyrinth analogy for clean delegation, while avoiding the context cliff and runaway cost ## Summary One agent can only hold so much in context before quality drops off the cliff. Sub-agents let you delegate a self-contained job to a fresh agent with clean context, which keeps the main agent sharp. This lesson covers the context-cliff motivation, the labyrinth analogy for delegation, when to run sub-agents sequentially versus in parallel, and how to keep a team of agents from quietly multiplying your bill. ## What you learn - Why sub-agents exist: protecting the main context window from the performance cliff - The labyrinth analogy: a sub-agent explores a branch and returns only the conclusion - Sequential versus parallel, and keeping multi-agent workflows from multiplying your costs ## Summary A sub-agent is a fresh agent you spawn for a contained task. It does the work in its own clean context window and returns only the result, so your main agent stays focused and never hits the performance cliff from carrying everything at once. This lesson explains why that matters, gives you the labyrinth analogy that makes good delegation obvious, and covers the practical choices - sequential versus parallel, which model to use, how to scope the job - that decide whether a team helps or just burns money. ## What you will learn You will learn why sub-agents exist and the context-cliff problem they solve, the labyrinth analogy for scoping delegated work, how to write a clean brief for a sub-agent so it returns a tight conclusion rather than a mess, when to run agents sequentially versus in parallel, and how to watch costs so a team of agents does not quietly multiply your bill several times over. ## Prerequisites The tokens, context and performance-cliff lesson from Course 1, and a comfortable single-agent workflow. Multi-agent only pays off once you have genuinely mastered one agent, because everything here is about managing the limits you first met in Course 1 - now across several agents instead of one. ## The problem You give your agent a big task. Halfway through, its context window is stuffed with file contents, command output, dead ends it explored and conversation history. The performance cliff hits: it starts forgetting the original goal, contradicting earlier decisions, and getting fuzzy on details that were crystal clear an hour ago. The work it does in the second half is worse than the first, not because the model degraded, but because its desk is buried. You cannot fix this by being a better prompter. The window is simply full of noise that the task generated along the way. ## Why sub-agents exist A sub-agent solves the buried-desk problem by doing the messy exploration somewhere else. You spawn a fresh agent with an empty context, hand it one self-contained job, and it works through all the file-reading, command-running and dead-ends in its own window. When it is done, it returns only the conclusion to your main agent. All the noise - the twelve files it read, the failed approaches, the raw command output - stays in the sub-agent's context and never touches yours. Your main agent's desk stays clean, so it stays sharp for the whole task. That is the entire point: sub-agents are a context-management tool first, a parallelism tool second. ## The labyrinth analogy Picture your main agent walking through a labyrinth toward a goal, holding the thread that marks the path back. Every side passage it explores in person risks losing its place and forgetting the route. Now imagine it can send a scout down a side passage instead. The scout explores the whole branch - reads everything, hits the dead ends, finds the answer - and comes back to report just one sentence: "that passage leads to the treasury, take the second left." The main agent never left the main path, never lost the thread, and gained exactly the knowledge it needed. That is a sub-agent. You delegate a branch of the work, the sub-agent absorbs all the mess of exploring it, and your main context receives only the clean conclusion. - Good sub-agent jobs are self-contained: "find which file defines the auth middleware and summarise how it works". - The sub-agent does all the noisy work: reading many files, running searches, trying approaches. - It returns a conclusion, not a transcript: a tight summary the main agent can act on. - Your main context only grows by that conclusion, not by everything the sub-agent touched. ## Sequential versus parallel Once you have sub-agents, you can run them two ways, and choosing right matters for both correctness and cost. Run them sequentially when each step depends on the last - explore, then based on what you found, build, then based on the build, test. The order is the logic. Run them in parallel when the jobs are genuinely independent: summarising five separate files, or checking three unrelated subsystems. Parallel is faster but only safe when there is no shared state the agents would trip over. The honest default is sequential: it is easier to reason about, easier to debug, and most real work has dependencies between steps. Reach for parallel only when the independence is obvious. - Sequential: each step needs the previous step's result. Easier to reason about and debug. The safe default. - Parallel: jobs are fully independent with no shared state. Faster, but only correct when truly independent. - When unsure, go sequential - a wrong parallel split causes subtle, hard-to-trace bugs. - Note the CLAUDE.md axioms in this very project insist on sequential sub-agent work for exactly this reason. ## Cost control Every agent costs tokens, and a team multiplies that fast. Three sub-agents plus a main agent is four context windows being filled and billed, and if you spawn them carelessly the bill climbs quietly. Three habits keep it sane. First, only spawn a sub-agent when the focus it buys is worth the spend - a single agent handles plenty of work fine, and not everything needs delegating. Second, match the model to the job: a narrow extraction or summarisation sub-task can run on a small, cheap model while the main agent uses a strong one for the reasoning. Third, scope sub-agent jobs tightly so they finish fast and do not wander, because a vague brief turns a cheap scout into an expensive explorer. The goal is to buy focus where focus is worth it, not to run a standing army of agents. ## Typical mistakes The expensive ones: spawning sub-agents for work a single agent would handle fine, so you pay for coordination you did not need; running jobs in parallel that secretly share state and corrupt each other; giving a sub-agent a vague brief so it returns a sprawling transcript that re-pollutes your main context instead of a clean conclusion; and using a flagship model for every sub-task when a cheap one would do. Delegate deliberately, scope tightly, and pick the model per job. ## Business ROI Sub-agents are how you scale the amount of real work an agentic workflow can do without quality collapsing on the cliff. A team that delegates well can take on tasks far larger than a single context window could ever hold, while keeping the final output sharp, because the main agent never drowns in detail. Done with discipline - delegate only when worth it, cheap models for narrow jobs, tight scopes - you get the throughput of a team for a fraction of what careless multi-agent spending would cost. For a founder, that is the difference between an agent that helps with tasks and an agentic system that runs whole projects. ## Checklist You are ready to move on when each of these is true. The next lesson goes deep on managing context across one or many agents. - You can explain why a sub-agent protects the main context window. - You can use the labyrinth analogy to decide what makes a good delegated job. - You know when to run sub-agents sequentially versus in parallel, and why sequential is the default. - You have three concrete habits for keeping multi-agent cost under control. ## Resources Bookmark the Claude Code documentation on sub-agents for the current way to define and invoke them, including custom sub-agent configurations. The model-selection lesson from Course 1 is your reference for matching a cheap model to a narrow sub-task. Your CLAUDE.md is the right place to state team rules - sequential by default, when to delegate - so the agent applies them automatically. ## Your task Take one task that normally bloats your context - something that needs exploring several files before acting. Run it twice: once with a single agent doing everything, and once where you have the agent spawn a sub-agent to explore and report back a conclusion before it acts. Notice how much cleaner the main session stays the second time. That is the cliff being managed instead of hit. ## Next lesson Managing context across one or many agents is its own craft. The next lesson goes deep on the levers: why auto-compaction quietly hurts, how to re-inject your goals after it, writing handover documents, when to reset a chat entirely, and dialling thinking effort to match the task. ## Transcript This lesson is a written, text-first guide. One agent can only hold so much in context before quality drops off the cliff. Sub-agents let you delegate a self-contained job to a fresh agent with clean context, which keeps the main agent sharp. This lesson covers the context-cliff motivation, the labyrinth analogy for delegation, when to run sub-agents sequentially versus in parallel, and how to keep a team of agents from quietly multiplying your bill. You will use sub-agents and teams effectively, with the labyrinth analogy for clean delegation, while avoiding the context cliff and runaway cost. Work through the sections in order, try the task at the end in a real project, and move on once it works for you. There is no video required - everything you need is in the written steps above.