Workflow or agent? 5 patterns from Anthropic for picking the right architecture

“Agent” is the hottest word in AI right now — so hot that many teams start every project with “let’s build an agent”. Anthropic’s “Building effective agents” (Erik Schluntz and Barry Zhang, December 2024), distilled from dozens of real deployments, gives the opposite advice: most successful systems use simple, composable patterns, not complex frameworks. This article summarises the workflow/agent distinction and the five foundational patterns.

Workflows vs agents

Both are built on the same basic block: the “augmented LLM” — an LLM enhanced with retrieval, tools and memory.

The 5 workflow patterns

1. Prompt chaining

Break the task into a fixed sequence; each step’s output feeds the next, optionally with programmatic “gates” between steps.

• Use when: the task splits cleanly into steps and you’ll trade latency for accuracy.
• Example: write an outline → check it meets criteria → write the article from it → translate.

2. Routing

Classify the input and send it to a specialised branch with its own prompt/tools.

• Use when: inputs fall into distinct categories and classification is reliable.
• Example: support tickets → technical / billing / feedback; easy questions → a small model, hard ones → a large model.

3. Parallelization

Two variants: sectioning (split into independent parts run in parallel) and voting (run the same task several times for consensus or confidence).

• Use when: parts are independent, you need multiple perspectives, or speed matters.
• Example: reviewing code against three criteria at once; one stream answers the user while another screens content; three vulnerability reviews with a majority vote.

4. Orchestrator-workers

A central LLM analyses the task, decides dynamically how to split it, delegates to workers and synthesises the results.

• Use when: subtasks can’t be predicted up front.
• Example: code changes across files you can’t list in advance; research gathering from many sources.

5. Evaluator-optimizer

One LLM generates, another evaluates and gives feedback, in a loop until it passes.

• Use when: there are clear evaluation criteria and iteration measurably improves results.
• Example: nuanced translation; rewriting to satisfy a checklist; complex searches needing several rounds.

When do you actually need an agent?

• Open-ended problems where the number of steps can’t be predicted (debugging, research, coding).
• Environments with clear feedback for self-checking — test pass/fail, tool results, compile errors.
• You accept higher cost and have guardrails: iteration limits, sandboxing, checkpoints for human approval.

The article highlights two areas that suit agents well: customer support (conversation plus actions via tools, with clear success criteria) and coding agents (results verifiable with automated tests).

Three principles for building agents

1. Simplicity: keep the design minimal; frameworks help you start fast but can hide the underlying prompts and responses, making debugging harder. If you use one, understand the code underneath.
2. Transparency: show the agent’s planning steps.
3. A carefully crafted agent–computer interface (ACI): invest in tool descriptions, documentation and testing as you would in a user interface — clear names, examples, edge cases, parameter formats that are easy for the model.

Choosing an architecture: a quick decision tree

Is one good LLM call (plus retrieval + examples) enough?   → Stop there.
Fixed, known steps?                                         → Prompt chaining.
Inputs fall into clear categories?                          → Routing.
Independent parts / multiple perspectives needed?           → Parallelization.
Subtasks unknown in advance?                                → Orchestrator-workers.
Clear grading criteria, several rounds of refinement?       → Evaluator-optimizer.
Open-ended, self-checkable feedback, cost acceptable?       → Agent (with guardrails).

How to apply it

• Developers: Before writing an agent, try solving the problem with one or two workflow patterns. Move to an agent only when you can show the workflow isn’t enough.
• Tech Leads: Use the five patterns as shared vocabulary in design reviews: “this part is routing, that part is evaluator-optimizer” gets everyone aligned fast.
• PMs: When the team proposes “an agent”, ask: “could a fixed workflow handle 80% of cases?” Workflows are cheaper and their cost and timeline are easier to forecast.