In the first three parts of this series, we achieved three objectives. We described the characteristics of the AI-first company. We identified the role of AI agents in such a company. Finally, we created and refined a six-level spectrum to map the range of AI agents, from simple software automation to embodied, collaborative systems. The challenge for the AI systems architect is how to design these agents in a disciplined, scalable, and reliable manner.
Introduction: From Mapping the Territory to Building the Roads
Agents as an AI construct are not new. They have been used in intelligent systems for several decades. Despite the recent emergence of powerful development frameworks, building agents remains an artisanal craft, more recently driven by intricate prompt engineering. The crafted agents are inherently brittle and rarely scale to meet the demands of the AI-first company.
To address brittleness and scale, we need to close the gap between craft and repeatable engineering practices. We must create a set of standardized AI Agent Design Patterns that link the conceptual levels of the agent spectrum to practical, reusable implementations. This article presents a catalog of such patterns.
The article’s unique value is in:
- Providing decision-support guidance for pattern selection.
- Highlighting anti-patterns and common pitfalls.
- Showing the evolution pathways between patterns as agents increase in capability along our spectrum.
The AI System Architect’s View: Adding the Design Dimension
The previous articles focused on two personas found in the AI-first company: the AI strategist and the AI system’s user. We now need to focus on the AI system architect whose responsibility is to design the agent-based system. To get everyone on the same page, let’s start by defining what we mean by “AI Agent Design Pattern.”
An AI Agent Design Pattern is a reusable, abstracted solution to designing, organizing, coordinating, or deploying agents that perform tasks within a system. It does not focus on specific implementations (e.g., which LLM or API to use), but on how agents are structured, interact, make decisions, and evolve across various contexts.
An AI Agent Design Pattern is defined by the following dimensions:
AI Agent Design Pattern
| Dimension | Agent Role |
| Autonomy Level | See Agent Spectrum |
| Intent |
What the agent does (e.g., execute a task, coordinate others) |
| Interaction Model | How the agent interacts with the world |
| Control Architecture | Centralized vs decentralized control |
| State Management | How the agent maintains, updates, and shares context |
| Task Decomposition |
How the agent breaks down tasks (relates to autonomy level) |
| Embodiment | Software only or is physically embodied |
For every AI agent level and associated user role, the AI system architect must address certain challenges. As the table below shows, design patterns address each of these challenges.
Agent Design Pattern Examples
|
Agent Level |
User’s Role | Agent Capability | AI System Architect Challenge | Design Patterns |
| 1 | Operator | Basic Automation |
Implementing deterministic logic: Creating rigid, predefined workflows and state transitions. |
• State Machine • Rule Engine • Sequential Executor |
| 2 | Guide | Conversational Assistant |
Managing intent and dialogue: Parsing input, managing conversation state, and executing simple tools. |
• ReAct (Reason+Act) • Function Calling • Intent-Slot Filling |
| 3 | Supervisor | Contextual Adaptive |
Architecting dynamic memory: Designing systems for storing and retrieving relevant context to alter behavior. |
• Memory Vectorization • Contextual Knowledge Graph • Dynamic Scaffolding |
| 4 | Orchestrator | Coordinated Multi-Agent |
Defining roles & communication: Designing protocols and roles for multiple agents to collaborate on a task. |
• Hierarchical Model • Multi-Agent Debate • Publish & Subscribe |
| 5 | Architect | Autonomous Learning |
Building self-improvement loops: Creating mechanisms for the agent to evaluate its own performance and modify its strategy. |
• Reflective Critic • Generative Feedback Loop • Explore/Exploit |
| 6 | Mission Strategist | Emergent Collaborative |
Guiding collective intelligence: Setting ethical guardrails and high-level objectives for a system that learns its own collaborative strategies. |
• Constitutional AI • Swarm Intelligence • Dynamic Role Allocation |
How to Use the Pattern Catalog
As the performance of foundation models begins to plateau, given the constraints of publicly available data, the performance of AI agents used in the enterprise will increasingly depend on the enterprise’s proprietary data, proprietary workflows, and domain-specific feedback loops. This shift has implications for design patterns: AI agents must be customized around the specific environments, interaction models, and governance constraints of each enterprise.
The Architect’s Challenge: From Generic Models to Enterprise-Specific Agents
The literature on agent design patterns is already substantial, including for patterns tied to LLMs or multi-agent systems. Generic agent design knowledge is valuable. However, the AI architect’s primary challenge is to select and adapt design patterns to:
- Integrate proprietary data securely and effectively.
- Embed within domain-specific workflows.
- Balance autonomy with the oversight models of the enterprise.
This framing enables the AI architect to move beyond static pattern knowledge toward dynamic pattern orchestration, choosing the right approach for the current agent level while planning for future evolution.
Four Classes of AI Agent Design Patterns
We organized design patterns into four classes:
- Foundational patterns (used for building reasoning agents and addressing situational adaptation).
- Organizational patterns (used for building various types of collaborating agents).
- Evolutionary patterns (used for building learning agents).
- Interface and Embodiment patterns (used for designing agents that interact physically with the world).
Deconstructing a Pattern: A Practical Example
Before diving into the catalog, provided as an Appendix, it is important to see how the dimensions introduced in Section 2 map onto a real pattern. The example below uses the “Hierarchical Model” pattern from Level 4, Orchestrator, where the agent’s role is to delegate tasks to lower-level agents and coordinate workflows.
| Dimension |
Agent Role |
| Autonomy Level | High in task execution, medium in goal setting |
| Intent | Break complex problems into manageable subtasks |
| Interaction Model | Structured inter-agent communication |
| Control Architecture | Hierarchical; top-level agent coordinates specialized agents |
| State Management | Shared state or blackboard for subtask progress |
| Task Decomposition | Multi-level, from broad objectives to atomic actions |
| Embodiment | Software-only or hybrid |
This example demonstrates how the dimensions provide a complete architectural profile of the pattern. The same approach is used in the Appendix to define each pattern in decision-support terms.
Conclusion
AI agent design patterns are building blocks for enterprise capability growth. As AI-first enterprises expand their AI efforts from prompting foundation models toward developing proprietary agent-driven workflows, AI agent design patterns become the critical link between the conceptual levels of our agent spectrum to practical, reusable implementations of scalable, robust agents. Our decision-support framework offers the AI system architect a tool for navigating design trade-offs today while anticipating tomorrow’s enterprise demands.
Appendix: AI Agent Design Patterns with Selection Heuristics, Pitfalls, and Evolution Paths
Foundational Patterns (Reasoning agents and situational adaptation)
| Agent Level | Pattern Name | When to Use | Common Pitfalls | Next Step in Evolution |
| 1 | State Machine | Tasks are deterministic, fully understood, and require predictable transitions (e.g., kiosk interfaces, process automation). | Hardcoding too many states, making the system brittle; using it for environments that require adaptation or handling unseen inputs.
|
Add contextual triggers or event-driven logic to transition toward an Interactive Agent. |
| Rule Engine | Decision-making can be captured as explicit if–then–else rules; easy for domain experts to modify. | Rule explosion in complex domains: rules that conflict or lack a resolution mechanism. | Introduce probabilistic or learning-based decision modules to move toward a Contextual Adaptive Agent. | |
| Sequential Executor | Linear workflows that must execute in a fixed order without deviation (e.g., data ETL pipelines). | Fragility when tasks fail mid-sequence; no provision for reordering or skipping steps. | Wrap sequence steps in a planning module for flexibility and error handling. | |
| 2 | ReAct | Tasks require both reasoning & tool use, with transparency in intermediate steps. | Over-reliance on LLM reasoning for domains requiring deterministic precision; verbosity in reasoning traces. | Augment with persistent memory to transition into a Contextual Adaptive Agent. |
| Function Calling | Agent must integrate with external APIs/tools to perform actions based on user intent. | Poor schema design for function inputs; too many functions causing intent confusion. | Introduce intent recognition and context management for adaptive decision-making. | |
| Slot Filling | Structured tasks where user intent maps to a fixed set of parameters (slots) before execution. | Rigid slot definitions that fail when user requests don’t match; lack of disambiguation strategies. | Expand to multi-intent handling and contextual slot adaptation. | |
| 3 | Memory Vectorization | The agent must recall past events, conversations, or facts to influence current behavior. | Storing irrelevant or low-quality context; vector search that returns noisy matches. | Add semantic filtering and reasoning over memory for deeper adaptation. |
| Contextual Knowledge Graph | Tasks require a structured, relational context for reasoning (e.g., linking entities, events, relationships). | Out-of-date graph data; over-complication with unnecessary relationships. | Pair with a planning module to drive multi-step reasoning. | |
| Dynamic Scaffolding | Agent dynamically creates or modifies its subroutines or reasoning paths. | Poor constraint management leading to runaway complexity; unpredictable performance. | Integrate scaffolding with coordinated multi-agent orchestration. |
Organizational Patterns (Collaboration between agents)
| Agent Level | Pattern Name | When to Use | Common Pitfalls | Next Step in Evolution |
| 4 | Hierarchical Model | Clear task decomposition exists; tasks can be delegated to specialized agents. | Single point of failure in top-level orchestrator; communication bottlenecks. | Introduce decentralized role negotiation for autonomy. |
| Multi-Agent Debate | Problems require weighing multiple perspectives or expertise areas | Endless debate loops without convergence; lack of scoring/ranking criteria | Add consensus or voting mechanisms for faster decision resolution | |
| Pub/Sub | Multiple agents must react to shared events without tight coupling | Event overload causing performance issues; poorly defined event schemas | Layer in priority or relevance filters to handle complex environments |
Evolutionary Patterns (Learning and adaptation)
| Agent Level | Pattern Name | When to Use | Common Pitfalls | Next Step in Evolution |
| 5 | Reflective Critic | Tasks benefit from iterative self-evaluation and output refinement. | Excessive self-critique loops; no grounding in objective performance metrics. | Combine with multi-agent peer review to evolve toward collaborative systems. |
| Generative Feedback Loop | Continuous learning from both successes and failures is needed. | Learning from biased or poor-quality feedback, drift from intended goals. | Incorporate feedback from other agents to improve collaborative performance. | |
| Explore/Exploit | Agent balances new strategies with exploiting known good ones | Over-exploration wastes resources; over-exploitation misses innovation opportunities | Transition to multi-agent learning where agents share discoveries. | |
| 6 | Constitutional AI | AI must align actions with predefined ethical or operational principles. | Overly vague or conflicting constitutional rules; no enforcement mechanism. | Embed constitutional constraints directly into emergent collaborative systems. |
| Swarm Intelligence | Large-scale coordination with no central controller; robustness through redundancy. | Emergent behaviors misaligned with objectives; inability to debug. | Add dynamic role allocation for adaptive swarm composition. | |
| Dynamic Role Allocation | Agents in a collective must shift roles based on real-time needs. | Excessive churn in roles causes instability; unclear role definition. | Integrate with swarm frameworks to combine adaptability with robustness. |
Interface & Embodiment Patterns (Physical interaction, sensors, and actuation)
| Agent Level | Pattern Name | When to Use | Common Pitfalls | Next Step in Evolution |
| 1-3 | Subsumption Architecture | Embodied agents in dynamic, unpredictable environments | Rigid priority layers causing conflicts; difficulty adding new layers | Add contextual decision-making above reactive layers |
| 2-5 | Event-Driven Autonomy | Energy/resource-constrained agents that act only on relevant triggers. | Missed events due to poor sensor coverage; event storms overloading the agent. | Combine with predictive models for proactive behavior. |
| 3-6 | Digital Twin Synchronization | Embodied agents requiring simulation-based planning or remote monitoring. | Desynchronization between twin and physical system; computational cost of updates. |