Eight AI agent patterns and when to use them

An assistant that checks an order, a research agent comparing ten companies, and a service reacting to incoming alerts all use models and tools. They do not need the same architecture.

The useful question is what the work requires: a sequence of decisions, a specialist taking over a conversation, separate tasks that can run at the same time, or work that continues after the first request. The eight AI agent patterns below describe common answers. They can combine within one system, and they are not levels you must climb in order.

TL;DR Start with a workflow when you know the steps, or one agent when the next step depends on tool results. Use a router to choose who handles a request, a handoff when another agent should take over the conversation, and workers when specialists can help with parts of the task. Run independent work at the same time, check how the results fit together, and measure quality and cost.

First decide which steps need model decisions

A workflow can contain an LLM without letting it choose the entire process. For example, code can classify a support request and send it to one of three predefined handlers. An agent loop gives the model more discretion: after reading a tool result, it decides whether to call another tool, ask a question, or answer.

Anthropic's workflow and agent distinction is useful here. Start with the simplest structure that handles the task. If the process is always "retrieve an invoice, check its status, return the result," a fixed workflow may be sufficient. If later actions depend on what the invoice reveals, an agent may help.

LangChain's full workflow catalog contrasts this loop with routing, chaining, and other predefined paths.

The boundary is about control, not product naming. A fixed router can lead to an agent, a supervisor can call a deterministic tool, and an event handler can start either a workflow or an agent run.

Eight patterns, eight useful questions

1. Single agent with tools: what should happen next?

One model chooses a tool, the runtime executes it, and the result informs the next decision. This is often called a ReAct loop. It works well for a task such as checking an order and then looking up the carrier status using the tracking reference returned by the order tool.

The main constraints are tool clarity, context quality, permissions, and runtime limits. If the agent repeatedly chooses the wrong tool, inspect the tool definitions before adding a second agent. If evidence disappears in a long history, improve how context is retained.

Read how the single-agent tools pattern works.

2. Router: which handler should receive this request?

A router classifies an input and selects a specialist, model, or workflow. A billing question can go to billing tools while a product error goes to technical support. A rule may be enough when the distinction is explicit; an LLM can help when it requires interpreting language.

The difficult cases sit between categories. A request about duplicate charges and a crashing receipt screen may need a broader handler or several routes. Include a fallback and evaluate whether the chosen handler resolves the request. An allowed route label is not proof of a correct classification.

Read how to design the router pattern.

3. Handoff: who should handle the next user turn?

A handoff changes the active conversation owner. Triage can transfer the conversation to billing, which asks follow-up questions and responds directly. This differs from asking a billing worker for a result and keeping responsibility for the answer.

Transfer relevant history, confirmed identifiers, unresolved questions, and completed actions. Otherwise the specialist may repeat questions or act on assumptions. Repeated transfers are worth investigating, but there is no universal safe hop count.

Read how agent handoffs transfer a conversation.

4. Supervisor with workers: who coordinates specialist results?

A supervisor delegates bounded tasks and remains responsible for the overall request. In a supplier comparison, it can ask a research worker for sourced prices, request calculations, and resolve missing information before answering.

Clear worker return contracts make this useful. A worker should report its findings, evidence, and gaps; the supervisor should know what completion looks like. Too little returned context hides assumptions. Too much can recreate the overloaded context the split was meant to address.

Read how the supervisor-worker pattern works.

5. Orchestrator with workers: how can this task be divided?

An orchestrator breaks a larger task into subtasks and combines the results. It can run independent work in parallel, such as researching different companies against the same criteria. The quality of the split matters: workers need sufficiently clear scopes and a common output format.

Anthropic reported a 90.2% improvement over single-agent Claude Opus 4 on its internal research evaluation, using a lead Opus 4 agent with Sonnet 4 subagents. That demonstrates a result for that system and evaluation, not a general gain from adding workers.

The terms orchestrator and supervisor overlap across frameworks. One emphasizes decomposition and synthesis, the other continuing coordination. Parallel execution is a scheduling choice either design can use.

Read the orchestrator-worker pattern.

6. Evaluator and optimizer: how will the output improve?

A generator produces an answer, an evaluator checks it, and feedback guides another attempt. This fits tasks with useful evaluation criteria, such as generated code that can be tested or a response that must satisfy a schema.

A second opinion is not automatically a reliable check. Models can share errors, and a fluent critique can still be wrong. Prefer checks tied to evidence: tests, source documents, constraints, or human judgment where appropriate. Model-based review can still help, but measure whether its feedback improves the result.

