1.1 Workflow vs. Agent: The Core Architectural Decision
1.1.1 Two Shapes of Control Flow
Every system you build with Claude ultimately reduces to one design question, asked before anything else: who decides what happens next -- your code, or the model? Anthropic draws a sharp, deliberate line here. A workflow is a system where LLMs and tools are orchestrated through predefined code paths: you, the developer, wrote down the sequence of steps in advance, and the model fills in content within a shape you already fixed. An agent is a system where the LLM dynamically directs its own steps and tool use: nobody wrote the sequence in advance, because the right next step depends on what the model discovers along the way.
This isn't a stylistic preference -- it changes the properties you get for free. A workflow is deterministic in its control flow, so it's predictable and easy to test: the same input walks the same code path every time, even if the text the model generates at each step varies. An agent's path varies run to run, which is exactly what makes it able to handle a task whose steps can't be enumerated ahead of time -- and exactly what makes it harder to test, harder to bound in cost, and harder to bound in latency.
The dividing line is who decides what happens next: fixed code (workflow) or the model itself (agent). Everything else -- predictability, cost, latency -- follows from that one choice.
The one idea to hold onto
Workflow = predefined code paths orchestrate the LLM. Agent = the LLM dynamically directs its own steps and tool use. Every other property in this lesson -- predictability, cost, latency, testability -- is a consequence of that one distinction, not a separate fact to memorize.
1.1.2 The Augmented LLM: the Building Block Underneath Both
Strip away the orchestration language from either a workflow or an agent and you find the same atomic unit underneath: the augmented LLM, a model enhanced with retrieval, tools, and memory. Retrieval means the call can ground itself in context pulled from outside the model's training data -- a knowledge base, a document store. Tools mean the call can take real actions or look up real information rather than only generating text. Memory means relevant state can be carried across turns or sessions instead of starting cold every time.
A workflow is simply several augmented LLM calls wired together in a fixed order that you designed. An agent is an augmented LLM that has been handed control over its own looping and tool-selection decisions instead of being driven by your predefined code. Neither pattern introduces a new primitive -- they're both compositions of the same building block, just with a different party holding the steering wheel.
1.1.2 -- Key Concept
The augmented LLM (model + retrieval + tools + memory) is the atomic unit of every Claude system. A workflow is a fixed composition of augmented LLM calls you designed; an agent is an augmented LLM given control over its own sequencing. Understanding this one unit well makes both patterns feel like variations, not mysteries.
1.1.3 The Agent Loop: Plan, Act, Observe, Repeat
An agent proper runs an open-ended loop: it plans its next move, calls a tool, observes the result -- real ground truth from the environment, not just its own prior text -- and repeats, until it decides the task is done or a stopping condition is hit. That grounding step matters more than it sounds: the agent isn't reasoning in a vacuum across turns, it's reasoning against what the environment actually returned, which is what lets it correct course when its first plan turns out to be wrong.
# The shape of the agent loop, at the level every implementation shares
while not done:
next_step = model.plan(conversation_so_far) # model decides, not your code
result = environment.execute(next_step) # a tool call, a lookup, a real action
conversation_so_far.append(result) # ground truth feeds back in
done = model.decides_task_is_complete_or_stopped()This is also where the tradeoff Anthropic is explicit about becomes concrete: an agent can keep looping for as many steps as the task turns out to need, which buys it the ability to handle genuinely open-ended work -- but every extra step is another model call, which is more latency and more cost, and a variable number of steps means you can no longer promise a bound on either one in advance.
1.1.3 -- Exam Trap
Exam trap: "agents are always better than workflows." They aren't -- Anthropic's own guidance is to find the simplest solution possible, and only increase complexity when needed. An agent adds latency, cost, and unpredictability; that tradeoff has to earn its place against a genuine need for open-ended, unpredictable steps, not get chosen by default.
1.1.4 The Five Workflow Composition Patterns
Workflows aren't one technique, they're a family of five named compositions, and matching a described task to the right one is squarely what gets tested. All five keep the code path fixed -- only the content generated inside each step is dynamic.
| Pattern | Structure | Fits when |
|---|---|---|
| Prompt chaining | A fixed sequence of steps, each an LLM call on the previous output, optionally with programmatic gate checks between steps | Steps genuinely depend on each other in a known order |
| Routing | Classify the input, then direct it to a specialized follow-up prompt or model | Inputs fall into distinct categories needing different handling |
| Parallelization -- sectioning | Split into independent subtasks known in advance, run them concurrently | Subtasks don't depend on each other and the split is already known |
| Parallelization -- voting | Run the same task multiple times and aggregate or vote on the results | A task benefits from redundancy or consensus across independent attempts |
| Orchestrator-workers | A central LLM dynamically breaks a task into subtasks at runtime and delegates to worker LLMs | The subtask breakdown can't be fully known in advance -- this is where a workflow starts to shade into an agent |
| Evaluator-optimizer | One LLM generates a result, another critiques it, and it's sent back to improve | A generate-then-critique loop measurably improves quality |
Six rows, five named patterns (parallelization splits into two variants). Memorize the discriminator for each, not just the label.
Notice that orchestrator-workers is listed as a workflow even though its defining feature -- a central LLM deciding the subtasks at runtime -- sounds agent-like. That's deliberate, and it's exactly the seam the next note is about.
1.1.5 The Trap: Orchestrator-Workers vs. Sectioning vs. a True Agent
Two patterns get confused constantly, and the confusion is really the same question asked twice: who decides the subtasks, and when? In parallelization sectioning, the developer decides the split at design time -- the subtasks are known in advance and simply run concurrently. In orchestrator-workers, a central LLM decides the subtask breakdown at runtime, but it still does so inside a fixed manager/worker shape that the developer designed. In a true agent, there is no larger predetermined shape at all -- the model decides its own next action, tool by tool, with no script constraining what happens next.
The dividing line moves in one direction across these three: from fully developer-decided, to runtime-decided-but-still-shaped, to no shape at all.
1.1.5 -- Exam Trap
Exam trap: confusing orchestrator-workers with sectioning, and confusing orchestrator-workers with a true agent. Sectioning's split is known in advance; orchestrator-workers decides at runtime but inside a fixed shape; a true agent has no predetermined shape at all. The discriminator every time is who decides the subtasks, and when.
1.1.6 Choosing the Simplest Sufficient Composition
Anthropic's guidance closes the loop on this whole lesson with a single instruction: find the simplest solution possible, and only increase complexity when needed. That's not a soft suggestion -- it's the deciding rule for every scenario question in this task statement. A task with fixed, known steps should be a prompt chain, not an agent. A task with distinct input categories should be routing, not an orchestrator. Complexity is a cost you pay in latency, spend, and unpredictability, and it has to be justified by something in the task itself, not by what sounds more sophisticated.
- 1.Can the steps be fully enumerated in advance? If yes, it's a workflow -- identify which of the five compositions fits the task's shape.
- 2.Are the steps fixed and sequential, each depending on the last? Prompt chaining.
- 3.Do inputs fall into distinct categories needing different handling? Routing.
- 4.Are the subtasks independent and already known? Parallelization -- sectioning (or voting, if the goal is consensus across repeated attempts).
- 5.Can the subtask breakdown only be decided once you see the input, but the overall manager/worker shape is still fixed? Orchestrator-workers.
- 6.Can the steps genuinely not be enumerated in advance at all, because each one depends on what the last one revealed? Only then does a full agent loop earn its cost.
Where this shows up on the exam
1.1 questions describe a task and ask which architecture fits. Before looking at the options, ask yourself: are the steps knowable in advance? Is there a fixed shape, even if the content inside it is runtime-decided? That question alone eliminates most of the wrong answers.
Key Takeaways
- ✓A workflow orchestrates LLM calls through predefined code paths; an agent lets the LLM direct its own steps and tool use dynamically -- every other property follows from this one distinction.
- ✓Both are built on the augmented LLM (model + retrieval + tools + memory), the atomic unit that workflows compose in a fixed order and agents are given control over sequencing.
- ✓An agent loop plans, acts, observes real environment feedback, and repeats until done or stopped -- more steps buys open-ended capability at the cost of more latency and money.
- ✓The five workflow compositions are prompt chaining, routing, parallelization (sectioning and voting), orchestrator-workers, and evaluator-optimizer -- each fits a distinct task shape.
- ✓The critical discriminator between sectioning, orchestrator-workers, and a true agent is who decides the subtasks and when: design-time, runtime-within-a-fixed-shape, or no shape at all.
- ✓Anthropic's explicit guidance: find the simplest solution first, and add agentic autonomy only when the task genuinely benefits from it -- "agents beat workflows" is a common exam trap, not a rule.
Check Your Understanding
Test what you learned in this lesson.
Q1.A task has three fixed steps that always run in the same order, each transforming the previous output. Which architecture fits best?
Q2.What is the precise distinction between orchestrator-workers and parallelization sectioning?
Q3.According to Anthropic's guidance, when should agentic autonomy be added to a design?
Q4.A team needs to investigate an unfamiliar production incident where the root cause and the steps to find it are unknown in advance. Why is a true agent the right call rather than orchestrator-workers?
Practice This Lesson