A Field Guide to Agentic Design Patterns: The 17 Building Blocks of Modern AI Agents

Author: Siddhesh Prabhugaonkar — Enterprise AI & Cloud Consultant

Object-oriented programming didn't feel like a discipline until the Gang of Four sat down and named the twenty-three recurring shapes hiding inside everyone's code. Once "Singleton," "Observer," and "Strategy" had names, teams stopped reinventing them badly and started choosing between them deliberately.

Agent architecture is at the same inflection point today. Every team building on top of an LLM eventually reinvents the same handful of control-flow shapes — a reasoning loop that calls tools, a planner that hands off to a swarm of workers, a memory layer that decides what the model is even allowed to see. Most of us built these the hard way, through trial, error, and a runaway token bill. It's worth naming them properly.

This post is the first in a five-part series that maps out 17 recurring agentic design patterns, organized into four families:

Single-Agent Patterns — how one model reasons and acts inside a loop
Multi-Agent Patterns — how several agents coordinate, delegate, and disagree
Memory & State Patterns — what an agent remembers, forgets, and persists
Interaction & Integration Patterns — how humans and other systems plug into the loop

Designing an agent architecture for production and want a second set of eyes? I run hands-on enablement workshops on exactly this stack. Book a discovery call →

Why a shared vocabulary matters now

Three years ago, "agent" meant a chatbot with a system prompt. Today it can mean a single ReAct loop calling three tools, or it can mean twelve specialized sub-agents checkpointing state to a database while a human approves every write operation. Those are wildly different systems with wildly different cost, latency, and failure profiles — and calling both of them "an agent" hides more than it reveals.

Naming the pattern underneath forces three useful questions before a line of code gets written:

What does this pattern cost? — not vibes, actual order-of-magnitude token spend.
What does this pattern cost the user in wait time? — sequential model calls on the critical path, which is a different number from total cost.
What failure mode am I signing up for? — every pattern trades one class of failure for another; there is no free lunch.

The two numbers that matter — and why they're not the same number

Most architecture discussions collapse "expensive" into a single axis. That's a mistake, because two systems can burn the same number of tokens and feel completely different to a user.

Total cost — tokens consumed across the whole run, regardless of how they're spent. This is what shows up on the invoice.
Path depth — the number of sequential model calls the user actually waits on, end to end. This is what shows up as latency.

They come apart badly. Ensembling (fire off five independent completions and vote) and peer debate (four agents argue across sequential rounds) both cost roughly the same order of magnitude in tokens. But ensembling is one call wide — you can fire all five in parallel and return in the time of a single call — while debate is four calls deep, so the user waits for all four rounds sequentially. Only one of those survives a live chat interface; the other is fine for an overnight batch job.

Every pattern in this series gets evaluated against both axes, because a pattern that's cheap in tokens but deep in sequential calls is exactly as unsuitable for a live user-facing chat as one that's shallow but burns ten times the tokens is unsuitable for a high-volume batch pipeline. Treat both figures as order-of-magnitude priors relative to a single reason-act call on the same model — not measured benchmarks. Your own evals should overturn them.

The four families, at a glance

Here's every pattern in one table — the cheat sheet to bookmark. Cost and latency are relative to a single reason-act call on a comparable model (1× baseline), not absolute numbers.

Pattern	Family	One-line intent	Relative cost	Relative latency (path depth)
Reason & Act (ReAct) Loop	Single-Agent	Interleave reasoning traces with tool calls, one step at a time	1–3×	Deep (N steps)
Plan-Then-Execute	Single-Agent	Decompose the goal once, then execute the plan with less re-reasoning	1–2×	Medium
Search over Actions	Single-Agent	Explore multiple candidate action paths via tree/graph search, backtrack on failure	3–10×+	Deep, but parallelizable
Reflection & Self-Correction	Single-Agent	Critique your own output, retry against the critique	2–4×	Medium (2× the base loop)
Code-as-Action	Single-Agent	Emit executable code instead of one tool call per step	1–2×	Shallow
Orchestrator-Worker	Multi-Agent	Central planner decomposes work, delegates to context-isolated workers	2–5×	Medium (parallel workers)
Peer Debate & Ensembling	Multi-Agent	Multiple instances argue or vote to cancel out individual errors	~5×	Wide (ensemble) or Deep (debate)
Role-Based Teams	Multi-Agent	Mirror a human org chart, communicate via artifacts, not chat	3–8×	Medium–Deep
Conversational Multi-Agent	Multi-Agent	Shared conversation history, dynamic turn-taking, human can jump in	2–6×	Deep
Handoff	Multi-Agent	Specialized agents pass control via routing tools	1–3×	Shallow–Medium
Context Window Management	Memory & State	Compact, truncate, and curate what stays in-context	Reduces cost	Reduces latency
Episodic External Memory	Memory & State	Embed and retrieve past sessions via vector similarity	+Retrieval calls	Shallow addition
Structured & Procedural Memory	Memory & State	Separate durable facts and reusable skills from conversation	Reduces cost	Reduces latency
Shared Memory / Blackboard	Memory & State	Agents read/write a common store instead of passing messages	Reduces redundant cost	Depends on contention
Checkpointing & Resumability	Memory & State	Persist state snapshots so runs can pause, resume, or roll back	Storage, not tokens	Removes re-run cost
Human-in-the-Loop	Interaction	Approval gates, escalation thresholds, steering, outcome review	Adds wait time	Adds human-speed latency
Protocol-Level Integration	Interaction	Standardized interfaces (MCP, A2A) instead of bespoke adapters	Reduces integration cost	Neutral
Sandboxing & Permissioning	Interaction	Runtime isolation and privilege separation for tool execution	Adds infra cost	Usually negligible

What's next in this series

Part 2 — Single-Agent Patterns: the five ways one model can reason and act — from the ubiquitous ReAct loop to writing code as its action space.
Part 3 — Multi-Agent Patterns: orchestration, debate, role-based teams, and the handoff pattern that keeps prompts sane.
Part 4 — Memory & State Patterns: context management, episodic memory, and why checkpointing is the pattern most production teams skip until it's too late.
Part 5 — Interaction & Integration Patterns: where humans sit in the loop, how MCP and A2A replace bespoke adapters, and how to sandbox an agent that can execute arbitrary code.

If you've already read my earlier piece on AI agents, multi-agent systems, and the LLM council pattern, think of that post as the why — the maturity model for adopting agents in an enterprise — and this series as the what: the concrete architectural vocabulary you'll use once you've decided to build.

If you found this useful, I write regularly on enterprise AI, agentic architectures, and applied GenAI adoption. My other recent posts:

Want help designing an agent architecture for your organization? Book a discovery call →

About the Author

Siddhesh Prabhugaonkar is a Generative AI & Agentic AI Enablement and Adoption Specialist with two decades as an Architect, Consultant, and Trainer across IT, Cloud, and Generative AI. He is a Microsoft Certified Trainer, a Pluralsight Instructor, and helps enterprises move from GenAI curiosity to production adoption at scale.

His consulting and training practice spans GenAI, Azure, Microsoft Foundry, Anthropic Claude, GitHub Copilot, Google Gemini, OpenAI Codex, Cursor, Devin, and modern full‑stack engineering (.NET, MEAN, MERN). Notable engagements include GenAI enablement for ADP, IoT platform consulting for IIT Bombay's E‑Yantra program, and early work on Microsoft's Repository platform (which later became Entity Framework).