Domain 1 — Agentic Architecture & Orchestration (27%)

The largest domain. It is about division of labour: what runs in the main conversation, what gets delegated, what runs in parallel, how results come back, and how control is enforced across the whole thing.

1.1 The agent loop

Every agent, whether you write the loop yourself against the Messages API or let the Agent SDK run it, is the same four beats: gather context → take action → verify work → repeat. The loop's exit condition is the part the exam cares about.

request → response
  ├─ stop_reason == "tool_use"   → execute tools, append tool_result blocks, loop
  ├─ stop_reason == "end_turn"   → the model is finished; exit the loop
  ├─ stop_reason == "max_tokens" → truncated; continue or raise max_tokens, do NOT parse as final
  └─ stop_reason == "refusal"    → safety stop; output may not match your schema

Canonical trap — An option that terminates the loop by checking whether the assistant text contains a phrase like "task complete" is always wrong. Text is generated; stop_reason is a protocol field. Likewise, an option that treats max_tokens as a normal completion is wrong — the response is truncated, and any JSON in it is likely malformed.

1.2 Single agent, subagents, or a workflow?

The four reasons to use a subagent

Know these as a list — questions often ask which benefit applies.

1. Context isolation. A subagent runs in its own conversation. Its intermediate tool calls and results stay inside it; only its final message returns to the parent as the Agent tool result. A research subagent can read fifty files without any of that landing in the main context.
2. Parallelisation. Independent subtasks finish in the time of the slowest one instead of the sum. A code review can run style-checker, security-scanner and test-coverage at once.
3. Specialised instructions. Each subagent gets a tailored system prompt with domain knowledge that would be noise in the main agent's prompt.
4. Tool restriction. A doc reviewer that only has Read and Grep cannot modify anything — regardless of what it decides to do.

What a subagent inherits (and what it does not)

Exam-critical — Because the prompt string is the only channel from parent to subagent, every file path, error message, prior decision and constraint the subagent needs must be written into that prompt. "The subagent will see what the coordinator saw" is false, and questions test it. A fork is the exception: it inherits the parent conversation.

AgentDefinition fields

Subagents are defined three ways: programmatically via the agents option (recommended in SDK apps), as files in .claude/agents/*.md with YAML frontmatter, or the built-in general-purpose agent. Programmatic definitions override filesystem agents of the same name.

Bounding a run

1.3 Parallel vs sequential

Sequential when — Step B needs step A's output. Analysis needs the search results; synthesis needs the analysis; the report needs the synthesis. Chaining is not a performance failure here — it is the data dependency.

A frequent stem: a multi-issue customer message ("my order is late and I was double-charged"). The correct architecture decomposes it into parallel tracks with separate tool sets, then reconciles — not one linear thread that handles issues in the order they were mentioned, and not one subagent per sentence.

1.4 Delegation, routing, and the "everything through everyone" trap

A coordinator should route each request to the subagents it actually needs. Sending every request through every specialist is the classic wrong answer: it multiplies cost and latency, and it dilutes the final synthesis with irrelevant findings. Routing is driven by the subagent's description field for automatic invocation, or by naming the agent explicitly in the prompt when the choice must be guaranteed.

1.5 Error handling across agent boundaries

When a subagent fails, the coordinator has to be able to tell the difference between "found nothing" and "could not look".

Wrong — Return an empty result set. The coordinator synthesises a confident report from partial data and no one knows a source was missing.

Note also that an API error which ends a subagent early (a rate limit, for instance) is never delivered as its result — plan for the coordinator to detect absence, not just read failure messages.

1.6 Task-scoped tool provisioning

An agent exploring a codebase needs Read, Grep, Glob. An agent writing a deployment needs Bash and Write. Giving both to both is the over-provisioning anti-pattern, and it causes real failures beyond security: with more tools in scope the model picks the wrong one more often, and each schema costs context. A tool you leave out of tools is simply not in the subagent's session — no prompt, no error, no temptation.

Watch for — Options phrased as "grant all tools and rely on the system prompt to restrict usage". Instructions in a prompt are not a permission boundary. The same reasoning kills "tell the agent not to call the refund tool until verification" — restrict, gate, or hook it.

← Previous: The mental model  |  Next: Domain 2 — Tool Design & MCP Integration →