The Agentic Stack in Three Planes: Where Authority Actually Lives

Every few weeks a new “modern AI ecosystem” map goes round LinkedIn. You know the kind: a hub in the middle, a dozen spokes (LLMs, agent frameworks, RAG, embeddings, MCP, memory, vector databases, automation, observability, security) and a hundred small logos. They are useful. If you need to know which vector databases exist or which frameworks people are building agents with, a map like that saves an afternoon.

What those maps can’t show you is how the categories relate. They lay every category out as an equal spoke, so the model you choose and the policy that decides what it may do look like two items on the same shopping list. They aren’t. Some categories supply knowledge, some supply capability and a few supply permission. If your architecture diagram doesn’t separate those, your governance won’t either.

So I redraw the map in three planes.

The intelligence plane: what the agent knows

Foundation models do the reasoning and the writing. Retrieval finds the passages that matter for a question. Embeddings and vector stores make that retrieval fast and semantic. Memory carries facts from one session or step to the next.

This is where most AI budgets and most vendor conversations sit, and it’s where improvements arrive fastest. It is also the plane you should expect to change most often. Models are replaced every few months, retrieval techniques improve, and memory products are young. Design so that you can swap anything in this plane without touching the other two.

The governance question for this plane is disclosure: can the agent learn something the person it acts for shouldn’t know? A vector store built from every SharePoint site in the company, indexed without the original permissions, is a data-leak engine with a friendly interface. The control belongs in the retrieval layer (permission-aware indexing and filtering) and not in a prompt telling the model to be discreet.

The action plane: what the agent can do

Agent frameworks run the plan, act and observe loop and coordinate multiple agents. Tool protocols such as the Model Context Protocol (MCP) and OpenAPI describe the tools an agent can call, in a form a model can read. Workflow and automation engines run the long, stateful, retryable processes that agents increasingly start. And at the end sit the systems of record: ERP, CRM, identity, IT service management, payments, the places where a change is a real change.

MCP deserves a special word, because it has made this plane far easier to build and far easier to over-build. Connecting an agent to a new system used to take a project; now it takes a configuration entry. That is a real productivity gain, and it means the set of things your agents can do grows every time someone adds a server. Ask how many MCP servers your agents can reach today, and who approved each one. In many organisations nobody can answer yet, and nothing triggers a review when the set changes.

Notice the dashed line in the figure between the workflow tile and the systems of record. That’s the commit boundary: the point past which a proposal becomes a change. In most stacks it isn’t drawn at all, because the agent framework calls the system of record directly with whatever credential it was given.

The control plane: what the agent may do

The third plane is the one the ecosystem maps tend to reduce to a single spoke labelled “security” or “guardrails”. It has at least four distinct parts, and each answers a different question.

Identity and authority: who is acting, and under whose grant? Every agent needs its own workload identity, not a shared API key and not the identity of the person who deployed it. Its permissions should be expressed as grants: scoped to specific actions, tied to a named human sponsor, and set to expire. This is ordinary zero-trust thinking, as described in NIST SP 800-207, applied to a new kind of actor.

Policy and guardrails: is this action allowed, here, now? Two different mechanisms often share this label. Content guardrails filter what goes into and comes out of a model: prompt-injection detection, sensitive-data redaction, topic limits. Policy engines decide whether a proposed action is permitted, based on the action, the subject, the authority and the context. You need both, but only the second can stop a well-phrased request to do the wrong thing. Keep policy as code in a deterministic engine, such as Open Policy Agent or your platform’s equivalent, where it can be tested and versioned like any other code.

Observability and evaluation: what is the agent actually doing, and is it getting worse? Traces tell you which steps ran and how long they took; OpenTelemetry now has conventions for generative AI spans, which makes this plane much more portable. Evaluation suites tell you whether the agent still makes good proposals after a model, prompt or tool change. Observability without evaluation shows you activity. Evaluation without observability shows you a test score. You need both.

Evidence and audit: can we prove what happened, and why? Logs are written for engineers. Evidence is written for the person who will have to answer for the action: what was proposed, which grant covered it, which policy version said yes, which evidence was checked and who, if anyone, approved. In the book I call the smallest useful unit of this a minimum action evidence bundle.

Why the planes need separating

Three practical consequences follow from drawing the stack this way.

Buy and replace the top plane; own the bottom one. You will change models and frameworks several times in the next three years. Your identity model, policies and evidence standard should outlive all of them. If your control plane is implemented inside a particular agent framework, you will rebuild your governance every time you change framework.

The control plane governs the action plane, not the model. Look at the arrows in the figure: they point from the control plane to the action tiles, not to the models. You can’t reliably control what a model thinks. You can control, completely, what its proposals are allowed to become.

The commit boundary is where the planes meet. Every arrow from the action plane into a system of record should cross it. It’s the one place where identity, policy and evidence are checked together, and so it is the one place you can point to when someone asks how you know an agent didn’t do something it shouldn’t have.

A two-hour exercise

Take the architecture diagram for your most advanced agent use case and redraw it in three planes.

1. Put every component on the plane where it belongs. Arguments about placement are useful: a “guardrails” product that only filters text belongs to content policy, not to action authority.
2. Draw every path from the agent to a system of record. Mark each one that doesn’t cross a deterministic check.
3. For each path, write down the credential used and the widest thing it could do.
4. List the MCP servers and tools the agent can reach today, and who approved each one.

The usual result is a short, concrete backlog: an agent that needs its own identity, a credential that needs narrowing, two tools nobody remembers adding, and one path to production data that needs a commit boundary in front of it. That backlog is worth more than any tool map.

Try it against the platforms

The architecture explorer puts the same idea on one screen: seven layers, and how four common platforms cover each. Filter it by platform and you get the shape of this article for the stack you actually have, with a link to each product’s documentation so you can check the claim yourself. The layers where it says yours are the ones to read twice: that is where the control plane stops being something you configure and starts being something you build.

References

1. The Contextual Agentic Enterprise, Chapters 8, 11, 13 and 16.
2. Model Context Protocol (2025) Specification. https://modelcontextprotocol.io/specification
3. Open Policy Agent (n.d.) Documentation. https://www.openpolicyagent.org/docs/latest/
4. OpenTelemetry (n.d.) Semantic conventions for generative AI systems. https://opentelemetry.io/docs/specs/semconv/gen-ai/
5. NIST (2020) Zero Trust Architecture. SP 800-207. https://doi.org/10.6028/NIST.SP.800-207