AI Agent Architecture Patterns Explained

What Architecture Patterns Actually Solve

Every AI agent, regardless of its purpose, faces the same set of structural questions. How does the agent decide what to do next? How does it interact with external tools and data sources? How does it handle failures partway through a task? How does it coordinate with other agents if the task requires collaboration? Architecture patterns provide standardized answers to these questions.

The value of patterns comes from their predictability. When a team adopts the supervisor pattern, everyone on the team immediately understands the roles involved (supervisor and workers), the communication flow (supervisor delegates tasks, workers report results), and the failure model (supervisor detects worker failures and takes corrective action). This shared understanding reduces design time, simplifies code reviews, and makes it easier to onboard new team members. Without patterns, each agent system is a unique snowflake that requires extensive documentation and tribal knowledge to understand.

Patterns also provide a common vocabulary for discussing architectural tradeoffs. Saying "we should switch from a pipeline to a supervisor pattern for this workflow" communicates a specific set of structural changes in a single sentence. The alternative is a lengthy description of exactly how tasks should be decomposed, routed, monitored, and reassembled. The vocabulary that patterns provide is as valuable as the patterns themselves.

The Landscape of Agent Patterns

Agent architecture patterns fall into two broad categories: structural patterns that define how agents relate to each other, and runtime patterns that define how agents execute over time. Structural patterns answer questions about composition and coordination. Runtime patterns answer questions about scheduling, activation, and state management.

The major structural patterns are single-agent, multi-agent, supervisor, and pipeline. Single-agent is the simplest: one agent, one task, one execution loop. Multi-agent distributes work across specialized agents that collaborate. Supervisor adds management oversight to multi-agent systems. Pipeline chains agents sequentially so each stage transforms the output of the previous stage.

The major runtime patterns are event-driven, queue-based, GenServer, and tick-based. Event-driven agents activate in response to external triggers. Queue-based agents pull tasks from a shared queue. GenServer agents maintain persistent state as long-running processes. Tick-based agents wake on a schedule to check conditions and take action.

These categories are not mutually exclusive. A production system typically combines structural and runtime patterns. A multi-agent system with a supervisor might use event-driven activation for its supervisor, queue-based task distribution for its workers, and GenServer state management for agents that need to maintain context across multiple interactions. The patterns are composable building blocks, not rigid templates.

Structural Patterns in Detail

The single-agent pattern wraps a language model in an observe-decide-act loop with access to a set of tools. The agent receives a task, reasons about what to do, takes an action (usually a tool call), observes the result, and repeats until the task is complete. This pattern handles a remarkable range of workloads. Code generation, document analysis, customer support, data extraction, and content creation all fit naturally into a single-agent loop. The pattern starts to strain when tasks require more context than a single model window can hold, when different subtasks require fundamentally different model configurations, or when parallelism would significantly improve throughput.

The multi-agent pattern distributes work across specialized agents. Each agent has its own prompt, tools, and model configuration optimized for a specific type of work. A research agent excels at gathering and synthesizing information. A code agent excels at writing and debugging software. A review agent excels at finding errors and suggesting improvements. Multi-agent systems achieve capabilities that no single agent could match, but they introduce coordination challenges that do not exist in single-agent systems. Agents must share context, agree on task decomposition, handle conflicting outputs, and merge their work into a coherent result.

The supervisor pattern addresses the coordination and reliability challenges of multi-agent systems by introducing a management agent. The supervisor does not do the work itself. It creates workers, assigns tasks, monitors progress, detects failures, and takes corrective action. When a worker agent crashes, the supervisor can restart it or reassign its task to another worker. When a worker produces incorrect output, the supervisor can request a retry with additional guidance. The supervisor pattern is directly inspired by Erlang/OTP's supervision trees, where the same concepts have proven their value over decades of use in telecommunications and distributed systems.

