Quick Answer: Agentic design patterns are reusable ways to structure an AI agent's work so it does more than answer in one shot. The four core patterns — reflection, tool use, planning and multi-agent collaboration — were named by Andrew Ng in 2024. Reflection and tool use are reliable defaults. Planning and multi-agent collaboration pay off only on the right tasks, and they cost more.
In March 2024, Andrew Ng published three numbers that changed how engineers think about agents. On the HumanEval coding benchmark, GPT-3.5 answering in one shot scored 48.1%. GPT-4, a much stronger model, scored 67.0%. GPT-3.5 wrapped in an agent loop scored up to 95.1%. The loop beat the model upgrade.
The loops he described became the four agentic design patterns: reflection, tool use, planning and multi-agent collaboration. Since then the list has grown. Anthropic has five workflow patterns, Google Cloud's architecture guide has twelve, and a 2025 Springer book counts twenty-one. The original four still carry most of the weight, but they aren't equally safe. Ng himself called reflection and tool use the dependable ones and said planning and multi-agent collaboration were hard to predict. Two years of research and production reports have mostly proved him right.
This guide covers how each pattern works, what it costs, what the evidence says about when it pays off, the patterns added since 2024, and how they stack inside one ordinary job. If you'd rather hand the job to an agent that already has its own computer than wire the patterns yourself, that's what cowork.ink is for.
What Are Agentic Design Patterns?
Agentic design patterns are reusable structures for how a language model loops over a task: how it checks its own work, reaches outside itself, breaks a job into steps, and divides it among roles. They sit one level above prompts and one level below a full system architecture.
The name borrows from classic software design patterns. A pattern like "observer" or "factory" doesn't give you code; it gives a recurring problem a name and a known-good shape. Agentic patterns do the same for LLM systems. "Add a reflection step" is a sentence two engineers can act on without drawing a diagram.
The term comes from a five-part letter series Ng wrote in The Batch between March 20 and April 17, 2024:
- Reflection — the model critiques its own output and revises it.
- Tool use — the model calls functions to fetch information or take action.
- Planning — the model breaks a goal into steps before executing them.
- Multi-agent collaboration — several agents with different roles split the work.
Each one adds model calls, and each extra call buys something specific: accuracy, fresh facts, structure, or specialization. The skill is knowing which purchase a task actually needs.
Design Patterns vs. Workflow Patterns vs. Pattern Catalogs
Several catalogs now use overlapping vocabulary, and the counts differ because they name different things. Here is how the main ones line up:
| Catalog | Source and date | Count | What it names |
|---|---|---|---|
| Agentic design patterns | Andrew Ng, The Batch, Mar–Apr 2024 | 4 | Capabilities an agent loop adds |
| Workflow patterns | Anthropic, "Building Effective Agents," Dec 2024 | 5 + agents | How LLM calls are wired: chaining, routing, parallelization, orchestrator–workers, evaluator–optimizer |
| Agentic AI design patterns | Google Cloud Architecture Center, updated May 28, 2026 | 12 | Single-agent and multi-agent topologies, ReAct, human-in-the-loop, custom logic |
| Agentic Design Patterns (book) | Antonio Gullí, Springer, 2025 | 21 | Adds memory, guardrails, MCP, A2A, exception handling, evaluation, prioritization and more |
The catalogs overlap more than they disagree. Anthropic's evaluator–optimizer is Ng's reflection split across two calls. Google's coordinator and swarm are two shapes of Ng's multi-agent collaboration. We cover Anthropic's wiring patterns in our guide to agentic workflows; this guide stays with the four capabilities underneath them, plus the handful of newer patterns that earned a place.
The 4 Core Agentic Design Patterns at a Glance
Two of the four patterns are reliable defaults; two are bets you place on specific tasks. That is not our opinion — it's how Ng graded them in 2024, and what most production evidence since then shows.
| Pattern | What the agent gains | Extra model calls | Ng's verdict (2024) | Reach for it when |
|---|---|---|---|---|
| Reflection | Catches its own mistakes | +1–2 per round | Reliable, quick to implement | There's a checkable quality bar |
| Tool use | Fresh facts, real actions | +1 per tool call | Reliable | The model can't know or do it alone |
| Planning | Stays on track across many steps | +1 to plan, + replans | "Less mature… hard to predict" | Jobs run long with dependent steps |
| Multi-agent | Specialization, parallel work, more total context | Many — about 15× a chat | "Hard to predict" when agents interact freely | Work splits into independent parts |
The last column is the most useful thing in this guide. Start with the top two rows, and climb down the table only when a task forces you to.
Pattern 1: Reflection
Reflection is the pattern where an agent reviews its own output and revises it before handing it over. One call drafts, another critiques the draft against explicit criteria, and a third rewrites it. The loop stops when the critique passes or a round limit is reached.
In practice it runs as four steps:
- Generate. Produce a first draft — code, a summary, a table, an email.
- Critique. Check the draft against a rubric or, better, against something external: tests, a schema, a source document.
- Revise. Rewrite using the critique as input.
- Stop. Exit on a pass, or after two or three rounds, whichever comes first.
Ng described the single-model version first and then a stronger variant: create two agents, "one prompted to generate good outputs and the other prompted to give constructive criticism." That second form is what Anthropic later called evaluator–optimizer and Google Cloud calls review and critique.
Why Does Reflection Need Something to Check Against?
Reflection works when the critic has evidence the drafter didn't. Test output, a compiler error, a source document or a total to reconcile against all qualify. Without that evidence, a model critiquing itself often just restates its own mistake more confidently.
Two well-known papers show both sides of this:
- With an external signal, it works. Reflexion (Shinn et al., 2023) ran generated code against tests, wrote a short reflection on each failure, and kept those notes in memory for the next attempt. It reached 91% pass@1 on HumanEval, against 80% for GPT-4 alone.
- Without one, it can backfire. Researchers at Google DeepMind found that LLMs "struggle to self-correct their responses without external feedback, and at times, their performance even degrades after self-correction" on reasoning tasks.
Same pattern, opposite results. The difference is the signal the critic gets to see.
Cognition, the company behind the Devin coding agent, added a third finding in April 2026. In its generator–verifier loop, the reviewer works better when it starts fresh: "clean context leads to a notable improvement in capabilities." A critic that watched the draft being written inherits the drafter's blind spots. Give it the output and the criteria, not the whole conversation.
If you can't write down what the critic should check, you don't need a reflection step — you need a better prompt. And if the check can be written as code (a schema, a test, a sum), run the code. A validator is cheaper than a critic and never gets talked out of its verdict.
When to Use Reflection
Use reflection when quality matters more than latency and there's a concrete bar to clear:
- Code, where tests and linters give the critic hard evidence
- Data work, where totals must reconcile with a source
- Extraction, where output must match a schema and the source text
- Writing against a style guide, where the rubric is explicit
Skip it for real-time responses, for tasks with no articulable quality bar, and anywhere the "critique" would be pure taste. Each round costs about two calls, so cap it at two or three rounds in code.
Pattern 2: Tool Use
Tool use is the pattern where the model is given functions it can call — search, code execution, APIs, a browser — and decides when to call them. In Ng's words, "an LLM is given functions it can request to call for gathering information, taking action, or manipulating data."
This is the pattern that turns a model into an agent. Without tools a model can only talk about the world; with them it can look things up and change things. Ng's own examples were deliberately mundane: search the web to find which coffee maker reviewers rate highest, or run a line of Python to compute compound interest instead of doing arithmetic in its head.
Most tool use runs inside a ReAct loop: reason about what's needed, call a tool, observe the result, decide again. Our ReAct pattern guide walks through that loop step by step.
Tool Design Is the Real Pattern
Most tool-use failures are tool-design failures, not model failures. The model picks tools by reading their names and descriptions, so the toolset is effectively part of the prompt.
What separates tools that work from tools that don't:
- Narrow beats broad.
get_invoice(invoice_id)is far more reliable thanrun_sql(query). Broad tools hand the model a design problem along with the task. - Descriptions are instructions. Say when to use the tool, when not to, and what it returns.
- Errors should teach. "Customer 1234 not found; IDs are 6 digits" lets the model recover. A stack trace doesn't.
- Fewer tools, better choices. Google Cloud's guide notes that a single agent degrades as its tool count grows — higher latency, wrong tool choices, failed tasks.
- Read-only first. Give write access only where the task needs it, and gate irreversible writes.
For the mechanics — schemas, parallel calls, error handling — see AI agent tool calling. For plugging tools in without custom glue, the Model Context Protocol has become the standard connector.
The Biggest Tool Is a Whole Computer
The far end of tool use isn't a longer list of APIs. It's an environment: a browser, a file system, a terminal, an inbox. An agent with a computer can use every tool a person can, including the ones nobody ever wrote an API for — the vendor portal, the admin dashboard, the spreadsheet someone emails every Friday.
That changes what "tool design" means. Instead of wrapping every system in a function, you give the agent a machine and let it work the way a new hire would.
Pattern 3: Planning
Planning is the pattern where the agent breaks a goal into steps before acting, then works through them — and revises the plan when reality disagrees. It's what lets an agent finish a twenty-step job without losing the thread at step seven.
Ng's example was a two-step image task adapted from the HuggingGPT paper: to draw a girl in the same pose as a boy in a photo, first detect the pose, then render a new figure in it. The model chooses the steps and the tools for each.
He was also blunt about the risk: "Planning is a less mature technology, and I find it hard to predict in advance what it will do." Plans fail in two classic ways. They're wrong from the start, or they're right at the start and go stale while the agent keeps following them.
Plan-and-Execute vs. ReAct
The two main ways to plan differ in when the plan gets made:
| ReAct | Plan-and-execute | |
|---|---|---|
| When the plan is made | One step at a time, after each observation | Up front, for the whole task |
| Adapts to surprises | Naturally, every step | Only if you add replan checkpoints |
| Cost profile | Full context on every call | One big planning call; steps can run on a cheaper model |
| Typical failure | Wanders, loops, forgets the goal | Follows a stale plan off a cliff |
| Best for | Short, exploratory tasks | Long tasks with a predictable shape |
Most production agents use a hybrid: write a plan, execute each step with a small ReAct loop, and replan at checkpoints or whenever a step fails. Our guide to how AI agents reason compares the reasoning strategies behind each.
Make the Plan an Artifact
The most practical planning upgrade is to write the plan down where both the agent and you can read it. A plan that lives only inside the model's reasoning disappears when the context fills up.
Anthropic's research agent does this explicitly. Its lead agent starts by "saving its plan to Memory to persist the context," because long research runs can exceed the context window and get truncated. GoGogot, the open-source engine underneath cowork.ink, ships a task_plan tool for the same reason: a session checklist the agent uses "to break complex work into steps and track progress."
A visible checklist has three advantages over a hidden chain of thought. The agent can re-read it after its context is compacted. You can see at a glance where a run stalled. And you can correct the plan before step one runs, instead of after step nine fails.
Pattern 4: Multi-Agent Collaboration
Multi-agent collaboration splits a task across several agents with different roles, prompts, tools or models — a researcher, a writer, a reviewer — that pass work between them. It's the most powerful pattern on paper and the most expensive and failure-prone in practice.
Why would several copies of the same model beat one? Ng's answer: prompting a model "to focus on one thing at a time can give better performance," the same reason managers split projects among specialists. His showcase was ChatDev, an open-source set of agents running a virtual software company. His caveat came in the same letter: output quality is hard to predict, "especially when allowing agents to interact freely."
What Does the Evidence Say About Multi-Agent Systems?
Multi-agent systems win on broad, parallel, read-heavy work and lose on almost everything else. Three sources from the last eighteen months tell a consistent story.
- Anthropic, June 2025. A lead agent running Claude Opus 4 with Claude Sonnet 4 subagents outperformed single-agent Opus 4 by 90.2% on Anthropic's internal research eval. The price: agents use about 4× the tokens of a chat, and multi-agent systems about 15×. Token usage alone explained 80% of the performance variance on BrowseComp. Anthropic also named the poor fits: domains where all agents need the same context, and most coding, which has fewer truly parallel parts than research.
- UC Berkeley, NeurIPS 2025. The MAST study annotated runs from seven popular multi-agent frameworks and found 14 distinct failure modes in three groups: system design, inter-agent misalignment, and task verification. The authors' conclusion is that most failures come from how the system is designed and coordinated, not only from the model.
- Cognition, April 2026. Ten months after arguing against multi-agent systems, Cognition reported what does work for it in production: "setups where multiple agents contribute intelligence to a task while writes stay single-threaded." Swarms of agents writing in parallel, it says, still don't see meaningful adoption.
Put together, the lesson fits in one line: read in parallel, write in one place.
Before adding a second agent, ask whether the result is worth roughly fifteen times the tokens of a chat. For Anthropic's broad research queries the answer was yes. For most business tasks — a report, a reply, a reconciliation — it's no, and one agent with good tools does the job.
Multi-Agent Topologies
When the work does justify several agents, the next decision is who coordinates whom. Google Cloud's catalog gives the clearest map:
| Topology | Who decides the next step | Use it when |
|---|---|---|
| Sequential | Fixed code, in order | Each stage always follows the last |
| Parallel | Fixed code fans out, then merges | Sub-tasks are independent |
| Loop / review and critique | Code, until an exit condition | Output needs rounds of checking |
| Coordinator | A model routes sub-tasks to specialists | Sub-tasks vary per request |
| Hierarchical decomposition | Layers of coordinators | The job is too big for one coordinator |
| Swarm | Peers talk to each other | Rarely — exploratory problems with a hard exit condition |
The top three are deterministic; the bottom three let a model direct the flow, which is where cost and unpredictability climb. Our guides to multi-agent systems and delegation patterns cover each topology with examples.
Beyond the Big Four: Patterns Added Since 2024
Since 2024 the catalog has grown in two directions: patterns for control and patterns for cost. Five additions are worth knowing by name.
Routing
A classifier reads each input and sends it to the right handler, prompt or model. It's the cheapest pattern in the catalog and often the highest-return, because it lets you send easy traffic to a small model and save the big one for the hard tail. See model routing for AI agents.
Human-in-the-Loop
The workflow pauses at defined checkpoints so a person can approve, correct or add input before the agent continues. It belongs anywhere an action is costly or irreversible: payments, deletions, messages to customers. Our guide to human-in-the-loop agents covers how to place checkpoints without killing the speed advantage.
Memory
The agent persists facts and corrections across sessions, so "exclude refunds from revenue" only has to be said once. Memory turns reflection from a per-run fix into a lasting one. More in AI agent memory.
Generator–Verifier With Clean Context
This is reflection promoted to two agents, with one rule added: the verifier starts with a fresh context. It's the multi-agent setup Cognition says works best for it today, because the verifier contributes judgment without writing anything itself.
The Advisor Pattern
The advisor pattern pairs a cheaper executor model that runs the whole task with a stronger advisor model it consults only on hard decisions. Anthropic published it as "the advisor strategy" on April 9, 2026 and shipped it as an API tool. The advisor reads the shared context and returns "a plan, a correction, or a stop signal"; it "never calls tools or produces user-facing output."
Anthropic's reported results, measured on its April 2026 models:
- Sonnet with an Opus advisor: +2.7 percentage points on SWE-bench Multilingual over Sonnet alone, with cost per agentic task down 11.9%.
- Haiku with an Opus advisor: 41.2% on BrowseComp, more than double Haiku's solo 19.7%. It trails Sonnet alone by 29% in score but costs 85% less per task.
Cognition describes the same idea as a "smart friend" and adds the caveat that it works "when both models are strong." The pattern is worth noticing for another reason: it is multi-agent collaboration with single-threaded writes built in. The advisor contributes intelligence; the executor does every write. That's exactly the shape the evidence above favors.
How Do Agentic Design Patterns Stack in a Real Task?
Real agents rarely use one pattern; they stack two to four. Take an ordinary recurring job — the Monday revenue report — and watch which pattern does which part.
- Planning. The agent writes a checklist: open the billing dashboard, export last week's transactions, compute revenue by plan, compare with the prior week, build the PDF, post it in Slack.
- Tool use. It opens the dashboard in a browser, downloads the CSV, runs the numbers in a code runtime and saves the PDF to disk.
- Reflection with a real check. Before sending, it compares its computed total with the headline number on the dashboard. If they don't match, it re-exports instead of explaining the gap away.
- Human-in-the-loop. If revenue moved more than an agreed threshold week over week, it flags the change for a person instead of just posting the chart.
- Memory. Last month someone said refunds belong in a separate line. That correction is still there this Monday.
| Step | Pattern | What goes wrong without it |
|---|---|---|
| Checklist | Planning | Skips the comparison, or stops after the export |
| Browser, files, code | Tool use | Writes instructions for you instead of the report |
| Total matches dashboard | Reflection | A silently wrong number lands in the team channel |
| Flag big swings | Human-in-the-loop | An alarming chart goes out with no context |
| Refunds on their own line | Memory | You correct the same thing every week |
Notice what's missing: a second agent. The job is sequential, needs one shared context, and produces one output. Every piece of evidence above says a single agent with good tools is the right design here.
This is the shape of work an AI coworker on cowork.ink is built for. Each coworker has its own computer — a real browser, files, an inbox, a code runtime — so the tool-use step is the whole web, not a list of integrations. It shows up in Slack or Telegram on the schedule you set, the PDF attached, and every run leaves a transcript of the pages it opened and the files it produced.
How to Choose an Agentic Design Pattern
Start with one agent and good tools. Add reflection where there's a checkable bar, planning when jobs run long, and more agents only when the work splits into independent parts one context can't hold. Google Cloud's guide puts the first step plainly: "we recommend that you start with a single agent."
Match the symptom to the pattern:
| If the problem is… | Reach for | Not this |
|---|---|---|
| The model lacks current facts or can't act | Tool use | A bigger model |
| Errors a test or validator could catch | Reflection with an external check | Self-critique with no evidence |
| Long jobs lose the thread | Planning with a written checklist | More agents |
| Inputs fall into distinct types | Routing | One giant prompt |
| A wrong action is costly or irreversible | Human-in-the-loop | Reflection alone |
| Broad research across many independent sources | Multi-agent: parallel readers, one writer | Parallel writers |
| The best model is too expensive for the whole loop | Advisor pattern | Downgrading everything |
Then climb in this order, measuring at every rung:
- One call, good context. Many "agent" problems are retrieval problems.
- Add tools. Narrow, well-described, read-only first.
- Add a check. A validator in code, then a critic if code can't express the bar.
- Add a plan. As a visible checklist, with replanning when a step fails.
- Add a human checkpoint before anything irreversible.
- Add agents last, and only for parallel reading.
Tool use plus one real check solves more problems than any multi-agent architecture. Ship that, measure cost per successful task, and let the failures tell you which pattern to add next.
Common Anti-Patterns to Avoid
Every pattern has a failure mode that looks like progress. These are the ones that show up most often in production post-mortems.
- •Give the critic evidence: tests, a schema, a source total
- •Keep toolsets small, narrow and well described
- •Write plans down as a checklist the agent re-reads
- •Parallelize reading, keep writing single-threaded
- •Cap rounds, iterations and tokens in code
- •Run "reflection theatre": a critic with no criteria
- •Hand one agent forty tools and hope it picks well
- •Follow a stale plan instead of replanning on failure
- •Build an org chart of agents because it demos well
- •Enforce limits with prompt instructions alone
The org-chart anti-pattern deserves a sentence of its own. A "CEO agent" briefing a "CTO agent" briefing a "developer agent" mirrors a human company, but it buys none of the reasons companies split work — and each hand-off is a chance to lose context, which is exactly the inter-agent misalignment MAST catalogued. Split agents along lines where the work is genuinely independent, not along job titles.
Hand the Patterns to an AI Coworker
Agentic design patterns aren't a menu to order everything from. The evidence points one way: tool use and reflection with a real check are the defaults, planning keeps long jobs on track, and multiple agents earn their 15× only on wide, parallel reading. Most valuable work is one agent, one context, good tools and a check before anything goes out.
If you want to see that loop in code, GoGogot (go-go-got.com) is the MIT-licensed engine underneath cowork.ink. It's a single agent: it plans with a task_plan checklist, works through tools like bash and web_fetch, keeps notes with memory_write, and pauses to ask a person with ask_user. It doesn't spawn sub-agents.
If you'd rather hand over the job than build the loop, cowork.ink gives you AI coworkers — as many as you need, in whatever roles you need — each with its own cloud computer. Tell one what it's for, hand it the documents a new hire would get on their first morning, connect Slack or Telegram, and give it the first task in plain language. It takes about three minutes, and it's $25 a month billed yearly, everything included.
For the wiring layer around these patterns, read our guide to agentic workflows; for the loop at the center of tool use, start with the ReAct pattern.