Set a limit and a stop condition. Otherwise a review loop can spend indefinitely rephrasing an answer without improving it. Read the evaluator-optimizer pattern.

7. Hierarchical teams: can one coordinator still manage the work?

A hierarchy puts coordinators above smaller specialist teams. A large analysis task might have separate research, implementation, and evaluation groups, each returning a bounded result to the top-level coordinator.

This can separate domains and context, but every level adds messages and another opportunity to lose a constraint. Use it when the work has real nested responsibilities. A flat team does not become inadequate at a particular worker count.

Read how hierarchical agent teams work.

8. Event-driven execution: what starts the work and survives a failure?

An event-driven system starts work from a webhook, queue message, or schedule. An incoming alert might trigger an agent to inspect logs and prepare an incident summary. That run could internally use any of the preceding patterns.

The new concerns are delivery, persistence, retries, and duplicate actions. A queue may deliver the same event again, so a repeated run must not blindly repeat a side effect. Store progress where needed and define budgets for event volume as well as individual runs.

Read how event-driven agents work.

Compare the decisions before choosing a framework

Need	Pattern to consider	First thing to check
Choose the next action from tool results	Single agent with tools	Tool definitions and context quality
Select the relevant handler	Router	Ambiguous requests and fallback behavior
Let a specialist continue the conversation	Handoff	Active owner and transferred context
Combine specialist contributions	Supervisor with workers	Task boundaries and returned evidence
Split a larger task into independent parts	Orchestrator with workers	Dependencies and synthesis quality
Improve an output against criteria	Evaluator-optimizer	Whether the feedback is trustworthy
Coordinate distinct groups	Hierarchical teams	What each level needs to know
React to events across time	Event-driven execution	Recovery and duplicate handling

These choices can compose. A queue event can trigger a router, which selects a supervisor that calls two workers and sends the result through an evaluator. Each added component should solve a specific problem in that path.

Parallel work still needs reconciliation

Independent supplier lookups can run at the same time because one lookup does not need another's result. The returned prices may still disagree because sources use different currencies, quantities, or dates. Independent execution does not mean the results agree.

Writing can also run in parallel when tasks are separated carefully. Two workers changing different files may avoid a merge conflict and still disagree about an interface. Decide who owns shared contracts and how results are checked before they are combined.

Cognition's discussion of multi-agent failures emphasizes the implicit decisions agents make while acting. Anthropic's research-system account shows how bounded research tasks can benefit from separate contexts. The practical question is whether the workers can complete their assignments independently and whether the coordinator can resolve what comes back.

Use shared-state controls where actions interact. A lock, transaction, isolated workspace, or designated writer can address different forms of conflict. None replaces checking that the combined result makes sense.

Reliability, security, and cost belong in the design

Test repeated runs on representative tasks. A system that succeeds once may fail when the same request produces a different tool choice. Sierra's tau-bench uses repeated-trial evaluation to examine this consistency. You can apply the same idea without adopting its benchmark: record task success across several attempts and inspect the failures.

Define the behavior for partial completion too. If two workers succeed and one fails, decide whether to retry, return a qualified result, ask the user, or stop. Do not let synthesis silently fill the missing result with a guess.

Security depends on the permissions along the entire path. Simon Willison's lethal trifecta describes the risk of combining private data, untrusted content, and external communication. Separating agents does not resolve that risk if they can still pass private data to an agent with an external write tool. Enforce access and approval requirements in the runtime and tools.

Finally, measure usage rather than attaching a fixed multiplier to a topology. Anthropic reported roughly 4x chat token usage for agents and 15x for multi-agent systems in its research-system observations. Those figures are not an additive pricing formula. Your cost depends on context, model choice, worker count, retries, tool services, and caching. Parallelism changes elapsed time, not necessarily total work.

Start with one representative request

Write down the inputs, desired output, permitted actions, and evidence required for success. Run that request through the simplest workable implementation and inspect the trace.

Then change the architecture for a named reason: a specialist needs different access, a context is overloaded, independent work is too slow, or an output needs a check the generator cannot perform. Compare the result against the original implementation on quality, completion rate, latency, and cost. That gives you a reason to keep the extra coordination, or remove it.

Sources

• Anthropic: Building effective agents
• Anthropic: How we built our multi-agent research system
• LangChain: Workflows and agents
• LangChain: Multi-agent patterns
• Cognition: Don't build multi-agents
• Sierra: tau-bench
• Simon Willison: The lethal trifecta