A single Claude Code session auditing a large codebase hits a wall that has nothing to do with intelligence: the context window fills with file dumps, and by the fortieth file the agent is summarizing away the details you needed from the fourth. Subagents exist to break that wall. Instead of one context doing everything, the main agent delegates bounded jobs to workers that each get a fresh context window, and only their conclusions come back.
Orchestration is the largest CCA-F domain at 27% of the exam, and subagent questions are its core. This guide covers how subagents actually work in Claude Code, the delegation patterns worth naming, and the judgment calls the exam tests. For the full exam map, start with the domains breakdown.
What a Subagent Actually Is
A subagent in Claude Code is a separate agent instance with three defining properties:
- Its own context window. The subagent starts fresh. It does not inherit the main conversation, and its intermediate work (file reads, search results, dead ends) never lands in the parent's context. Only its final report comes back.
- Its own system prompt. Defined in an agent file, so a code-reviewer subagent can carry review-specific instructions the main agent does not need.
- A scoped toolset. Each agent definition can restrict which tools the subagent may use, which is both a safety boundary and a focus mechanism.
Custom subagents live as Markdown files with YAML frontmatter in .claude/agents/ (project-level) or ~/.claude/agents/ (user-level):
---
name: code-reviewer
description: Reviews diffs for correctness bugs. Use after any nontrivial change.
tools: Read, Grep, Glob, Bash
---
You are a code reviewer. Examine the diff for correctness issues...
The description field matters more than it looks: the main agent reads it to decide when to delegate, so a vague description means the subagent never gets used or gets used for the wrong jobs. Treat it as routing logic, not documentation.
Preparing for CCA-F? Practice with 390+ exam questions
Why Delegation Beats One Big Context
The exam frames subagent value in three ways, and all three show up as scenario questions:
Context isolation. A research subagent can read fifty files and return three paragraphs. The parent pays three paragraphs of context, not fifty files. This is the difference between an agent that stays sharp across a long task and one that degrades as its window fills with intermediate noise.
Parallelism. Independent subagents can run concurrently. Auditing eight modules with eight parallel workers takes roughly the wall-clock time of the slowest one, and each worker's context holds exactly one module's detail.
Specialization. A dedicated system prompt plus a restricted toolset outperforms a general-purpose prompt juggling roles. The reviewer subagent that can only read cannot accidentally "fix" things mid-review.
The Orchestration Patterns Worth Naming
CCA-F questions describe a scenario and ask which shape fits. These four cover nearly every case:
Fan-out / fan-in. Split a large job into independent slices, run a worker per slice, merge results. The classic for audits, migrations, and multi-file analysis. The judgment call the exam probes: slices must be genuinely independent, because workers cannot see each other's findings.
Pipeline. Stage A's output feeds stage B: research, then plan, then implement, then review. Each stage can be a different subagent with a different toolset. Pipelines trade latency for quality gates between stages.
Orchestrator-workers. The main agent holds the plan and the running state; workers execute bounded tasks and report back. This is Claude Code's native shape: the parent never loses the thread because the thread never leaves its context.
Evaluator loop. A generator produces work, a separate evaluator judges it, and the loop repeats until the evaluator passes it. Separating the two roles into different contexts avoids the self-grading bias of asking one agent to critique its own output.
The anti-pattern the exam loves: reaching for multi-agent orchestration when a single agent with a good prompt would do. Anthropic's own guidance is to start with the simplest architecture that works, and exam answers reward that instinct. Multiple agents earn their overhead when the task exceeds one context window, needs genuine parallelism, or benefits from adversarial separation (generator vs evaluator).
Build a multi-agent supervisor and two talking agents
The patterns stick after you have built one: a LangGraph supervisor delegating to workers, and two agents coordinating over the A2A protocol.
Master These Concepts with Practice
Our CCA-F practice bundle includes:
- 6 full practice exams (390+ questions)
- Detailed explanations for every answer
- Domain-by-domain performance tracking
30-day money-back guarantee
Communication Costs and Failure Modes
Professional-level questions go past the happy path:
Subagents cannot talk to each other. All coordination flows through the parent. If worker B needs worker A's output, that is a pipeline through the orchestrator, not a peer conversation. Designs that assume peer-to-peer chatter inside Claude Code are wrong answers.
Results must be synthesized, not concatenated. Eight workers returning eight reports leave the parent with a merge job. Good orchestration prompts tell workers the shape of the report they must return, so synthesis is cheap and mechanical.
Delegation has overhead. Each subagent spins up fresh, re-reads whatever context it needs, and burns tokens doing so. Delegating a two-minute task with a one-minute setup cost is a loss. Exam scenarios test this arithmetic: small, quick lookups stay in the main agent; big, noisy, parallelizable work gets delegated.
Long-running state needs checkpoints. A worker that dies mid-task loses its context. Durable state (files written, commits made, results logged) survives; conversational state does not. Reliability questions in the Context Management domain (15%) reuse this exact principle.
How This Shows Up on the Exam
Representative question shapes, from the same angles our practice tests drill:
- A team runs one agent that reads an entire monorepo before answering anything, and answers degrade over the session. What architecture change helps most? (Delegate reading to research subagents; keep the parent's context for decisions.)
- A reviewer agent keeps "fixing" code during reviews. What is the cleanest prevention? (Restrict the reviewer's toolset to read-only tools in its agent definition.)
- Eight independent module audits need to finish today. Which pattern? (Fan-out with a defined report format, fan-in synthesis in the parent.)
- When is a single agent the right answer? (When the task fits one context and has no parallel structure: orchestration adds cost without benefit.)
The Claude Code course dedicates Level 7 to exactly this territory, with graded boss projects where you orchestrate real subagent teams. And Preporato's CCA-F practice tests carry the orchestration domain at its full 27% weight across 6 exams and 390 questions, with explanations that name the pattern behind every answer.
Key Takeaways
- Subagents = separate context window + own system prompt + scoped tools, defined in
.claude/agents/files whosedescriptionacts as routing logic - Delegate what is noisy, parallel, or specialized; keep what is quick and sequential
- Know fan-out/fan-in, pipeline, orchestrator-workers, and evaluator loops by name and by failure mode
- All coordination flows through the parent; workers never talk peer-to-peer
- The strongest exam instinct: simplest architecture that works, and escalate only when the task demands it
Continue with the hooks deep dive for the automation layer, or test yourself against the full domain in the CCA-F practice exams.
Sources:
Last updated: July 10, 2026
Ready to Pass the CCA-F Exam?
Join thousands who passed with Preporato practice tests