The developer's guide to choosing agentic design patterns

Agentic design patterns are common, reusable architectural patterns that you can apply when building agentic workflows. There are different patterns that suit different use cases. Andrew Ng popularized this term with his original four patterns, but since then, many more patterns have been devised, with new and overlapping concepts. 

This post explains the agentic design patterns that enterprise teams actually need to know about, helping you understand what makes them different and how you can apply them.

Andrew Ng's four agentic design patterns

Andrew Ng's four agentic design patterns popularized the idea of bringing software design patterns to agentic workflows, and they are seminal in the field.

These four foundational patterns are:

• Reflection: An agent critiques the output of another agent or itself.

• Tool use: Allows agents to take actions in external software systems outside of the LLM.

• Planning: Involves an agent planning all its tasks up front before executing them.

• Multi-agent collaboration: Involves multiple agents working together.

Ng's four patterns laid the groundwork for future patterns, and in some cases, they're now regarded as baseline capabilities. For example, tool use has become so fundamental that it's now hard to think of an AI agent that doesn't have it. 

Why the list keeps growing

Researchers have continued to name new agentic design patterns. Some of these are entirely new techniques, and some are variations of existing ones. Either way, once these get implemented by the different agentic AI frameworks (like LangChain, CrewAI, and AutoGen), they may have slightly different implementations or different names, which can make it hard to understand their differences and which ones you actually need.

This article wades through the noise, pulling out the key agentic AI design patterns into a clear, practical set.

The different types of agentic design patterns

There are different patterns for how an individual agent reasons and for how multi-agent systems coordinate. They can be broadly categorized as reasoning patterns, which are how each individual agent thinks internally, and coordination patterns, which are how multiple agents work together in a multi-agent system. 

Understanding which category a pattern belongs to allows you to understand whether it's suitable for solving problems with a single agent or getting multiple agents to work together effectively.

Reasoning patterns explained

Reasoning patterns are about how an individual agent reasons, and they're relevant whether that agent is acting alone or within a multi-agent system. 

The bulk of agentic reasoning happens as a loop, and the two most common loops to choose between are ReWOO and ReAct, though variations like the Ralph loop are also becoming more common. Reflection is another reasoning pattern that is typically added to the end of one of these loops.

ReWOO

The ReWOO (Reasoning Without Observation) pattern can be thought of as a more specific implementation of Andrew Ng's planning pattern. In ReWOO, there are three roles that must each be called in order: 

• Planner: Generates a step-by-step plan for solving the query.

• Worker: Runs each step of the plan in sequence, calling tools or LLMs if needed.

• Solver: Takes all the evidence gathered from the outcome of each step and uses this to generate a single response.

You don't necessarily need a separate agent for each role — this pattern can be used with a single agent.

To understand ReWOO, let's take an example of a customer account support agent. A user sends the following query to an AI system: "Can I get a refund for last month? I was billed for the analytics package, but it was broken every time I tried to use it." This triggers the ReWOO pipeline.

First, the pipeline calls the Planner, which might have the following instruction built into it: "Take this question and write out the full plan for answering it as a series of steps before executing anything. Each step should say what to do and can reference the result of a previous step by using a placeholder variable (e.g., #E1, #E2, #E3)." The Planner then generates the plan, which, for this example, might look something like this:

Copy to clipboard

Once the plan is generated, the series of steps is sent to the Worker, which runs each step sequentially. The Worker may call external tools, like in #E1 and #E2, or it may call an LLM, like in #E3. Each Worker step generates a piece of evidence, labeled as #E1, #E2, #E3, and so on. 

Finally, when all the steps have been run and all the evidence gathered, the Solver is called. The Solver might be instructed: "You have the customer's original question and all the evidence gathered while answering it as #E1, #E2, #E3, etc. Write a clear response to the customer, using only this evidence. Don't include any information that's not present in the evidence provided."

ReAct

Another common reasoning loop, ReAct (short for Reason and Act), allows an agent to be more adaptive. This loop follows a simple cycle: think, act, observe, repeat. This is useful for dealing with more open-ended questions, like "My scheduled content is no longer publishing automatically. Can you fix this?" 

ReWOO is less suitable for this type of question, as there are many possible reasons why a publishing process could be broken, and trying to plan the whole investigation up front isn't practical. It's much more effective in this case for the agent to think about what to check first, take that action, observe the result of that action (i.e., find out why the system is broken), then decide what to do next and take an action to fix it.

