7 Agentic AI Design Patterns You Should Know

For the last two years, "AI" mostly meant a chatbot: you type a prompt, it types back. That's changing fast. The systems getting built in production right now don't just respond — they plan, call tools, check their own work, and sometimes hand off tasks to other agents entirely. That shift, from AI as chatbot to AI as autonomous system, is what "agentic AI" actually means.

The problem is, most engineers jump straight to frameworks (LangGraph, CrewAI, AutoGen) without understanding the underlying patterns those frameworks are built on. If you know the patterns, you can pick the right tool — or build it yourself without one. Here are the 7 you need to know.

This is the foundation almost every other pattern builds on. The LLM is given a set of tools (a weather API, a database query, a calculator) with structured schemas. Instead of just generating text, the model decides when to call a tool, which one, and what arguments to pass — then uses the result to continue its response.

Use it when: You need the model to fetch real-time or external data it doesn't have (pricing, inventory, live metrics). Trade-off: Simple to implement, but it's single-shot — the agent doesn't loop or reconsider once it acts.

ReAct extends tool-use into a loop: Reason → Act → Observe → Reason again, repeating until the task is done. Instead of one tool call, the agent thinks out loud about what to do next, takes an action, looks at the result, and decides the next step.

Use it when: The task requires multiple steps where each result changes what the next step should be (e.g., debugging, multi-hop research). Trade-off: More flexible than plain tool-use, but can loop inefficiently or get stuck without good stopping conditions.

Here, planning and execution are split into two distinct roles. A "planner" LLM breaks the goal into a sequence of subtasks upfront. An "executor" (which can be the same or a different model) carries out each subtask, one at a time.

Use it when: The task is complex enough that reasoning about the whole plan upfront produces better results than deciding step-by-step (e.g., multi-stage data pipelines, report generation). Trade-off: Better structure and predictability than ReAct, but less adaptive — if step 3 fails, the whole plan may need re-planning.

Instead of one agent doing everything, a "supervisor" agent delegates subtasks to specialized worker agents — a research agent, a coding agent, a writing agent — then combines their outputs. The supervisor decides who does what and in what order.

Use it when: Different subtasks genuinely need different skills, tools, or context windows (e.g., a system that researches, codes, and then documents). Trade-off: Powerful for complex workflows, but adds coordination overhead, latency, and cost — more agents talking to each other means more room for miscommunication.

The agent generates an output, then critiques its own work against the original goal, and revises if needed — before showing the result to the user. Think of it as a built-in code review step, except the reviewer and the author are the same model.

Use it when: Output quality matters more than speed — code generation, writing, or anything where a "first draft" isn't good enough. Trade-off: Noticeably improves quality, but doubles (or triples) token usage and latency per task.

Retrieval-Augmented Generation gives the agent access to a knowledge base (internal docs, a vector database, a wiki) that it searches before responding. Unlike a static tool call, RAG grounds the agent's reasoning in your actual data instead of what the model memorized during training.

Use it when: Answers need to be grounded in proprietary, current, or domain-specific information (internal engineering docs, support tickets, compliance policies). Trade-off: Reduces hallucination significantly, but output quality is only as good as your retrieval pipeline — garbage chunks in, garbage answers out.

The agent pauses at defined checkpoints and waits for human approval before taking a consequential action — sending an email, deploying code, executing a financial transaction. It's the safety valve pattern.

Use it when: The action is high-stakes, irreversible, or regulated — anywhere a mistake is expensive. Trade-off: Adds friction and slows down the loop, but it's often non-negotiable for production systems handling real money, real infrastructure, or real customers.

Most production agentic systems don't use just one pattern — they stack them. A common architecture for an AI-powered DevOps assistant looks like this:

That's five patterns working together — planning-and-delegation, retrieval, reasoning loops, human oversight, and self-review — in a single real-world workflow. This is what "agentic architecture" actually looks like once you move past a demo.

When would you choose a planner-executor pattern over ReAct?

Think about it before scrolling.

A good answer: ReAct is better when each step genuinely depends on the outcome of the previous one and you can't predict the full path upfront (exploratory, uncertain tasks). Planner-executor is better when the overall structure of the task is knowable in advance and you want predictability, easier debugging, and the ability to run steps in parallel — at the cost of being less adaptive if something unexpected happens mid-execution.