Agent Design Patterns
Just as software architecture has established patterns — microservices, event-driven systems, pub-sub — agent design has its own emerging patterns. Knowing these patterns helps you understand why agents are built certain ways and what tradeoffs each approach involves.
The Single Agent Pattern
The simplest architecture: one agent with one model and a set of tools. You give it a goal, it plans and executes.
When it works: Tasks with clear scope, limited tools, and straightforward steps. A coding assistant, a research helper, a customer service bot.
When it breaks: Complex tasks that require different types of expertise, tasks that benefit from parallel execution, or tasks where one mistake early on cascades through later steps.
The Router Pattern
A central agent receives requests and routes them to specialized sub-agents based on the task type. Think of it as a receptionist who knows which department handles which question.
The router agent does not do the work itself — it classifies the request, selects the right handler, and returns the result. This keeps each sub-agent focused and simpler.
When it works: Systems that handle diverse request types — a support system that routes billing questions differently from technical issues.
When it breaks: When requests do not fit neatly into categories, or when the routing logic itself becomes complex.
The Pipeline Pattern
Agents are arranged in a sequence. The output of one agent becomes the input of the next. Agent A researches, Agent B analyzes, Agent C writes.
This mirrors assembly lines in manufacturing. Each agent does one thing well, and the overall quality comes from the chain.
When it works: Content creation, data processing, multi-stage analysis — any workflow with clear sequential stages.
When it breaks: When stages are tightly coupled, when errors in early stages compound, or when the pipeline needs to loop back to earlier stages.
The Debate Pattern
Two or more agents take different positions on a question. One proposes, another critiques, and a third synthesizes. This adversarial dynamic catches errors and biases that a single agent might miss.
When it works: Decision-making, code review, content editing — tasks where quality benefits from multiple perspectives.
When it breaks: When it degenerates into repetitive disagreement, or when the overhead of multiple agents is not justified by the complexity of the task.
The Swarm Pattern
Multiple agents work on the same problem simultaneously, often with different approaches. A coordinator collects their outputs and selects or merges the best result.
When it works: Problems with multiple valid approaches — research synthesis, creative brainstorming, optimization problems.
When it breaks: When coordination overhead exceeds the benefit of parallelism, or when agents duplicate effort.
The Human-in-the-Loop Pattern
The agent operates autonomously but pauses at defined checkpoints to get human approval before continuing. This is less a technical pattern and more a deployment philosophy — it balances agent capability with human judgment.
Most production agents use some form of this pattern. Full autonomy is rare outside of low-stakes tasks.
When it works: Almost always, especially for high-stakes decisions, financial transactions, or communications sent on behalf of users.
When it breaks: When the approval requests are so frequent that the human becomes a bottleneck, negating the efficiency gains of automation.
Choosing the Right Pattern
There is no universally best pattern. The choice depends on:
- Task complexity — Simple tasks need simple patterns
- Risk tolerance — High-stakes tasks need more human oversight
- Latency requirements — Pipelines add latency; single agents are faster
- Cost constraints — More agents mean more model calls mean higher costs
- Reliability needs — Simpler architectures fail more predictably
The best agent architectures start simple and add complexity only when the simpler approach demonstrably fails.