What You Need to Know
Every agentic system starts from one decision: who owns the control flow. Anthropic's taxonomy has three tiers, separated by who decides the next step. An augmented LLM is a single model call with retrieval, tools and memory added. A workflow is a system where LLM calls and tools are orchestrated through predefined code paths. An agent is a system where the model directs its own process and tool usage. Domain 1 opens here. Placing it right gives the construction work in 1.2 a shape, and no SDK configuration rescues a wrong one.
Take a mobile phone repair shop. Booking in a cracked screen runs the same way every time: log the phone, check the warranty, print a ticket. Diagnosing a phone that will not charge does not. The fault could be the port, battery or board, and each test depends on the last result.
The Three Tiers
The augmented LLM is the basic building block, and most problems need nothing more.
In a workflow, you write the control flow and the model executes inside it, as in the shop's booking-in. The path cannot surprise you, so a workflow is predictable, testable and cheaper per run.
In an agent, the model decides each next step from environment feedback until the goal is met. A diagnostic agent reads the charging test result and picks the next test itself. You get flexibility and pay in latency, token spend, more room for error, and a guardrail burden the workflow never had.
The dividing line
Whoever decides the next step names the tier. A hand-coded three-step chain is a workflow, however capable the model in each step. A model choosing its own tool sequence is an agent, however short the run.
Choosing Between Workflow and Agent
Anthropic's guidance is to find the simplest solution possible and add complexity only when it demonstrably improves outcomes. The working test is path predictability. Steps that are known in advance and repeat for every input, like booking in, belong in a workflow. When the number of steps is unknown and each decision depends on the last, like the charging fault, an agent earns its cost.
Placement fails in two directions. An agent on a fixed pipeline pays agent costs for flexibility the task never uses. An open-ended investigation forced through a rigid chain breaks the first time the real path diverges from the coded one. Cost and latency belong inside this decision: an agent's extra spend has to buy something the workflow could not deliver.
Supervisor Hierarchies and Subagents
When one context window cannot hold the task, the orchestrator-workers shape takes over. A lead agent (the manager or supervisor) decomposes the goal, spawns specialised subagents and synthesises their results. A subagent is a worker that a lead agent spawns and briefs. The shop's lead might give each subagent one parts supplier to price. Anthropic's multi-agent research system is the reference implementation, and in its basic form every result flows back through the lead. For bulky output, the same post recommends a bypass: subagents store their work in external systems and pass lightweight references back to the coordinator. This prevents information loss between stages and saves copying large outputs through conversation history.
Subagents do not share memory. A subagent's context window starts fresh, with no parent conversation. Only the delegation prompt travels from parent to subagent. Every file path, error message, decision and convention the subagent needs must be in that brief. Anything agreed earlier in the orchestrator's own conversation does not exist for the worker. If the owner tells the lead to quote genuine parts only, a supplier subagent never sees that rule unless its brief states it. Designs that assume shared memory are broken by construction.
One exception, as of September 2026, is a fork. In Claude Code, a forked subagent inherits the whole conversation so far. Fork mode is on by default in interactive sessions, and off in the Agent SDK and in non-interactive -p runs unless you turn it on. Every other subagent starts fresh, so the brief is its only channel.
Isolation is also the payoff. Intermediate tool calls, their results and large file reads stay inside the subagent. Only its final message returns to the parent. A research subagent can read dozens of files while the lead's context grows by a summary. Separate windows make parallelism work and add aggregate reasoning capacity. Anthropic reported a lead-plus-parallel-subagents system outperforming a single agent by 90.2% on its internal research evaluation. Parallelism pays only when subtasks are independent, as the supplier checks are. Pricing a repair depends on its diagnosis, and splitting dependent work across parallel subagents recreates the coordination problem with added token cost.
When a multi-agent system misbehaves, trace the failure to the orchestrator first. Vague delegation produces duplicated work and gaps. Overlapping task boundaries produce near-identical outputs. Spawning a dozen subagents for a simple query is an effort-scaling failure in the lead, not incompetence in the workers. The fix is almost always a better brief: an explicit objective, an output format, tool guidance and clear task boundaries, per subagent, every time.
Other Multi-Agent Shapes
Claude Code also offers a peer shape, agent teams: one session leads, and each teammate works in its own context window and messages the others directly. As of September 2026 they are experimental, disabled by default (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 enables them) and need an interactive session, so Agent SDK and -p runs never spawn teammates. The docs keep subagents for quick, focused workers that report back, like the supplier checks. Teams are for teammates who need to share findings, challenge each other and coordinate on their own. They cost more tokens, because each teammate is a separate Claude instance. Even ordinary subagents are not always cut off. Ones that Claude named when it spawned them can message each other.
Dynamic workflows go the other way and move the plan into code. Claude writes a script that orchestrates many subagents. The script decides what runs next and holds the loop, the branching and the intermediate results, so Claude's context holds only the final answer. The docs point to one when a task needs more agents than one conversation can coordinate. That means dozens to hundreds per run, against a handful of long-running peers in a team. They also suit orchestration you want codified as a script you can read and rerun. By this lesson's dividing line, that puts the orchestration back on the workflow side.
Claude Managed Agents (sub-skill 1.2) has a supervisor structure of its own. As of September 2026, a coordinator agent declares a roster of agents it can delegate to, and it delegates one level only. Referencing an agent that has its own roster fails the create or update request with a validation error. A roster lists at most 20 unique agents, though the coordinator can call several copies of each, within the session's thread limit. All of them share the session's sandbox and filesystem, and each runs in its own context-isolated thread.
In the exam
The exam tests the placement decision directly. It draws its vocabulary from one source: Anthropic's "Building effective agents". Distractors blur the dividing line. Both failure directions are punished equally. A stem that names a fixed, auditable, high-volume process is telling you the workflow wins. The single most-tested fact in this sub-skill: subagents do not share memory. Distractors that rely on implicit shared state are always wrong.
Exam Traps
Treating the agent as the default because it is the more capable tier, and reaching for it on a task whose steps are identical every run.
The exam keys the simplest tier that meets the stated requirement. A fixed pipeline gains nothing from model-directed control flow but inherits its cost, latency and unpredictability; the keyed answer for known, repeating steps is a workflow.
Assuming subagents can see the orchestrator's conversation, so a policy agreed with the lead agent will be honoured by its workers.
Unless it is a fork, a subagent's context starts fresh and receives only the delegation prompt. Anything not stated in the brief does not exist for the subagent. The fix is never a respawn, a bigger model or a concurrency change; it is putting the fact into every delegation.
Fixing an architecture mismatch by upgrading the model, on the theory that a stronger model will cope with the wrong tier.
When the stated problem is that the task's predictability profile does not fit the chosen tier, a model swap changes nothing. The exam treats the bigger-model option as a standing distractor for what is actually a control-flow decision.
Believing more subagents means better results, so breadth of spawning is a quality lever.
Parallelism pays only on independent subtasks. Unbounded spawning on a simple query is a documented orchestrator failure mode: duplicated work, gaps and multiplied spend. Effort should scale with query complexity.
Practice Scenario
An observability platform team runs an orchestrator agent on the Claude Agent SDK that decomposes a codebase-wide dependency upgrade into per-service subtasks and spawns one subagent per service. The dependency-pinning policy was agreed in the orchestrator's own conversation, yet the subagents keep choosing versions that violate it. What is the cause, and the fix?
Build Exercise
Draw the Boundary Before You Build
What you'll learn
- How to place a task on the augmented LLM / workflow / agent taxonomy
- How to justify the placement from control-flow ownership and step predictability
- How to decompose an agent-shaped task into an orchestrator-workers design
- How to write a subagent delegation brief that survives context isolation
- Pick two real automation candidates from your own work: one whose steps are the same every run, and one where the path depends on what turns up
Why: The taxonomy only becomes a skill when applied to tasks whose shape you already know from experience.
You should see: Two one-line task descriptions, visibly different in predictability.
- Place each task on the taxonomy and write one sentence per placement naming the deciding property: who owns the control flow, and whether the step count is known in advance
Why: The exam tests the justification, not the label; a placement you cannot defend from the task profile is a guess.
You should see: Two placements, each with a one-sentence defence citing predictability or control-flow ownership.
- For the agent-shaped task, sketch an orchestrator-workers decomposition: list the subtasks, mark which are genuinely independent, and note which could run in parallel
Why: Parallelism only pays on independent subtasks, and spotting dependence before building avoids recreating the coordination problem at higher cost.
You should see: A subtask list with independence marked, and a parallel set identified (possibly empty).
- Write the full delegation brief for one subagent: objective, output format, tool guidance, task boundaries, and every convention the subagent must follow
Why: Subagents start with a fresh context window; the brief is the only channel through which facts reach them.
You should see: A brief a stranger could execute without asking you anything.
- Delete one necessary fact from the brief and predict the failure mode, then write the cost note: what does the extra spend of the agent tier buy on this task that a workflow could not deliver
Why: Predicting the failure makes the no-shared-memory constraint concrete, and the cost note is the discipline the exam rewards in every architecture item.
You should see: A named failure mode (duplicated work, a gap, or a wrong convention) and a one-sentence value justification for the agent tier.
Sources
- Building effective agents — Anthropic engineering, the canonical taxonomy and the simplest-solution rule
- How we built our multi-agent research system — Anthropic engineering, orchestrator-workers in production and its failure modes
- Subagents in the SDK — Claude Docs, context isolation mechanics and the delegation prompt as the only channel
- How the agent loop works — Claude Docs, the loop that agents run and workflows avoid
- Create custom subagents — Claude Docs, forks, fork mode defaults and named subagents that message each other
- Orchestrate teams of Claude Code sessions — Claude Docs, agent teams: experimental peer sessions that message each other directly
- Orchestrate subagents at scale with dynamic workflows — Claude Docs, a script that holds the plan and the intermediate results
- Multiagent orchestration — Claude Docs, Managed Agents coordinator rosters and one-level delegation