What you will be able to do
- Choose between prompt chaining, routing and parallelization for a task with a fixed code path
- Explain how orchestrator-workers differs from parallelization and when task decomposition should be left to the model
- Describe how Managed Agents multiagent sessions isolate context and combine results
- Justify an architecture choice in terms of cost, latency, quality and time-to-market
1.Fixed-path workflows: chaining, routing, parallelization
When a task's structure is known in advance, you can code the processing stage as a workflow. In this pattern the code path is fixed, and Claude does the work at each step. Three workflow patterns cover most designs. Each one trades something different.
Prompt chaining splits a task into a sequence of steps, and each LLM call processes the output of the one before it. You can add programmatic checks, called gates, between steps to confirm the process is still on track. The trade is explicit: chaining accepts extra latency in return for accuracy, because each call has an easier job. Generating an outline, checking it against criteria and then writing the document is a typical chain.
Routing classifies an input and sends it to a specialized follow-up task. This keeps concerns separate. Otherwise, tuning a prompt for one kind of input can make it worse at others. Routing also controls cost: easy or common questions can go to a smaller model such as Claude Haiku 4.5, and hard or unusual ones to a more capable model. The routing decision itself is structured output. A tool schema enforces its shape, so you never have to parse it out of prose.
Parallelization runs LLM calls at the same time and combines their outputs in code. Sectioning splits a task into independent subtasks, which saves time and gives each concern its own focused call. Voting runs the same task several times, which raises confidence. An example is several prompts each reviewing the same code for vulnerabilities.
| Pattern | Use when | Main trade |
|---|---|---|
| Prompt chaining | Task decomposes cleanly into fixed subtasks | More latency for higher accuracy |
| Routing | Distinct input categories, and classification can be done accurately | Specialized prompts; cheap models for easy inputs |
| Parallelization: sectioning | Independent subtasks | Speed, and focused attention per aspect |
| Parallelization: voting | Multiple attempts needed for confidence | More calls for higher-confidence results |
Checkpoint 1 of 4· Match them up
Match each workflow pattern to what it does.
Tap a term, then the definition that fits it.
The definitions come straight from the patterns section. Sectioning and voting are the two forms of parallelization.
“Routing classifies an input and directs it to a specialized followup task.”Source: www.anthropic.com
2.Orchestrator-workers and multi-agent coordination
Fixed paths stop working when you cannot predict the subtasks. In a coding change, for example, the number of files to edit depends on the request. In orchestrator-workers, a central LLM breaks the task down at runtime, hands the pieces to worker LLMs and combines their results. It looks like parallelization, but the key difference is that the orchestrator chooses the subtasks for each specific input. In this pattern, task decomposition is a decision the model makes, not one you code.
Anthropic's research system uses this pattern. A lead agent analyzes the user's query, develops a strategy and spawns subagents to explore different aspects at the same time. The subagents act as intelligent filters: they repeatedly use search tools to gather information, and the lead agent combines what they return.
Claude Managed Agents supports this in a single session. One coordinator delegates work, and each agent it calls runs in its own session thread, a context-isolated event stream with its own conversation history. All agents share the sandbox, the filesystem and the vault credentials. They do not share tools, MCP servers or context, and each agent keeps its own model and system prompt. Threads persist, so the coordinator can send a follow-up to an agent it called earlier, and that agent remembers its earlier turns. The pattern the documentation recommends is to fan out independent subtasks and have the coordinator combine the results.
Checkpoint 2 of 4· Check yourself
In a Managed Agents multiagent session, which statement about the agents the coordinator calls is correct?
The sandbox, filesystem and vault credentials are shared. Each agent runs in its own context-isolated thread with its own configuration, and tools, MCP servers and context are not shared.
“All agents share the same sandbox, filesystem, and vault credentials, but each agent runs in its own session thread”Source: platform.claude.com
Checkpoint 3 of 4· Exam question
A production agent built with the Claude Agent SDK runs multi-hour autonomous coding sessions. The architecture needs a feedback loop that automatically writes an audit-log entry to disk every time the agent edits or writes a file, without the model having to be asked to do this in every prompt. Which mechanism should the architect use?
Correct answer: A — Register a PostToolUse hook matched to the Edit and Write tools that runs a callback to append an audit entry after each call
- A. Correct. Agent SDK hooks such as PostToolUse run deterministic callback code at a defined point in the agent lifecycle, and matching on Edit and Write is the documented way to log file changes automatically without relying on the model to remember.
- B. Incorrect. Relying on a prompt instruction is not deterministic; the model could omit the step under context pressure, so it doesn't guarantee the audit log is written every time.
- C. Incorrect. External polling and diffing is a workaround that duplicates functionality hooks already provide, adds latency, and can miss or misattribute rapid changes.
- D. Incorrect. Requiring manual confirmation on every edit breaks the autonomous, multi-hour operation the scenario describes and is not what audit logging requires.
3.Mapping architecture choices to cost, latency, quality and time-to-market
Each step up in complexity has to pay for itself. Multi-agent designs show this most clearly. Anthropic's data shows agents using about 4× the tokens of a chat interaction, and multi-agent systems about 15×. That is worth paying only when the task's value is high enough. In return, isolated parallel contexts can improve output quality and shorten time to completion. Multi-agent systems do best on valuable tasks that need heavy parallelization, involve more information than one context window holds, or use many complex tools.
The fit is poor when every agent needs the same context or the agents depend on each other heavily. Most coding tasks have fewer truly parallel pieces than research does. And today's LLM agents are not yet good at coordinating and delegating to each other in real time.
Time-to-market depends on what you build versus what you adopt. The Messages API gives you direct model access, which suits custom agent loops and fine-grained control. You build the loop, the tool execution and the runtime. Claude Managed Agents provides a ready-made harness on managed infrastructure. It suits long-running, asynchronous work, and you do not have to build your own agent loop, sandbox or tool-execution layer.
| Decision | Lever it moves | Source of the trade |
|---|---|---|
| Prompt chaining | Accuracy up, latency up | Each LLM call gets an easier task |
| Routing easy queries to Claude Haiku 4.5 | Cost down | Smaller, cost-efficient model for common questions |
| Parallel isolated subagents | Quality and time to completion up; tokens up (~15× chat) | Separate contexts working at the same time |
| Claude Managed Agents instead of a custom loop | Time-to-market down | No agent loop, sandbox or tool execution layer to build |
Checkpoint 4 of 4· Check yourself
A team proposes a multi-agent design for a coding assistant whose subtasks all need the same shared context and depend heavily on each other. What is the best architectural response?
Anthropic names shared context and many inter-agent dependencies as poor fits for multi-agent systems, and those systems also cost about 15× a chat in tokens.
“some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit”Source: www.anthropic.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Orchestrator-workers is just parallelization under another name, because both fan work out to several LLM calls.Why is that wrong?
They look alike, but in parallelization the subtasks are defined in advance. In orchestrator-workers, the orchestrator decides the subtasks at runtime from the specific input.
Covered in Orchestrator-workers and multi-agent coordination
2.A multi-agent architecture is the safe default for any complex task, because more agents means better results.Why is that wrong?
Multi-agent systems use far more tokens and only pay off when the task's value covers that cost. They also fit poorly when agents share context or depend on each other.
Covered in Mapping architecture choices to cost, latency, quality and time-to-market
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://www.anthropic.com/engineering/building-effective-agentsSecondary source
“Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one.”
↩︎ Fixed-path workflows: chaining, routing, parallelization“The main goal is to trade off latency for higher accuracy, by making each LLM call an easier task.”
↩︎ Fixed-path workflows: chaining, routing, parallelization“Without this workflow, optimizing for one kind of input can hurt performance on other inputs.”
↩︎ Fixed-path workflows: chaining, routing, parallelization“In the orchestrator-workers workflow, a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results.”
↩︎ Orchestrator-workers and multi-agent coordination“subtasks aren't pre-defined, but determined by the orchestrator based on the specific input.”
↩︎ Exam trap 1“This tends to perform better than having the same LLM call handle both guardrails and the core response.”
↩︎ Prediction“Routing classifies an input and directs it to a specialized followup task.”
↩︎ Checkpoint - 2.
“a tool schema enforces the shape.”
↩︎ Fixed-path workflows: chaining, routing, parallelization - 3.
“the lead agent analyzes it, develops a strategy, and spawns subagents to explore different aspects simultaneously”
↩︎ Orchestrator-workers and multi-agent coordination“multi-agent systems use about 15× more tokens than chats”
↩︎ Mapping architecture choices to cost, latency, quality and time-to-market“multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance”
↩︎ Exam trap 2“some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit”
↩︎ Checkpoint - 4.
“Tools, MCP servers, and context are not shared.”
↩︎ Orchestrator-workers and multi-agent coordination“Fan out independent subtasks simultaneously (searching multiple sources, analyzing separate files) and have the coordinator synthesize the results.”
↩︎ Orchestrator-workers and multi-agent coordination“which helps improve output quality and can also improve time to completion”
↩︎ Mapping architecture choices to cost, latency, quality and time-to-market“All agents share the same sandbox, filesystem, and vault credentials, but each agent runs in its own session thread”
↩︎ Checkpoint - 5.
“Minimal infrastructure: No need to build your own agent loop, sandbox, or tool execution layer”
↩︎ Mapping architecture choices to cost, latency, quality and time-to-market