Agentic AI architecture.

The blueprint

            ┌───────────────────────────┐
            │        Governance         │  lineage · permissions · retention
            └─────────────┬─────────────┘
            ┌─────────────┴─────────────┐
            │        Evaluation         │  golden sets · rubrics · CI gates
            └─────────────┬─────────────┘
   ┌──────────┬───────────┴───────────┬──────────┐
   │  Context │        Memory         │  Tools   │
   │  layer   │  session · durable    │  MCP     │
   └──────────┴───────────┬───────────┴──────────┘
            ┌─────────────┴─────────────┐
            │      Model + planner      │
            └───────────────────────────┘

The model sits at the bottom of this diagram deliberately. It is the most replaceable component in the system. Everything above it is what you own.

Layer 1 — the context layer

This layer answers a single question on every request: what does the agent need to know right now? It owns chunking, hybrid retrieval, reranking, freshness rules, source authority, and the token budget. Its output is not a blob of text but an assembled, attributable payload with a known cost.

Common failure: retrieval treated as a library call rather than a component with its own quality metric. If you cannot state your grounding rate and context precision, this layer is unmanaged.

Layer 2 — memory

Three tiers, not one. A scratchpad for the current task, session state for the current conversation, and durable memory for what the organisation has learned. The tiers need different retention, different permissions, and different curation. Durable memory is where compounding advantage lives — and where an unaudited liability grows if nobody owns it.

Common failure: writing everything to durable memory because it is easy, then discovering you cannot explain, expire, or delete any of it.

Layer 3 — tools and protocols

Agents need live truth and the ability to act: query a warehouse, call an internal service, open a ticket. Model Context Protocol has become the practical standard for describing those capabilities so they are not rewritten per platform. Agent-to-agent messaging is a different concern and belongs at the boundary between agents, not inside the tool layer.

Common failure: dozens of bespoke tool integrations with no shared contract, which turns every platform decision into a migration project.

Layer 4 — evaluation

Evaluation is not a launch activity. It is the layer that lets you change anything else without fear: a golden set per task, rubric scoring for open-ended output, regression gates in CI, and online monitoring with sampled human review. Teams that add it late move slowly forever, because every change becomes a negotiation instead of a test.

Layer 5 — governance

Lineage from answer to source, permissions enforced at retrieval time rather than at the UI, retention that matches policy, and an audit trail that survives a question from legal six months later. Governance is not a brake on this architecture. It is the reason the architecture is allowed to reach production data at all.

Multi-agent: only after the seams are solved

Splitting work across agents multiplies the number of handoffs, and a handoff is where context is lost. Before adding a second agent, make the context payload explicit and versioned, so what crosses the seam is a contract rather than a hope. Most multi-agent failures are not reasoning failures; they are seam failures.

An implementation order that works

• Retrieval quality first, with a measured grounding rate.
• Token budget and compaction second, so cost is defensible.
• Evaluation third — before the system gets complicated enough to need it.
• Tools through one protocol, not many adapters.
• Memory tiers with explicit retention.
• Multi-agent last, and only when a single agent is demonstrably the bottleneck.