Brian Jagger
I have reviewed dozens of agentic AI architectures in the last two years, and the pattern is striking. The systems that survive contact with production share an architectural discipline that is recognisable from the first slide. The systems that fail share a different and equally recognisable pattern: clever model usage, ad hoc tool integration, no memory strategy, no observability, and a deployment plan that amounts to “ship it and watch the dashboards we have not built yet.”
Agentic AI Architecture: Components, Patterns & Best Practices
This article is the architectural reference I wish every team had before they started building. I will walk you through a reference architecture with all the components a production agentic system needs, the five architecture patterns that cover almost every real deployment (single-agent, hierarchical, peer-to-peer, debate, ensemble), where vector databases fit, when to use which pattern, capacity planning, and the observability stack that is non-negotiable. I will be specific about trade-offs and opinionated about defaults, because in my experience the cost of being vague about architecture is paid many times over in production incidents.
If you are an AI solution architect, an engineering manager, or a senior engineer about to lead an agentic AI build, this is the article to read first.
The reference architecture, end to end
Every production agentic system I have helped design has the same component skeleton. The details vary; the skeleton does not.
The seven components:
- The foundation model (the reasoning engine)
- The planner and orchestration layer (the control flow)
- The tool registry (the action surface)
- The memory store (working, episodic, semantic)
- The observability stack (tracing, metrics, evaluation)
- The governance and audit layer (auth, policy, compliance)
- The user interface (chat, embedded UI, async notifications)
I draw this as a diagram on the first day of every architecture engagement. The exercise of placing each system component in the right box surfaces the gaps. The systems that fail usually have a missing or hand-waved component in this list. The systems that succeed treat every component as a first-class engineering concern.
“If your architecture diagram has fewer than seven components, you have an immature design. If it has more than fifteen, you have an over-engineered design. The right answer almost always sits in this range.”
The foundation model layer
The foundation model is the reasoning engine. In 2026, the dominant choices are GPT-5, Claude Opus 4 and Sonnet 4, Gemini 2.5, and a handful of open-source frontier models. The choice matters less than people assume, and matters in ways most teams underestimate.
What matters in the foundation model choice:
- Reasoning quality on the specific class of task
- Tool-calling reliability (structured output adherence)
- Latency at the required token budget
- Cost per token at expected volume
- Data residency and contractual terms
What matters less than people assume:
- Marginal benchmark improvements
- The model lab’s brand
- The marketing claims around “agentic capability”
I push teams to run the candidate models on their own task set rather than relying on public benchmarks. The benchmark differences are small. The differences on specific real workloads can be large and surprising.
For most production agents, I recommend designing for model swappability from day one. The abstraction over the model API is usually trivial. The pay-off when prices drop or capabilities shift is real.
The planner and orchestration layer
The planner is the control flow. It is the part of the system that decides what the model is asked to do next, what tools are made available, and when to stop. It is the heart of agentic architecture.
The dominant implementations in 2026:
- LangGraph for explicit graph-based state machines
- The OpenAI Agents SDK for production-grade orchestration on OpenAI models
- The Anthropic Claude Agent SDK for production on Claude
- CrewAI and AutoGen for multi-agent setups
- Custom orchestration built on raw model APIs
I have a strong preference for explicit, graph-based orchestration over implicit, prompt-driven orchestration. The reason is operational: when a graph-based system fails, you can point at the node that failed. When a prompt-driven system fails, you have to read traces and guess.
For a deeper look at framework choice, see LangChain vs LangGraph 2026.
The tool registry
The tool registry is the catalogue of capabilities the agent can call. It is the action surface of the system, and the boundary at which the agent meets the rest of your infrastructure.
A good tool registry includes:
- A clear schema for each tool (name, description, parameters, return type)
- Documentation that the model can read at runtime
- Versioning so tools can evolve without breaking agents
- Authorisation policies tied to the calling agent and user
- Telemetry per tool (latency, error rate, success rate)
- Cost attribution per tool call
The tool registry is the part of the architecture I see most often built ad hoc, with tools defined inline in the agent code, no documentation, no versioning, and no telemetry. This is fine for a prototype. It becomes a maintenance nightmare in production.
“The maturity of a team’s tool registry is the single best predictor of whether the agent will still be running in twelve months. Tools you cannot version are tools you cannot evolve.”
The memory store
I covered the three kinds of memory (working, episodic, semantic) in detail in how AI agents work. Architecturally, each kind maps to different storage:
| Memory type | Typical storage | Access pattern |
|---|---|---|
| Working | Context window, scratchpad | In-task only |
| Episodic | Event log, structured DB | Query by user, task, time |
| Semantic | Vector DB | Similarity search |
The architectural mistake I see most often is dumping all three into a single vector database. Vector DBs are great for semantic similarity. They are poor for “give me the last five things this user did” (which is a structured query) and irrelevant for working memory (which lives in the model context).
A clean memory architecture has separate stores with separate access patterns, all behind a memory abstraction the agent calls explicitly. Letting the agent decide which kind of memory to query is a feature, not a complication.
The observability stack
Observability for agents is different from observability for traditional services. Traditional observability assumes deterministic execution: same input, same output, predictable failure modes. Agents have none of those properties. Your observability has to capture the non-determinism explicitly.
The minimum stack I require:
- Per-task tracing: every model call, every tool call, every observation
- Cost tracking: tokens per call, dollars per task
- Outcome tracking: success, failure, escalation, with reasons
- Latency: per-step and end-to-end distributions
- Evaluation harness: a representative task set that runs on every release
- Dashboards: completion rate, cost per task, intervention rate, by use case
Tools that I see used at scale: LangSmith, Langfuse, Arize Phoenix, Datadog (with LLM integrations), Helicone. Pick one, integrate it from the start, and treat the traces as primary engineering artefacts.
I have a rule: no agent reaches production until the observability dashboard exists, and a senior engineer has spent at least a week reading traces from the staging environment. The teams that follow this rule ship reliable agents. The teams that skip it ship demos.
The governance and audit layer
The governance layer is the part of the architecture that handles authentication, authorisation, policy enforcement, audit logging, and compliance. It is the layer that lets you deploy an agent in a regulated environment without giving your legal team a heart attack.
A mature governance layer enforces:
- User identity propagation from the calling user to every tool call
- Scope and permission policies (this agent can read but not write to system X)
- Action thresholds (refunds over 1000 require human approval)
- Audit logs that record who asked, what the agent did, and what the outcome was
- Policy enforcement that runs before the action, not after
The governance layer is often the thinnest in early designs and the thickest in mature ones. Teams that under-invest here discover, at the wrong moment, that they cannot answer the question “what did this agent do for customer X last Tuesday.” That question gets asked more often than you think.
Pattern 1: single-agent architecture
The single-agent pattern is one agent with a tool set, a memory store, and a goal. It is the simplest pattern and the right starting point for almost every project.
When to use it:
- The task can be handled by one specialist agent
- The tool count is manageable (under 20)
- You are early in the project and want to ship
Strengths:
- Simple to design, build, evaluate
- Single trace per task makes debugging easy
- Lower cost than multi-agent
- Fewer failure modes
Weaknesses:
- Scales poorly past 20 tools
- Cannot easily parallelise sub-tasks
- Specialisation is limited
My default recommendation: start single-agent. Resist the urge to go multi-agent until the single-agent design has provably hit a wall.
Pattern 2: hierarchical multi-agent
Hierarchical multi-agent puts an orchestrator agent on top, with worker agents below. The orchestrator decomposes the task, dispatches sub-tasks to workers, and assembles the results.
When to use it:
- The task naturally decomposes into specialist sub-tasks
- The tool count exceeds what a single agent can handle
- Parallel execution would meaningfully reduce latency
Strengths:
- Clean separation of concerns
- Easier to scale tool counts
- Parallelism opportunities
Weaknesses:
- Coordination overhead
- Compounded latency unless you parallelise carefully
- Cost grows quickly
- Debugging is harder
The hierarchical pattern is the most common multi-agent architecture I see in production. It works because the orchestrator is a familiar conceptual model: a manager and team members.
For CrewAI specifically, see CrewAI multi-agent tutorial.
Pattern 3: peer-to-peer multi-agent
Peer-to-peer multi-agent has multiple agents that interact as equals, often through a shared workspace or message bus. There is no fixed orchestrator.
When to use it:
- The task is fundamentally collaborative (negotiation, role-play, simulation)
- The agents represent distinct viewpoints or roles
- You are running simulations or generating training data
Strengths:
- Models complex real-world collaboration
- Useful for simulations and research
Weaknesses:
- Hard to make production-reliable
- Failure modes are very hard to predict
- Cost is high and unpredictable
Peer-to-peer is mostly a research pattern in 2026. I have seen interesting demos and a handful of production deployments in narrow domains. For most enterprise use cases, hierarchical multi-agent is a better fit.
Pattern 4: debate and critique
Debate patterns put two or more agents in adversarial roles. One produces a solution; another critiques it; a third arbitrates. The pattern is used to improve reasoning quality on hard problems.
When to use it:
- The task has measurable answers and reasoning errors are costly
- The cost of an error justifies multiple model calls
- The reasoning depth is the bottleneck
Strengths:
- Can substantially improve reasoning quality
- Surfaces errors a single agent would miss
- Useful for high-value, low-volume tasks
Weaknesses:
- Cost is 3-10x a single-agent solution
- Latency is significantly higher
- Implementation complexity is real
I see debate patterns in research-style agents, in code review automation, and in some legal and financial analysis workflows. They are not appropriate for high-volume, low-margin tasks.
Pattern 5: ensemble and routing
The ensemble pattern runs multiple agents (often different models or different prompts) on the same task and combines the results. The routing pattern decides which agent or model to use based on the task characteristics.
When to use ensemble:
- Reliability is more important than cost
- The cost of an error is high
- The marginal cost of additional inference is acceptable
When to use routing:
- Tasks vary widely in complexity
- Cost optimisation across a portfolio of tasks matters
- You want to use small models for easy tasks and large ones for hard tasks
Routing is the more important pattern in 2026, in my view. The cost differential between frontier and smaller models is large enough that intelligent routing can cut costs by 50 percent or more without harming quality. See LLM routing and orchestration patterns for a deeper look.
Where vector databases actually fit
Vector databases are necessary for semantic memory but get used inappropriately for everything else. Here is the honest architectural placement:
| Use case | Vector DB? | Alternative |
|---|---|---|
| Semantic search over docs | Yes | None |
| Retrieving “what did the agent do for user X” | No | Structured database |
| Working memory inside a task | No | Context window |
| Tool selection from a large set | Sometimes | Hierarchical routing |
| Caching past completions | Sometimes | Key-value store with embedding lookup |
The architectural mistake I see most often is using a vector database as a general memory store. The retrieval semantics do not fit. Use a vector DB for what it is good at and a structured DB for everything else.
For an architect’s view of vector DB choices, see vector databases for AI architects.
Capacity planning and cost engineering
Capacity planning for agents differs from traditional services because the cost per request is much higher and much more variable.
What to model:
- Tokens per task (broken down by step type)
- Tool calls per task
- Distribution of task complexity (P50, P90, P99)
- Model cost per token at current pricing
- Tool costs (some tools have meaningful per-call costs)
- Expected concurrency
A simple cost model:
expected_cost_per_task =
avg_tokens_in * model_price_in +
avg_tokens_out * model_price_out +
avg_tool_calls * avg_tool_cost
The P99 cost is often 5-10x the P50 cost because tasks that go badly tend to retry, reflect, and consume more tokens. Plan for the P99, not the P50. Set hard step budgets per task. Build alerting on cost-per-task anomalies.
“The teams I have seen burn six-figure unexpected bills in a single month did not plan for the P99. They planned for the demo, and the demo was a P10 task.”
For deployment and operations beyond cost, see MLOps for LLMs: deployment and monitoring.
