Agentic AI Architecture: 5 Design Patterns Devs Must Know

When Shunyu Yao and colleagues published the ReAct paper in October 2022 (arXiv:2210.03629), they demonstrated something that now seems obvious but wasn't: large language models could interleave internal reasoning with real-world actions — web searches, database lookups, API calls — and use the results of those actions to reason further. That paper kicked off what is now a mature engineering discipline. Four years on, the field has enough battle-tested patterns to assemble something like a design catalog. Knowing these patterns is the difference between an agent integration that works in a demo and one that holds up in production.

What Distinguishes an Agent from a Plain LLM Call

Before the patterns, a precise definition. An agent is an LLM system that can take actions in the world — through tools, APIs, code execution, or other agents — and uses the results of those actions to inform subsequent reasoning. The loop of observe → reason → act is what separates an agent from a text completion endpoint. This loop creates a new class of engineering challenges that a standard REST wrapper around an LLM call never has to face: tools must be designed and managed, context windows grow with each step, external errors must be handled gracefully, and multiple agents must coordinate without deadlock or cascade failure.

Pattern 1: ReAct — Reasoning and Acting Interleaved

The ReAct pattern (Yao et al., arXiv:2210.03629) is the foundational design. Rather than separating reasoning from action into distinct phases, ReAct interleaves them in a loop: the model produces a Thought (internal reasoning about what to do), then an Action (a tool call), then receives an Observation (the tool's output), then produces the next Thought. This continues until the agent reaches a final answer.

ReAct's power comes from making the model's reasoning visible and interruptible. You can read the thought chain to understand why a particular tool was called, which transforms debugging from guesswork into inspection. The model can self-correct mid-loop: if an observation is unexpected, the next thought can revise strategy without discarding prior context. Most major frameworks — LangChain, LlamaIndex, CrewAI, and the Anthropic Claude Agent SDK — implement ReAct or a close variant internally. Understanding the underlying pattern lets you tune and debug behavior that frameworks often obscure.

Image: File:Co-storm workflow (Wikipedia-like article draft-generating AI).jpg — Stanford Open Virtual Assistant Lab (MIT), via Wikimedia Commons

Pattern 2: Least-Privilege Tool Design

The most underappreciated design surface in agentic AI is the tool itself. A tool is not just an API endpoint — it is a capability with a name, a natural-language description (which the LLM uses to decide when to invoke it), a parameter schema, and an implicit authorization scope. Poor tool design creates two failure modes: tools that are never invoked because their descriptions do not match the model's internal framing of the task, and tools that are invoked incorrectly because their schemas are ambiguous.

A 2026 arXiv paper ("When Lower Privileges Suffice: Investigating Over-Privileged Tool Selection in LLM Agents," arXiv:2606.20023) introduced a critical security dimension: LLM agents consistently select tools with broader permissions than the task requires. An agent asked to "read the latest customer email" may invoke a tool that also has write and delete capabilities, when a read-only variant would have been sufficient. This over-privileged tool selection has real security implications — prompt injection or jailbreak attempts can exploit the gap between what the user intended and what the agent has permission to do.

The principle of least privilege maps directly to agentic tool design:

• Define narrow, single-responsibility tools rather than broad multi-action ones
• Expose read-only variants separately from write variants
• Make descriptions unambiguous about what each tool does and does not do
• Enforce authorization inside the tool implementation, not only in the system prompt

Pattern 3: Tool Registry for Scale

As agentic systems grow, tool sprawl becomes a real operational problem. A 2025 arXiv paper ("ToolRegistry: A Protocol-Agnostic Tool Management Library for Function-Calling LLMs," arXiv:2507.10593) introduced the concept of a structured tool registry: a centralized, versioned catalog of tool definitions that agents query at runtime and developers manage independently of any specific LLM or framework.

Without a registry, tool definitions scatter across agent configurations and system prompts. Updating an API changes the schema, and that change must be manually propagated to every agent that uses the tool. A registry solves this with three capabilities:

• Version management: Tools can be versioned and deprecated independently of agent prompts
• Protocol abstraction: The same tool can be exposed via OpenAI function-calling format, Anthropic tool-use format, or MCP without duplicating definitions
• Dynamic discovery: Agents query available capabilities at runtime rather than having them statically embedded in a system prompt that grows unbounded

Pattern 4: Memory Architecture

Single-turn LLM calls have no memory problem. Agents accumulate state across many tool calls, and that state must be managed deliberately. In practice, production agentic systems use several memory tiers:

• Working memory (context window): The active conversation and tool call history. Grows with every step. The primary engineering constraint.
• External memory (retrieval): Documents, notes, or prior session data stored in a vector database and retrieved on demand via embedding search.
• Episodic memory: Compressed summaries of past sessions or completed tasks, used to inform current behavior without replaying full histories.
• Semantic memory: Persistent facts — user preferences, domain knowledge, invariants — that should always be available regardless of conversation length.

The practical failure mode is keeping too much in-context. Most production systems err this way, degrading performance and driving up cost. A disciplined approach aggressively summarizes completed subtask results rather than carrying raw tool outputs forward, and retrieves long-term memory on demand rather than prepending it to every prompt.

Pattern 5: Multi-Agent Orchestration

The Co-STORM system (shown above, from Stanford Open Virtual Assistant Lab) illustrates one of the most sophisticated multi-agent patterns: a network of specialized agents — AI Expert, domain specialist, Moderator — that maintain a shared discourse history and take turns generating, critiquing, and refining content to produce a cited research report. The orchestrator-worker pattern separates responsibility cleanly: the orchestrator manages flow and shared state; workers execute focused subtasks with limited, purpose-built context.

In production engineering, the key design decisions for multi-agent systems are:

• Whether to use a centralized orchestrator (simpler coordination, single point of failure) or peer-to-peer coordination (more resilient, harder to reason about)
• How to handle contradictory outputs between agents — via voting, a tiebreaker agent, or escalation
• What shared context each agent needs versus what can be withheld to reduce cost and sharpen focus
• How to propagate errors upward without triggering cascading failures across the agent network

Image: File:Chatbot Arena main UI.png — Public domain, via Wikimedia Commons

Frequently Asked Questions

When should I use ReAct versus a Plan-and-Execute pattern?

ReAct is the right default for most tasks. It handles uncertainty well — the model adapts mid-task based on what it observes. Plan-and-Execute is better when you want to inspect and validate the full execution plan before any action is taken, or when partial execution of a wrong plan carries high cost. Modifying a production database warrants plan-first review with human confirmation. Researching a question does not. For irreversible or high-stakes actions specifically, combine Plan-and-Execute with a human-in-the-loop gate before the execution phase begins.

How do I prevent my agent from taking unintended actions?

The most durable defense is narrow tool design. If a tool only exposes the capability the agent legitimately needs (read-only email access, not delete), the worst-case error from a confused or manipulated agent is bounded at the tool level. Layer this with input validation inside tool implementations themselves, explicit human confirmation gates for irreversible actions, and comprehensive audit logging so any unintended action can be detected and replayed for postmortem. Do not rely solely on system prompt instructions to restrict behavior — they can be overridden by adversarially crafted inputs reaching the model.

What is the right way to handle tool call failures in an agent loop?

For transient failures — network errors, rate limits, temporary service unavailability — implement retry with exponential backoff and a retry budget. For semantic failures, where the tool returned a result but not the one the agent expected, the ReAct pattern handles this naturally: the observation is passed back to the model, which reasons about the unexpected result and can try a different approach or tool. Always set a maximum iteration budget to prevent infinite loops, and define explicit terminal conditions for both success and graceful failure so the agent knows when to stop and report rather than loop indefinitely.

Bottom Line

Agentic AI is no longer a research novelty — it is a production engineering discipline, and the design patterns are mature enough to be prescriptive. We recommend that any team building LLM agents start with ReAct as the default reasoning loop, invest seriously in tool schema design and least-privilege scoping before worrying about prompt optimization, implement a tool registry before the tool count exceeds ten, and treat memory management as a first-class architectural concern from the start rather than retrofitting it later. The research literature — from the original ReAct paper through the latest 2026 work on over-privileged tool selection — provides a solid, evidence-grounded foundation. In a field moving this fast, tracking arXiv is a practical career skill for engineers building in this space.

Disclaimer: This article is for informational purposes only. Technology landscapes change rapidly; verify information with official sources before making technical decisions.