Agent design patterns

Most useful “agentic” systems are not mysterious autonomous minds. They are a handful of simple, composable patterns for arranging LLM calls, tools and code. Knowing these patterns by name helps you pick the least complicated design that solves your problem, and recognise when a flashier design is just adding cost.

Workflows versus agents

A helpful distinction, popularised by Anthropic’s December 2024 essay Building effective agents, separates two families:

• Workflows: your code decides the path. LLM calls and tools run along steps you defined in advance.
• Agents: the model decides the path. It chooses which tools to call, reads the results, and keeps going until it judges the task done.

Workflows are more predictable, cheaper and easier to test. Agents are more flexible but harder to control. Neither is “better”; they suit different problems.

Workflow patterns

Prompt chaining

Break a task into a fixed sequence of calls, each consuming the previous output. For example: draft an outline, check the outline meets requirements in code, then write the full text. Each step is easier than the whole task, so accuracy tends to rise, at the cost of extra latency. Simple checks between steps (“gates”) catch problems early.

Routing

A first step classifies the input and dispatches it to a specialised handler. Refund requests, bug reports and sales questions might each get their own prompt and tools. Routing is also a cost lever: send easy questions to a small, cheap model and hard ones to a stronger model. It works only if the classification itself is reliable.

Parallelisation

Run several calls at the same time, in one of two flavours:

• Sectioning: split the task into different independent parts, such as one call answering a user while another screens the request for policy problems.
• Voting: run the same task several times and aggregate, such as asking multiple reviewers whether code has a vulnerability and flagging it if any say yes.

Sectioning buys speed and focus; voting buys confidence. Both multiply token usage.

Orchestrator–workers

A central “orchestrator” model looks at the task, decides at run time what the subtasks are, hands them to worker calls, and combines the results. It resembles sectioning, but the subtasks are not known in advance. A coding change that touches an unpredictable set of files is a classic fit.

Evaluator–optimiser

One call generates, another evaluates against explicit criteria and gives feedback, and the generator revises. This loop helps when you can state what “good” looks like and when feedback actually leads to better revisions, as with translation nuance or search tasks needing several rounds. Without clear criteria, it simply burns tokens.

Agent patterns

Reason and act (ReAct)

The ReAct paper (Yao et al., 2022) showed the value of interleaving reasoning with actions. The loop is:

1. Think about what to do next.
2. Take an action, typically a tool call such as a search or a shell command.
3. Observe the result.
4. Repeat until finished.

Grounding each step in real observations reduces made-up facts and lets the agent change course. Nearly every modern tool-using agent is a descendant of this loop, even when the “thoughts” are hidden.

Reflection and self-critique

After an attempt, the agent reviews what happened and writes down lessons for the next try. Reflexion (Shinn et al., 2023) stored these verbal reflections in memory across trials and improved results on coding and decision-making tasks.

Be careful, though:

A model checking its own work can share the blind spots that produced the mistake.

Reflection is much more reliable when anchored to external signals such as failing tests, compiler errors or a separate checker, rather than the model’s opinion of itself.

Multi-agent setups

Several agents with different roles or instructions collaborate, often as a lead agent coordinating sub-agents. This can help when work genuinely splits into independent threads, like researching many sources in parallel, and it keeps each agent’s context focused. The costs are real: many more tokens, information lost in hand-offs, errors that compound between agents, and runs that are harder to debug. Giving agents human job titles does not by itself make a system smarter.

Choosing a pattern

The most durable advice is also the least exciting: start with the simplest thing that could work and add complexity only when measured results justify it.

A practical ladder:

1. A single, well-prompted call, perhaps with retrieval or examples.
2. A workflow (chain, router, parallel calls) if one call is not enough.
3. An evaluator loop if you have clear criteria and evidence it helps.
4. An autonomous agent only when steps cannot be predicted in advance, and when you have a way to check progress, such as tests or environment feedback.

At each rung, build a small evaluation set and compare. If the more complex design does not beat the simpler one on quality, cost or latency by enough to matter, keep the simpler one.

Common pitfalls

• Framework-first design. Heavy abstractions can hide the prompts and responses you need to see when something breaks. Understand the underlying calls first.
• Agent where a workflow would do. If you can write the steps down, you probably should.
• Unbounded loops. Every loop needs a stopping condition and a budget on steps or tokens.
• Poor tool descriptions. An agent is only as good as its understanding of its tools. Clear names, parameters and examples matter as much as the main prompt.

These patterns are building blocks, not rigid categories. Real systems mix them: a router in front of a chain, with an agent loop in one branch. The skill is in picking the fewest pieces that do the job reliably.