The Ralph loop

Another related pattern to ReAct is the Ralph loop, which has become popular with developers who use coding agents. The Ralph loop is a way to avoid the cost and quality degradation that happens when the context length of a conversation becomes too long over one continuous ReAct session. This is done by externalizing information needed to carry progress forward into files instead of the agent's own memory. It's named after The Simpsons' Ralph Wiggum, who is known for being obliging but simple-minded. 

Each cycle around the Ralph loop consists of a fresh, "dumb" agent with no memory of what came before. Any necessary information is fed to each agent at the start of a cycle from external files, which is what allows this approach to work surprisingly well over many cycles.

With Ralph, you can begin with an external list of tasks that need to be completed in a file like fix_plan.md:

Copy to clipboard

The Ralph loop is then initiated by wrapping a single agent invocation in a bash loop:

while :; do cat PROMPT.md | claude-code; done

PROMPT.md contains the prompt that tells the agent what to do, for example:

Copy to clipboard

Reflection

Reflection, one of Andrew Ng's four patterns, isn't a reasoning loop on its own: It's used as an addition to your existing reasoning loop, like ReWOO or ReAct. 

Reflection adds an extra step after the agent has generated its LLM output, where the output is critiqued and, if necessary, revised. Within a single agent, this can just be another LLM call or two.

Multi-agent coordination patterns

These patterns give you different options for how agents can work together in a multi-agent system. They focus specifically on the coordination between agents, not on how each agent itself reasons — you will still need to choose a reasoning pattern for that.

1. Sequential pattern

The sequential pattern works like a pipeline, where each agent completes all its actions before another is called. You'll need this when the input of one agent depends on the output of another.

2. Parallel pattern 

This is when multiple agents work in parallel to solve different aspects of the same overall task. Running agents in parallel is much faster than the sequential pattern, so it's worth doing if one agent doesn't depend on another.

3. Loop pattern

With the loop pattern, you run a sequence of agents like in the sequential pattern, but with a difference: At the end of the sequence, you run a check to see if a termination condition has been met. If not, you repeat the same sequence, and you keep doing this until the condition is met.

4. Single orchestrator pattern 

This involves having an additional agent whose role is to coordinate the others. This extra agent is the orchestrator agent. 

Unlike the previously mentioned multi-agent patterns, the orchestrator pattern takes the responsibility of routing to the different agents away from your code and hands it to the orchestrator agent, which dynamically decides which of the other agents to call and in what order. 

To understand how this pattern gives routing responsibility to the orchestrator agent, let's compare a Python/LangChain code snippet for the orchestrator pattern against a non-orchestrator pattern — the sequential pattern — for the following example:

Imagine a customer support system with three different agents that get asked questions about different topics, such as technical support, billing, and shipping. 

The code for the sequential pattern is shown below. Your code is responsible for calling each agent in sequence.

Copy to clipboard

By contrast, with the orchestrator pattern, you only need to call the orchestrator agent. You don't need to do anything else, as the orchestrator handles the routing by deciding itself which agents should be called and in which order. The code for the orchestrator pattern is shown below:

Copy to clipboard

5. Hierarchical orchestration 

Similar to the orchestrator pattern, this requires delegation. The difference is that there are many layers of delegation with this pattern. One top-level agent delegates to its sub-agents, but then each of these sub-agents itself acts as an orchestrator, delegating to agents below it. This pattern becomes useful once your system has too many agents for a single orchestrator agent to reliably coordinate.

6. Swarm pattern 

This is a decentralized pattern where the agents work directly with each other with no centralized orchestrator. Instead, the agents must decide together when a task is done and which agent to send the next task to. 

This is generally not used in production enterprise contexts due to unpredictability, the possibility of very high costs, and the difficulty of debugging such systems. At the moment, it remains more of an interesting research problem when working out whether it would be possible for agents to completely coordinate themselves.

Combining agentic design patterns

It's worth noting that almost any of these patterns can be combined, and they regularly are. The single orchestrator pattern, for example, tends to be paired with either the sequential, parallel, or loop patterns. Reflection is also commonly added to many patterns.

How to choose the right agentic design patterns for your use case

You will need to make choices about how each agent reasons and how they coordinate in groups. This will depend on how predictable the task is, how much priority you want to give to quality over cost and speed, and how many agents you need to be involved.

Choosing between reasoning patterns

ReWOO vs. ReAct 