The pipeline pattern arranges agents in a sequential chain. Each agent in the pipeline performs a specific transformation: extracting data, enriching it with additional context, analyzing it, formatting it, and validating the result. Pipelines excel when the task has a natural sequential structure and when each stage requires a meaningfully different type of processing. They are easy to build, easy to debug (you can inspect the data between any two stages), and easy to extend by adding new stages. The main limitations are that pipelines cannot exploit parallelism and that a failure at any stage blocks all downstream processing.

Runtime Patterns in Detail

The event-driven pattern activates agents in response to external events: an incoming email, a webhook notification, a database change, or a user request. The agent processes the event and then returns to an idle state until the next event arrives. This pattern is resource-efficient because agents only consume compute when there is actual work to do. It is also naturally responsive because processing begins as soon as the event arrives. Event-driven agents need careful design around context resumption, since the agent must quickly understand the context of each event without maintaining continuous state.

The queue-based pattern decouples task submission from task execution. Producers push tasks onto a queue. Consumer agents pull tasks from the queue, process them, and acknowledge completion. If a consumer fails during processing, the task returns to the queue automatically. This pattern provides built-in fault tolerance, load balancing, and backpressure. When the queue grows faster than consumers can process it, you add more consumers. When demand drops, consumers sit idle. Queue-based systems are the backbone of scalable agent deployments that need to handle variable workloads reliably.

The GenServer pattern models agents as stateful processes with a message-passing interface. Each agent maintains its own state, processes messages sequentially, and updates its state atomically with each message. This eliminates concurrency bugs within a single agent because there is no shared mutable state. The pattern comes from the Erlang ecosystem, where GenServers power everything from phone switches to messaging platforms serving hundreds of millions of users. Applied to AI agents, it provides a clean model for agents that need to maintain complex state: conversation histories, task progress, coordination state, or resource allocations.

The tick-based pattern runs agents on a fixed schedule. Every N seconds or minutes, the agent wakes up, evaluates its environment, decides if action is needed, and either acts or goes back to sleep. This pattern is ideal for monitoring and maintenance tasks: checking system health, reviewing queued items, generating periodic reports, or cleaning up stale resources. Tick-based agents are simple to implement and easy to reason about, but they introduce latency proportional to the tick interval and waste resources on ticks where no action is necessary.

Cross-Cutting Concerns

Several design concerns cut across all patterns and must be addressed regardless of which structural or runtime pattern you choose.

State management determines where agent state lives, how it is updated, and what happens to it during failures. Every pattern involves state in some form, whether it is the current position in a pipeline, the contents of a message queue, the internal state of a GenServer, or the accumulated context of a single-agent loop. The choice between in-memory, persisted, and distributed state has profound implications for performance, reliability, and complexity.

Prompt composition addresses how agent behavior is defined through modular, reusable prompt components rather than monolithic text blocks. As agents become more complex, maintaining a single prompt becomes untenable. Prompt composition lets teams manage agent behavior the way they manage code: with modules, versioning, testing, and reuse.

Hot configuration reload enables changes to agent behavior without system restarts. In production, you need to update prompts, adjust parameters, modify tool configurations, and change routing rules while agents are actively processing tasks. Hot reload mechanisms make this possible without losing in-flight work or creating downtime.

Combining Patterns Effectively

Production agent systems rarely use a single pattern in isolation. The most robust architectures combine patterns at different levels of the system. A common and effective combination is a supervisor pattern at the top level managing a pool of workers, where each worker uses a single-agent pattern with event-driven activation and GenServer state management.

The key to combining patterns successfully is clarity about which pattern applies at which level. The supervisor pattern governs the relationship between the manager and its workers. The single-agent pattern governs how each worker executes its assigned task. The event-driven pattern governs when workers activate. The GenServer pattern governs how workers maintain state. Each pattern answers different questions at different levels, and they compose cleanly because they address orthogonal concerns.

The opposite approach, picking a single pattern and forcing the entire system to fit it, leads to awkward compromises. A system that tries to model everything as a pipeline ends up with artificial pipeline stages that exist only to fit the pattern. A system that models everything as event-driven ends up with contrived events that trigger scheduled work. Let the workload drive the pattern selection, not the other way around.