What you will be able to do
- Tell a workflow from an agent by asking who controls the next step: your code or the model
- Decide whether a task needs an agentic system at all, and if so whether it needs a workflow or an agent
- Match prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer to the tasks each one fits
- Tell orchestrator-workers apart from parallelization, even though the two look the same on a diagram
Key concept
Workflow vs. agent — Both are agentic systems, and they differ in who controls the process. In a workflow, your code fixes the path the LLM and its tools follow. In an agent, the model decides its own steps and tool calls at runtime.
1.Workflows and agents are both agentic systems
Anthropic uses one umbrella term, agentic systems, for every LLM application that uses tools across several steps. It then draws a single architectural line through that group. In a workflow, your code owns the control flow: LLM calls and tool calls run along code paths you defined in advance. In an agent, the model owns the control flow: at runtime it decides which step comes next, which tool to call and when the task is finished. The line is about who decides. It is not about how many LLM calls there are or how clever the prompts are.
The decision criteria start one step earlier than 'workflow or agent'. First, find the simplest solution that works and add complexity only when it is needed. Sometimes that means building no agentic system at all: for many applications, a single LLM call with retrieval and in-context examples is enough. Agentic systems usually trade latency and cost for better task performance, so ask whether that trade is worth it for this particular task.
If it is worth it, the choice depends on how completely you can describe the task before it starts. Workflows give you predictability and consistency on well-defined tasks. Agents fit better when you need flexibility and model-driven decisions at scale. Open-ended research is the standard example: you cannot hard-code a fixed path, because each step depends on what the previous step found.
| Question | Workflow | Agent |
|---|---|---|
| Who controls the process? | Your code, through predefined code paths | The LLM, which directs its own process and tool usage |
| Best fit | Well-defined tasks that need predictability and consistency | Tasks that need flexibility and model-driven decision-making at scale |
| Typical example | Write an outline, check it against criteria, then write the document | Research in which the next search depends on what the last one found |
You can see the line in real code. In the Claude Agent SDK, each subagent definition has a description field, and a comment in the official example says the description tells Claude when to use that subagent. None of your code chooses the subagent: the model reads the descriptions and picks one, which is agent behaviour. Compare a router you wrote yourself that sends refund requests to one prompt and technical questions to another. That is workflow behaviour, even though every branch calls Claude.
2.The workflow patterns, from fixed to flexible
Every pattern is built from the same unit, the augmented LLM: a model with retrieval, tools and memory that can write its own search queries, choose tools and decide what information to keep. The patterns combine that unit in ways that give the model progressively more say over the path.
| Pattern | How it works | Use it when | Documented example |
|---|---|---|---|
| Prompt chaining | A sequence of steps, each LLM call processing the previous output, with optional programmatic gates | The task splits cleanly into fixed subtasks; you accept extra latency for higher accuracy | Generate marketing copy, then translate it |
| Routing | Classify the input and send it to a specialized follow-up task | Distinct categories are better handled separately and can be classified accurately | Easy questions to Claude Haiku 4.5, hard ones to Claude Sonnet 4.5 |
| Parallelization | Sectioning (independent subtasks) or voting (same task run several times), with outputs aggregated programmatically | You want speed, or several perspectives for higher confidence | One instance screens for inappropriate content while another answers |
| Orchestrator-workers | A central LLM breaks down the task, delegates to worker LLMs and synthesizes their results | You cannot predict the subtasks in advance | Coding changes that span multiple files |
| Evaluator-optimizer | One call generates a response and another evaluates it and gives feedback, in a loop | Evaluation criteria are clear and iterative refinement gives measurable value | Literary translation with an evaluator critiquing nuance |
A few details from the table decide many exam answers. Prompt chaining deliberately trades latency for accuracy by giving each call an easier job, and its gates are programmatic checks on intermediate output. Parallelization has two variants that are easy to mix up: sectioning splits the work into different independent subtasks, while voting runs the same task several times to get varied outputs. Splitting concerns across calls also improves quality, not only speed. When a task has several considerations, LLMs generally do better if each one gets its own call, which is why a separate guardrail call tends to beat one call that both screens and answers.
The fan-out-and-synthesize shape also appears in Anthropic's Managed Agents documentation, where parallelization is listed as a pattern that works well for multiagent coordination: independent subtasks run at the same time and a coordinator combines the results.
3.Orchestrator-workers: where workflows meet agents
On a diagram, orchestrator-workers looks just like parallelization: one node fans the work out, several nodes do it, and the results come back together. The difference is who defines the subtasks. In parallelization, your code fixes them before the input arrives. In orchestrator-workers, a central LLM breaks the task down as it goes, delegates the pieces to worker LLMs and synthesizes what they return, so the subtasks are chosen separately for each input.
You could not, and that is the textbook case. In coding, the number of files that need changing and the kind of change each one needs depend on the task itself. Search tasks that collect and analyze information from many sources have the same shape. If the subtasks cannot be known in advance, a fixed sectioning workflow has nothing to split, so the decomposition itself has to be a model decision.
This pattern is also where workflows and agents meet. An orchestrator that decides at runtime what to delegate is already using the model-driven control that defines an agent. Claude Managed Agents makes the runtime part explicit: a coordinator's session opens additional context-isolated threads only at the moment it delegates work.
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.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.An autonomous agent is always an upgrade over a fixed workflow, so a well-tested workflow should be replaced once the task gets complex.Why is that wrong?
Anthropic's advice is to use the simplest solution that works. Workflows give predictability and consistency on well-defined tasks. Agentic systems trade latency and cost for performance, and agents pay off only when flexibility is actually needed.
2.Orchestrator-workers is just parallelization with a different name, because both fan work out and combine the results.Why is that wrong?
The difference is flexibility. Parallelization runs subtasks that are defined in advance. In orchestrator-workers, the orchestrating LLM decides the subtasks for each input.
Covered in Orchestrator-workers: where workflows meet agents
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
“Workflows are systems where LLMs and tools are orchestrated through predefined code paths.”
↩︎ Workflows and agents are both agentic systems“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”
↩︎ Workflows and agents are both agentic systems“Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one.”
↩︎ The workflow patterns, from fixed to flexible“a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results”
↩︎ Orchestrator-workers: where workflows meet agents“Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.”
↩︎ Key concept“we recommend finding the simplest solution possible, and only increasing complexity when needed”
↩︎ Exam trap 1“subtasks aren't pre-defined, but determined by the orchestrator based on the specific input”
↩︎ Exam trap 2 - 2.
“You can’t hardcode a fixed path for exploring complex topics, as the process is inherently dynamic and path-dependent.”
↩︎ Workflows and agents are both agentic systems - 3.https://code.claude.com/docs/en/agent-sdk/subagentsOfficial docs
“description tells Claude when to use this subagent”
↩︎ Workflows and agents are both agentic systems - 4.
“Fan out independent subtasks simultaneously (searching multiple sources, analyzing separate files) and have the coordinator synthesize the results.”
↩︎ The workflow patterns, from fixed to flexible“additional threads are spawned at runtime when the coordinator delegates work”
↩︎ Orchestrator-workers: where workflows meet agents