# 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 →](https://topmate.io/siddheshp)

* * *

## 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:

1.  **What does this pattern cost?** — not vibes, actual order-of-magnitude token spend.
    
2.  **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.
    
3.  **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.

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/ebe2b640-046f-4b6a-aff4-b27b09d45d98.png align="center")

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

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/e7161cf3-18e6-4187-a795-9b1af882eb8b.png align="center")

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**](/agentic-design-patterns-single-agent)**:** 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**](/agentic-design-patterns-multi-agent)**:** orchestration, debate, role-based teams, and the handoff pattern that keeps prompts sane.
    
*   **Part 4 —** [**Memory & State Patterns**](/agentic-design-patterns-memory-state)**:** context management, episodic memory, and why checkpointing is the pattern most production teams skip until it's too late.
    
*   **Part 5 —** [**Interaction & Integration Patterns**](/agentic-design-patterns-interaction-integration)**:** 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](https://cloud-authority.com/ai-agents-multi-agents-llm-council-enterprise-guide), 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:*

*   [*AI Agents, Multi-Agent Systems & LLM Council: A Practitioner's Guide to Enterprise Agentic AI*](https://cloud-authority.com/ai-agents-multi-agents-llm-council-enterprise-guide)
    
*   [*Prompt, Context, Harness, Loop: The Four Layers of Engineering Reliable AI Agents*](https://cloud-authority.com/prompt-context-harness-loop-the-four-layers-of-engineering-reliable-ai-agents)
    
*   [*AI-DLC: The AI-Driven Development Life Cycle That Replaces Sprints With Bolts*](https://cloud-authority.com/ai-dlc-the-ai-driven-development-life-cycle-that-replaces-sprints-with-bolts)
    

**Want help designing an agent architecture for your organization?** [**Book a discovery call →**](https://topmate.io/siddheshp)

* * *

### Further reading

*   Yao, S., et al. (2023). *ReAct: Synergizing Reasoning and Acting in Language Models.* ICLR. [arxiv.org/abs/2210.03629](https://arxiv.org/abs/2210.03629)
    
*   [Model Context Protocol](https://modelcontextprotocol.io) — the open standard referenced throughout the Interaction & Integration part of this series
    
*   [Agentic Protocols — Pattern Catalog](https://www.agenticprotocols.dev/patterns.html) — an interactive catalog covering similar ground, worth bookmarking as a cross-reference
    

* * *

## 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**).

> *Empowering organizations and individuals to adopt, build, and scale with Generative AI, Cloud, and Modern Software Engineering.*

**Connect & explore:**

*   💼 LinkedIn — [linkedin.com/in/siddheshprabhugaonkar](https://www.linkedin.com/in/siddheshprabhugaonkar)
    
*   📝 Blog — [azureauthority.in](https://azureauthority.in/)
    
*   📬 Newsletter — [cloud-authority.com](https://cloud-authority.com/)
    
*   🎥 YouTube — [youtube.com/c/SiddheshPrabhugaonkar](https://www.youtube.com/c/SiddheshPrabhugaonkar)