Agentic AI architecture is the design of the system around the model: the layers that decide what an agent is asked to do, what it may reach, what it is forbidden to do, how far it may act without a person, and how any of that is proved afterwards. The model is a component in this architecture. It is not the architecture, and treating it as such is the most expensive mistake I see enterprises make.
The distinction I keep returning to is this. Instructions in, results out was IT. Intent in, outcomes out is agentic AI. Once a system takes an outcome rather than a script, the architect’s job stops being the specification of steps and becomes the specification of boundaries.
Why this is not application architecture
Traditional application architecture describes a path. Given this input, the system does these things in this order, and if it does something else, that is a defect. You can draw it, test it exhaustively, and reason about it.
An agent does not work that way. It chooses its next action from what it observes, which means the same request can take a different route on Tuesday than it took on Monday. Anthropic drew the line cleanly in its guidance on building effective agents: “Workflows are systems where LLMs and tools are orchestrated through predefined code paths,” while agents direct their own process. Both are agentic systems. Only one of them removes the path from your control.
That single property changes what an architecture document is for. You are no longer describing what will happen. You are describing what cannot happen, what must be recorded, and how much rope the thing has earned. I defined the broader shift in what agentic AI actually is, and everything below is the engineering consequence of it.
The six layers
An enterprise agentic AI architecture has six layers. Most vendor diagrams cover two of them, which is why so many pilots pass a demo and fail a security review.
| Layer | What it decides | Typical components |
|---|---|---|
| Intent | What the agent is asked to do, and why | intent.md, spec, plan, CLAUDE.md or AGENTS.md |
| Capability | What the agent can reach | Tools, MCP servers, skills, subagents, plugins |
| Enforcement | What the agent cannot do | Hooks, permission rules, sandbox, agent identity, branch protection |
| Runtime | How the loop actually runs | Harness, context window and compaction, memory, orchestration |
| Evidence | How you know it worked | Evals, traces, gate logs, cost per completed task |
| Autonomy | How far it goes without a person | Tiers, control bands, escalation, rehearsed rollback |
The intent layer is where the work is defined and where the reason for it survives. The capability layer is the agent’s reach, and it is the layer everyone builds first because it is the fun one. Skills sit in this layer, not the enforcement layer; I explain why a SKILL.md is advisory by design and what to put around it. The runtime layer is the harness — the context assembly, the loop, the memory, the stopping conditions — and it decides more about outcomes than the choice of model does. The evidence layer is what turns a working demo into something you can defend. The autonomy layer is the dial, and it should move slowly.
The enforcement layer is the one that gets skipped.
The layer most teams skip
Every control in an agent system is either advisory or enforcing, and one question sorts them: can the person it constrains switch it off? A prompt, a rules file, a skill written in careful English — all advisory. They make an agent likely to behave. Nothing makes it comply.
That is not a failure of model quality. An instruction and a piece of data arrive through the same channel and the model cannot reliably tell them apart, which is why prompt injection has sat at the top of OWASP’s list of LLM risks since the list existed. The architectural answer is to stop relying on the model’s judgement for anything that must always hold, and put a deterministic check in the path instead.
In practice that means four things. Hooks that block, ask, or allow at the tool boundary. Sandboxes that the operating system enforces rather than the policy document, which is the lesson two frontier labs learned in public. Agent identity, so the log separates what the agent did from what the engineer who triggered it did. And branch protection, so the agent that wrote the code has no route to approving it.
I wrote about who owns all of this in governing the harness rather than the model. The short version: you cannot govern a probability distribution. You can govern the code around it.
More on Agentic AI Architecture
- The Definition: What agentic AI is as an enterprise workload, and why intent replaces instruction as the unit of work.
- The Vocabulary: Twenty-seven terms with one authoritative source each, because a control you cannot name is a control you cannot enforce.
- The Harness: The layer around the model that decides agent outcomes, and where the term came from.
- The Roadmap: Five stages from Prompted to Autonomous, and what each one has to prove before the next is safe.
- The Evidence: Fifty enterprise deployments mapped onto those five stages, with what separated the ones that scaled.
The protocols settled the plumbing, not the permissions
Two standards now carry most of the integration weight. The Model Context Protocol handles how an agent reaches tools and data. Agent2Agent handles how agents hand work to each other. Both sit under the same roof: the Linux Foundation formed the Agentic AI Foundation in December 2025 with MCP, goose and AGENTS.md as founding contributions, and A2A moved in on August 17, 2026.
This is genuinely good news for architects, and it is narrower news than the announcements suggest. A common protocol tells you how an agent connects. It says nothing about which agent may read which data, under whose identity, with what recorded afterwards. Those remain your design decisions, and I argued in the post on where lock-in actually moved that standardizing the connectors mostly relocates the expensive part rather than removing it.
Design the enforcement layer as though the protocol layer will change again, because it will.
Architecture is sequenced, not deployed
The mistake that produces most write-downs is not choosing the wrong component. It is installing a late-stage component on an early-stage foundation.
My Five-Stage Agentic AI Roadmap — Prompted, Piloted, Governed, Assured, Autonomous — exists because autonomy is collateralized by the controls underneath it. Each stage has to prove something before the next one is safe to attempt: that intent is captured, that the agent verifies its own work in a box, that gates are enforced in code for everyone every time, that the controls are continuously tested, and only then that a loop may close on itself. The assessment version, with five pillars scored across the five stages, is in the maturity model.
A team running an unattended loop with no managed settings has not built an advanced architecture. It has built an early one and removed the supervision.
What the architecture costs to run
One line that belongs on the architecture diagram and almost never appears: every layer above multiplies token consumption. Verifier subagents, parallel sessions, several review passes per change, a nightly eval suite with a budget of its own.
Put cost per completed task on the same dashboard as the eval pass rate from the pilot onward. Retrofitting cost attribution onto a running loop is miserable work, and the CFO asks the question in the second meeting, right after the security team finishes in the first.
The bottom line
Agentic AI architecture is boundary design. The intent layer says what is wanted, the capability layer says what can be reached, the enforcement layer says what cannot happen, the runtime layer decides how the loop behaves, the evidence layer proves it, and the autonomy layer says how far it goes alone. Get the enforcement layer wrong and none of the others matter, because the whole system reverts to hoping the model reads carefully.
My frameworks are laid out in full in my two books, Agentic AI and Earned Autonomy, and the vocabulary is in my glossary.
So take your current design and read it against those six layers. Which one is missing entirely — and is it missing because you decided you did not need it, or because nobody drew it?
Go deeper
- Agentic AI Architect: control design for enterprise agents.
- Agentic AI Case Studies: deployment evidence, one teardown at a time.
- Agentic AI P&L: cost, payback, and risk in a CFO’s voice.
- Agentic AI Governance: who owns the harness.
- Substack first access: agenticaiarch.substack.com/subscribe
© Dr. Harish Kotadia, Ph.D., All Rights Reserved, 2026.
Dr. Harish Kotadia, Ph.D., is an Enterprise AI Architect with 20+ years of IT consulting experience serving Fortune 100 clients, specializing in agentic AI systems built on Anthropic Claude, AWS Bedrock, and Google Vertex AI.
Disclaimer: This blog post is based on publicly available academic publications, vendor documentation, open standards, and news items from reputed media sources linked above. This post is intended for educational purposes, to help the enterprise agentic AI community build a shared vocabulary from public, authoritative sources.
Views and opinions expressed here are my own and do not represent those of any employer or client, past or present. The analysis presented is my independent interpretation of the published sources linked above and does not constitute legal, financial, or consulting advice of any kind.