ReWOO is generally simpler than ReAct, which makes it easier to debug. It's also usually cheaper and has lower latency due to fewer overall LLM calls. But if you need your system to adapt to the outcomes of previous steps, ReAct is what you need.

This adaptability is also what gives ReAct a better error tolerance, as it can more easily handle when an LLM returns something unexpected by adapting. Longer-running ReAct sessions are where you really start to see affordability and quality degrade. However, you can try using the Ralph loop instead, as this resets the agent each cycle, meaning the context window can't keep growing.

When to add reflection 

Whichever loop you use, you can add reflection to it. If output quality is more important than speed and cost, and if you think it will be fairly easy to define what the critiquing agent should do, you should use reflection.

Reflection is typically used for generation-heavy tasks, like those where the output is long prose or code generation. It tends to be used less for simple actions that don't involve much generation.

Choosing between multi-agent coordination patterns

Sequential vs. parallel vs. loop pattern 

These patterns must be coordinated by you in your own code. It's fairly straightforward to understand when you'll need the sequential pattern — when one agent's output is needed before another can start its own task. If you don't need that, it's more efficient to use the parallel pattern. However, it's quite common to combine both when some tasks depend on others, but the rest can run at the same time. 

If you have a sequence where the final output might need to be run more than once, use the loop pattern. An example of when to use this is a customer support system with two different agents. First, one agent drafts a response to a customer query, and then another checks it for compliance. It must pass compliance before the message can be sent. If the compliance check fails, the loop pattern ensures that the workflow goes back to the drafting agent to try again, repeating the workflow over and over until it passes compliance or the maximum number of retries is reached.

When to add orchestration

For simple workflows where you know the exact agents you need to call ahead of time and the order in which to call them, you don't need an orchestrator agent. But sometimes you can't know until runtime which agents should be called, as it depends on the query. In these cases, an orchestrator agent can be useful.

Single orchestrator vs. hierarchical orchestration

A single orchestrator works well when you have a small number of agents. But with larger numbers, such as 50 or more agents, the entire context of the orchestrator agent will get filled up with descriptions of each agent, and it will start to degrade in quality and make more mistakes.

For large numbers of agents, switching to hierarchical orchestration can help since this spreads the context load across multiple orchestrators instead of just one.

Best practices when implementing agentic design patterns

Once you've decided on an agentic design pattern (or a combination of patterns), these best practices will help you run your agents reliably in production.

Version your agents: The specific model versions each agent uses, along with the prompts and configuration sent to it, are just code, so they can be version controlled through Git or similar tools. The same goes for configuration that's common across all agents, like the AGENTS.md file, which is explained in more detail below.

In multi-agent systems, the output of each agent may also need to be version controlled: Many agents are now instructed to return JSON according to a specific schema, with another agent expecting that output as part of its input. So it starts to become like an API contract, and like APIs, this also needs versioning. You can do this by defining the JSON output structure with a schema and versioning the schema.

Use an AGENTS.md file: This file defines shared guidelines, guardrails, and other preferences like tone or coding conventions that all agents should read before doing their work. This allows your agents to behave more consistently. 

Keep a human in the loop: For high-stakes actions that could have serious consequences, don't allow agents to take actions without them being checked by a human. This includes processing payments, issuing refunds, deleting data, and executing code in production environments. 

Define exit conditions clearly: For any patterns that involve a loop, you need to clearly define the exit conditions that make an agent break out of a loop. However, you must also set a clear number of retries so that your agent doesn't keep trying indefinitely, racking up huge bills.

Log every agent call: Logging the traces and spans for each agent call helps with debugging and auditing, especially with orchestrator patterns where the exact order the agents are run in isn't predetermined and can vary across requests.

Start simple. Iterate and improve. Build on structured content.

With so many different agentic design patterns, you should be careful not to overengineer a solution. A good approach is to find the simplest solution that will work for your use case. 

For example, you could try starting with a single agent with ReWOO and see if that can handle what you need. Then, add complexity as needed — perhaps by using ReAct or by adding reflection. Then, you can make your system multi-agent, starting with sequential, parallel, or loop and adding orchestration.

AI agents work best with consistent, predictable, structured content, as this allows complex agentic workflows to maintain context over long conversations, making the system easier to debug, improve, and govern. 

The Contentful digital experience platform allows you to structure your content so that it works best for agentic AI as well as for websites, apps, and any other digital channels.

Start building

Sign up for a Contentful account

Use your favorite tech stack, language, and framework of your choice.