Agentic Design Patterns
10 Patterns for AI Engineers

Workflow vs Agent — the first rule

These design patterns are the "alphabet" of building AI systems. But before diving into the list, there's one rule that matters more than any pattern, and every experienced AI engineer will sign off on it: start with the simplest thing that works. Most problems that look like "I need an autonomous agent" are solved perfectly by a workflow — a fixed code path with LLM calls wired up in advance. Don't add autonomy unless the task genuinely requires dynamic runtime decisions.

Patterns 1–6 are mostly workflows. Pattern 7 is the true autonomous agent. Patterns 8–10 are cross-cutting — they accompany all the rest. Authoritative sources for most of these: Anthropic's "Building Effective Agents", the ReAct paper (Yao et al.), and the Reflexion paper (Shinn et al.).

1 · Prompt Chaining

linkWORKFLOW · fixed sequence

Break a task into a fixed sequence of LLM calls, where each step processes the previous step's output. You can add a "gate" between steps that checks the output is valid before continuing.

When to use: when the task decomposes cleanly into fixed subtasks — e.g. outline → draft → polish, or translate → localize. You trade latency (more calls) for higher accuracy at each step.

2 · Routing

call_splitWORKFLOW · classify then dispatch

Classify the request, then send it to the right specialist — a dedicated prompt, a different model, or a different tool. This is the pattern from the viral series (04/05).

When to use: when inputs fall into distinct categories better handled separately — support tickets (billing / technical / refunds), or routing easy questions to a cheap model and hard ones to a strong model (significant cost savings).

3 · Tool Use / ReAct

buildAGENTIC · reason → act → observe

The heart of every agent: the model reasons about what to do, calls a tool (search, DB, code, API), observes the result, and loops — until an answer. This is the pattern from the series (01/05), based on the ReAct paper.

When to use: when the task needs live data or an action in the world — search, database reads, running code. We covered a full implementation in the AI Agents guide and in MCP (the standard way to connect tools to an agent).

4 · Planning

checklistWORKFLOW · Plan-and-Execute

One LLM decomposes a high-level goal into ordered steps; then each step executes (sometimes by sub-agents). It separates "what to do" from "the doing." This is the pattern from the series (02/05).

When to use: for multi-step goals where planning ahead improves the result — writing a report, market analysis. The difference from Orchestrator (pattern 7): here the plan is set once, upfront, it doesn't evolve dynamically.

5 · Reflection / Critic

rate_reviewWORKFLOW · Evaluator-Optimizer

A generator produces output; a critic evaluates it against criteria; you loop on "revise" until the output passes the threshold. This is the pattern from the series (03/05), based on Reflexion.

When to use: when quality is critical and you have a clear evaluation criterion — code that must pass tests, content that must meet a spec, a translation that must preserve nuance. Works best when the critic has a sharp signal for "good."

6 · Parallelization

splitscreenWORKFLOW · in parallel

Run several LLM calls at once. Two flavors: Sectioning — split into independent subtasks; Voting — run the same task several times and aggregate by vote/consensus.

When to use: for speed (independent subtasks in parallel), or for higher confidence via consensus — e.g. several safety checkers in parallel, or several code reviews that vote. Also a good way to separate concerns when one task overloads a single prompt.

7 · Orchestrator-Workers

hubAGENTIC · Multi-Agent

An orchestrator agent dynamically breaks down the task and delegates to worker agents, then synthesizes the results. This is likely the fifth pattern (05/05) in the series. The difference from Planning: the subtasks aren't known upfront — the orchestrator decides them at runtime.

When to use: for open-ended, complex tasks you can't plan upfront — deep research, a code change spanning many files. Powerful, but expensive and slow — see the frameworks comparison (CrewAI, LangGraph, AutoGen) that implement it.

8 · Memory

databasecross-cutting · context over time

Short-term memory = the conversation history in the context window. Long-term memory = information stored outside the context (usually in a vector store) and retrieved by relevance.

When to use: when the agent must remember across steps or sessions. The trap: context bloat. Retrieve, don't dump — bring only the relevant snippets, not the whole history. The technical foundation is in the RAG guide and Vector Databases.

9 · Human-in-the-Loop

how_to_regcross-cutting · approval before action

A checkpoint that requires human approval before an irreversible or high-risk action — a payment, a deletion, sending an email to a customer.

When to use: for any action with a real-world consequence. Blind trust in an agent for irreversible actions is a recipe for disaster — one checkpoint beats fixing the damage. Easy to implement in LangGraph (Conditional Edges + an interrupt point).

10 · Guardrails

shieldcross-cutting · a safety layer

Not a flow but a safety layer wrapping all the other patterns: input and output validation, allowlists, schema checking, moderation, and hard limits (max_iterations, timeout, cost ceiling).

When to use: always, in any system that reaches production. We expanded on it in Guardrails, Agent Security and Prompt Injection — critical when the agent reads external content (a web page, an email) that may contain hostile instructions.

Cheat sheet — which pattern for which problem