What you will be able to do
- Tell a workflow from an agent by asking who decides the next step: your code or the model
- Pick the lowest rung of the autonomy ladder that meets a requirement, and say what more autonomy costs
- Describe how an orchestrator (manager/supervisor) agent hands work to subagents and what comes back to it
- Name the three situations where subagents beat a single agent, and estimate their token and latency cost
Key concept
Ownership of the control flow — The line between a workflow and an agent is who decides the next step. In a workflow, code you wrote fixes the sequence of LLM calls and tool calls. In an agent, the model picks its own steps and tool calls at runtime.
1.Workflows and agents differ in who owns the control flow
Every system that puts an LLM to work with tools makes one architectural choice: who decides what happens next. Anthropic groups all of these systems under the name agentic systems and splits them into two kinds. A workflow runs LLMs and tools along code paths you defined in advance. An agent lets the LLM direct its own process and tool use, so the model stays in control of how the task gets done.
You can see the difference in the code. In a workflow, the order of steps is written in your program: call the model to draft, run a check, call it again to translate. If you read the code, you know every path the system can take. In an agent, your code runs a loop and the model makes the choices. On each turn Claude looks at where things stand and decides whether to answer, call a tool, or both. Tool results go back to the model, and the loop continues until Claude replies without asking for a tool. How the Claude Agent SDK runs that loop for you is covered in [the Agent SDK query() loop](lesson:1.2). What matters here is that neither the number of turns nor the order of the calls is in your code.
That one difference drives everything else. Because a workflow has fixed paths, it gives you predictability and consistency: you can test each path and know what it costs. An agent gives you flexibility for tasks whose steps can't be known in advance. Research is the standard example. The next search depends on what the last one found, and a linear, one-shot pipeline can't follow leads it didn't know would appear.
Checkpoint 1 of 8· Check yourself
A support system classifies each ticket and then sends it to one of three prompts. The classifier is an LLM call, and a Python if statement picks the next prompt from the classifier's label. How should this system be described?
The model fills in a value, but the set of paths and the order of the steps are fixed in code, so the system is a workflow. It would be an agent only if the model chose its own process and tool use.
“Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.”Source: www.anthropic.com
2.Start at the bottom of the autonomy ladder
The design rule is to build the simplest thing that works and add complexity only when a requirement forces it. Sometimes that means building no agentic system at all. For many applications, a single LLM call improved with retrieval and in-context examples is enough. Each added layer of autonomy costs latency and money in return for better task performance, so ask whether that trade is worth it before you climb.
Think of the options as rungs on a ladder. Each rung hands more of the control flow to the model. [The five workflow patterns (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer)](lesson:1.3) sit between a single call and a fully autonomous agent. Most of them keep the step sequence in your code. Orchestrator-workers is the rung where the model starts choosing the subtasks: they aren't defined in advance but decided by the orchestrator from the specific input.
| Rung | Who decides the steps | Enough when |
|---|---|---|
| Single LLM call with retrieval and in-context examples | Nobody: there is only one step | One well-prompted call meets the quality bar |
| Fixed workflow (prompt chaining, routing, parallelization) | Your code | The task splits cleanly into subtasks or categories known in advance |
| Orchestrator-workers | A central LLM picks the subtasks; your code runs the structure around it | You can't predict the subtasks, such as how many files a code change touches |
| Autonomous agent | The model, turn by turn | The task needs flexibility and model-driven decisions at scale |
Swapping a tested workflow for an agent changes more than quality. An agent keeps calling tools until it decides it is done, so you no longer set the turn count, the token bill or the response time in code. A workflow's fixed paths are also what made it easy to test. Frameworks add a separate risk on top: their layers of abstraction can hide the underlying prompts and responses, which makes debugging harder and makes it tempting to add complexity a simpler setup didn't need.
Checkpoint 2 of 8· Check yourself
A team's document pipeline drafts an outline, checks it against criteria, then writes the document. It meets its quality target, and the team now wants to replace it with an autonomous agent. What is the strongest argument against the change?
The rule is to add complexity only when needed. A workflow that already meets its target offers predictability and consistency, and agentic designs trade latency and cost for performance this task doesn't require.
“workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale.”Source: www.anthropic.com
Checkpoint 3 of 8· Exam question
A platform support team routes every incoming ticket into one of five known categories (billing, account access, bug report, feature request, or general inquiry). Once a ticket's category is identified, the exact sequence of downstream steps -- which system to query, what template to draft, and who to notify -- is fixed and never varies for that category. The team wants an architecture that keeps this dispatch-then-fixed-path behavior explicit and predictable. Which architecture should they implement?
Correct answer: B — Build a routing workflow that classifies each ticket into its category and then executes that category's predefined, fixed sequence of steps.
- A. Incorrect -- orchestrator-workers is for cases where subtasks aren't predefined; here the steps per category are already fixed, so a dynamically deciding orchestrator adds unneeded flexibility.
- B. Correct -- routing directs input to specialized, predefined downstream paths, matching the fixed-path-per-category requirement exactly.
- C. Incorrect -- a fully autonomous agent introduces unpredictable steps, which conflicts with the team's need for a fixed, predictable path per category.
- D. Incorrect -- running the same five steps for every category regardless of type skips the classification step entirely and can't represent different fixed paths per category.
3.Manager/supervisor hierarchies: an orchestrator and its subagents
A manager/supervisor hierarchy, usually called the orchestrator–subagent pattern, is a multi-agent system with a single top agent. A lead agent breaks the task into parts, starts specialized subagents for specific subtasks, and manages them. Each agent is a separate LLM instance with its own conversation context, and code coordinates them. Among the multi-agent coordination patterns, this one has the simplest coordination model, so it is the usual starting point.
The key structural fact is what goes up the hierarchy. A subagent runs in its own conversation. Its intermediate tool calls and results stay inside that conversation, and only its final message returns to the parent. A subagent that reads dozens of files sends back a short summary, not the files. The orchestrator therefore works from a compressed view of each subtask.
async def research_topic(query: str) -> dict:
# Lead agent breaks query into research facets
facets = await lead_agent.decompose_query(query)
# Spawn subagents to research each facet in parallel
tasks = [
research_subagent(facet)
for facet in facets
]
results = await asyncio.gather(*tasks)
# Lead agent synthesizes findings
return await lead_agent.synthesize(results)Anthropic's Research feature is a production example of this structure. A LeadResearcher plans the approach and saves the plan to memory, because anything past 200,000 tokens of context gets truncated. It then creates subagents with specific research tasks. Each subagent searches on its own and returns findings. The lead combines them and decides whether more research is needed. When it has enough, a separate CitationAgent attributes the claims to sources. With Claude Opus 4 as lead and Claude Sonnet 4 subagents, this setup outperformed single-agent Claude Opus 4 by 90.2% on an internal research eval.
Two structural choices shape how well a hierarchy performs. First, the Research lead runs subagents synchronously: it waits for each batch to finish before it continues. That keeps coordination simple, but one slow subagent can hold up the whole system. Second, passing every output back through the lead turns into a game of telephone. Subagents can instead write their work to external storage and return only a lightweight reference, which keeps detail intact and avoids copying large outputs through the conversation.
Checkpoint 4 of 8· Put it in order
Put the steps of the Research system's orchestrator loop in order.
- 1.The LeadResearcher thinks through the approach and saves its plan to memory
- 2.Each subagent searches on its own and returns findings
- 3.All findings go to a CitationAgent, which attributes the claims to sources
- 4.It creates subagents, each with a specific research task
- 5.The LeadResearcher combines the findings and decides whether more research is needed
The lead plans first, delegates, combines the results, and loops back if needed. Citation is a separate final step that runs after the research loop ends.
“The LeadResearcher synthesizes these results and decides whether more research is needed”Source: www.anthropic.com
Checkpoint 5 of 8· Exam question
A content team needs to produce localized marketing copy. Every request goes through the same three steps in the same order: draft the copy, run a fixed compliance check on the draft, then translate the approved draft into the target language. Each step consumes the previous step's output, and the sequence never changes. Which workflow pattern fits this process?
Correct answer: D — Prompt chaining, where each LLM call processes the fixed output of the step directly before it in an unchanging sequence.
- A. Incorrect -- the three steps always run in the same fixed order for every request, so there's no runtime decision for an orchestrator to make about which steps apply.
- B. Incorrect -- evaluator-optimizer implies an iterative critique-and-revise loop until criteria are satisfied, but this process is a single fixed pass through three steps, not a repeated refinement loop.
- C. Incorrect -- there's only one pipeline used for every request; routing would require multiple distinct pipelines chosen by classification, which isn't described here.
- D. Correct -- prompt chaining describes a fixed, unchanging sequence where each call processes the prior step's output, exactly matching draft, then check, then translate.
4.When subagents improve the result, and what they cost
Subagents improve a task in three situations. Outside them, coordination usually costs more than it returns. Teams have spent months building multi-agent systems only to find that better prompting on a single agent got the same results. A single agent with good tools can do more than most developers expect.
| Situation | What goes wrong with one agent | What the subagent provides |
|---|---|---|
| Context pollution | Output from one subtask, such as 2000+ tokens of order history, crowds out reasoning on the next | A clean, separate context that returns only a short summary |
| Parallel work | One agent searching step by step covers too little ground | Several subagents exploring separate parts of the question at the same time |
| Specialization | Too many tools (often 20+) across unrelated domains confuse tool selection | A focused toolset and system prompt for each responsibility |
Context isolation pays off most when a subtask produces a lot of output (more than 1000 tokens) and most of it doesn't matter to the main task. Lookups and retrieval that need filtering before use are typical examples. Specialization also works as a safety measure. In the Agent SDK, each subagent can have its own system prompt and a restricted tool list, so a reviewer given only read tools can analyze files but can't change them.
Checkpoint 6 of 8· Fill the gap
Which field limits this Agent SDK subagent to read-only tools?
// tools restricts what the subagent can do (read-only here)
? : ["Read", "Grep", "Glob"],
// model overrides the default model for this subagent
model: "sonnet"Inside an agent definition, tools is the list of tools that subagent may use. allowedTools is the top-level option that auto-approves tools for the whole query, and disallowedTools removes named tools rather than listing the allowed ones.
The cost is mainly tokens. For the same task, multi-agent systems typically use 3 to 10 times more tokens than a single agent. The extra comes from duplicating context in each agent, messages between agents, and summaries written for each handoff. Parallel subagents do finish in the time of the slowest one rather than the sum of all of them, but that only speeds up the multi-agent work itself. The real gain from parallelism is thoroughness, not speed. The money is worth spending only when the task is valuable enough to pay for the better result.
Some tasks resist this split. Work where every agent needs the same context, or where agents depend heavily on each other, is a poor fit, and most coding tasks have fewer truly parallel pieces than research does. Coordination also brings its own failures. Early versions of the Research system started 50 subagents for simple queries, and teams that split planning, execution and review into separate agents lost context at every handoff and spent more tokens coordinating than executing. Each extra agent is one more point of failure and one more prompt to maintain.
Checkpoint 7 of 8· Match them up
Match each symptom in a single-agent system to the subagent benefit that addresses it.
Tap a term, then the definition that fits it.
These are the three situations where multiple agents consistently outperform one: context pollution, parallelizable tasks, and tool or task specialization.
“when context pollution degrades performance, when tasks can run in parallel, and when specialization improves tool selection or task focus.”Source: claude.com
Checkpoint 8 of 8· Exam question
A security team reviews every pull request by running several independent prompts against the same diff at the same time -- one focused on injection vulnerabilities, one on authentication issues, one on dependency risks -- and then combines the separate flagged findings into one report. Which pattern is this?
Correct answer: A — Parallelization by sectioning, where independent subtasks examine the same input simultaneously and their separate results are aggregated.
- A. Correct -- sectioning splits the work into independent subtasks that run in parallel over the same input, with results aggregated afterward, matching the three simultaneous, differently-focused reviews.
- B. Incorrect -- voting runs the identical task multiple times for diverse outputs on the same question; here the three prompts each examine a different aspect, not the same question repeated.
- C. Incorrect -- evaluator-optimizer requires an iterative critique loop between two LLMs, but these three reviews run independently and simultaneously with no feedback loop between them.
- D. Incorrect -- the three review categories are fixed and predetermined, not dynamically chosen at runtime by a central orchestrating LLM.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Splitting work across parallel subagents makes the whole job finish faster than a single agent.Why is that wrong?
Parallelism buys coverage. A multi-agent system does so much more total work that it often takes longer overall than a single agent.
Covered in When subagents improve the result, and what they cost
2.The orchestrator sees every tool call and file a subagent worked through.Why is that wrong?
A subagent's intermediate work stays in its own conversation. The parent gets only the final message, usually a short summary.
Covered in Manager/supervisor hierarchies: an orchestrator and its subagents
3.Orchestrator-workers is just parallelization with an extra LLM on top.Why is that wrong?
The two look alike, but in orchestrator-workers the model decides the subtasks at runtime from the input. In parallelization the subtasks are fixed in advance.
Covered in Start at the bottom of the autonomy ladder
4.An autonomous agent is always the upgrade from a workflow.Why is that wrong?
Agentic systems trade latency and cost for performance. When the task is well defined, a workflow, or even one optimized call, is often the better design.
Covered in Start at the bottom of the autonomy ladder
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://code.claude.com/docs/en/agent-sdk/agent-loopOfficial docs
“Claude evaluates the current state and determines how to proceed.”
↩︎ Workflows and agents differ in who owns the control flow“Claude continues calling tools and processing results until it produces a response with no tool calls.”
↩︎ Start at the bottom of the autonomy ladder - 2.https://www.anthropic.com/engineering/building-effective-agentsSecondary source
“Workflows are systems where LLMs and tools are orchestrated through predefined code paths.”
↩︎ Workflows and agents differ in who owns the control flow“we recommend finding the simplest solution possible, and only increasing complexity when needed.”
↩︎ Start at the bottom of the autonomy ladder“Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense.”
↩︎ Start at the bottom of the autonomy ladder“Workflows are systems where LLMs and tools are orchestrated through predefined code paths.”
↩︎ Key concept“subtasks aren't pre-defined, but determined by the orchestrator based on the specific input.”
↩︎ Exam trap 3“For many applications, however, optimizing single LLM calls with retrieval and in-context examples is usually enough.”
↩︎ Exam trap 4“Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.”
↩︎ Checkpoint“workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale.”
↩︎ Checkpoint - 3.
“A linear, one-shot pipeline cannot handle these tasks.”
↩︎ Workflows and agents differ in who owns the control flow“outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval”
↩︎ Manager/supervisor hierarchies: an orchestrator and its subagents“Currently, our lead agents execute subagents synchronously, waiting for each set of subagents to complete before proceeding.”
↩︎ Manager/supervisor hierarchies: an orchestrator and its subagents“Subagents call tools to store their work in external systems, then pass lightweight references back to the coordinator.”
↩︎ Manager/supervisor hierarchies: an orchestrator and its subagents“require all agents to share the same context or involve many dependencies between agents are not a good fit”
↩︎ When subagents improve the result, and what they cost“Early agents made errors like spawning 50 subagents for simple queries”
↩︎ When subagents improve the result, and what they cost“The LeadResearcher synthesizes these results and decides whether more research is needed”
↩︎ Checkpoint - 4.https://code.claude.com/docs/en/agent-sdk/subagentsOfficial docs
“intermediate tool calls and results stay inside the subagent; only its final message returns to the parent.”
↩︎ Manager/supervisor hierarchies: an orchestrator and its subagents“independent subtasks finish in the time of the slowest one rather than the sum of all of them”
↩︎ When subagents improve the result, and what they cost“subagents can be limited to specific tools, reducing the risk of unintended actions.”
↩︎ When subagents improve the result, and what they cost“intermediate tool calls and results stay inside the subagent; only its final message returns to the parent.”
↩︎ Exam trap 2 - 5.
“a hierarchical model where a lead agent spawns and manages specialized subagents for specific subtasks.”
↩︎ Manager/supervisor hierarchies: an orchestrator and its subagents“multi-agent implementations typically use 3-10x more tokens than single-agent approaches for equivalent tasks.”
↩︎ When subagents improve the result, and what they cost“improved prompting on a single agent achieved equivalent results.”
↩︎ When subagents improve the result, and what they cost“subtasks generate high context volume (more than 1000 tokens) but most of that information is irrelevant to the main task”
↩︎ When subagents improve the result, and what they cost“they suffered from lost context at each handoff and spent more tokens coordinating than executing.”
↩︎ When subagents improve the result, and what they cost“The primary benefit of parallelization is thoroughness, not speed.”
↩︎ Exam trap 1“multi-agent systems often take longer overall than single-agent systems because of the sheer increase in total computation.”
↩︎ Prediction“when context pollution degrades performance, when tasks can run in parallel, and when specialization improves tool selection or task focus.”
↩︎ Checkpoint