Most discussions about an Enterprise AI Maturity Model focus on how fast an organization can give models autonomy. In my view, that is only part of the story.

Today’s frontier AI platforms bundle software workflows and AI models together in impressive ways. That system can generate and refactor code, analyze data, write a social media post, summarize a phone call, access other systems for data, and so on.

However, for high-stakes enterprise systems, the default pattern of autonomy is fundamentally fragile. This risk of “autonomous AI systems” is something that must be mitigated in an enterprise. That’s because we deal with business processes and real people. We can’t afford mistakes we can’t control.

In this article, I’ll outline an Enterprise AI Maturity Model to steer organizations toward a scalable, deterministic AI architecture.

The Current Paradigm

The current popular design of enterprise AI systems is closer to this:

“Give the employee all the passwords along with a strongly worded employee handbook”.

With MCP (Model Context Protocol) servers – or equivalent tool/function-calling setups – the typical pattern is:

• Expose a set of tools/skills (basically APIs) with natural-language descriptions and parameter schemas.
• Give the model a system prompt that tries to constrain behavior (“only do X when Y, never do Z, be careful with…”, etc.).
• Let the 3rd-party AI system or “model” decide when to call which tool/API, with what arguments, and in what sequence.
• Monitor the system as much as you can with human in the loop or other means while it executes.

In an enterprise, this method is extremely flexible and productive for prototyping. It is also architecturally very fragile.

To understand why, we have to look at what is actually happening under the hood.

How a Typical Agentic AI Platform Works

As I mentioned earlier, we often refer to agentic platforms as “the model,” but it’s made up of a software workflow and one or more core AI models.  The models themselves are simply text predictors operating in a vacuum. They have no hands.

When an AI agent or platform performs an action, it actually does so from inside a traditional software wrapper – a harness. The harness provides a list of available tools described in text. The “AI model” itself is a complex combination of tokenizers, transformers, and various AI models.  When this system needs information – e.g. it’s been prompted to get the latest stock market data, and summarize it – it simply outputs to the harness a structured command block (like JSON). The harness intercepts this text, pauses the system execution, executes the real-world software workflow (like calling an API or modifying a file), and inserts the result back into the system, who then ultimately feeds it to the neural net (and actual AI model) that then predicts the next words.

This overall design in a much more advanced form is the one widely available from AI vendor companies such as OpenAI, Anthropic, xAI, AWS, and so on.

As you can see, the only real gate on the software system is the system itself, and the interpretation of its natural-language policy. That’s why these companies are also building strong security gates and safeguards into their systems.

In an enterprise, the runtime harness has some basic rules to maintain security and access but otherwise executes what the system suggests. We let the system generate a summary of a telephone call, fetch data from another system using an API, and so on.

This enterprise design works surprisingly well when:

• The blast radius is small or limited to test environments
• The tools are relatively simple and outcomes are easily reversible or mitigable
• The prompts haven’t been successfully attacked or corrupted

For example, code generation and refactoring, analyzing data, creating a presentation, drafting emails or social media posts, and so on. But it starts to break down as soon as the blast radius is larger and cannot easily be mitigated. Even if it works most of the time, an enterprise needs to operate deterministically, not on a prayer.

So, for anything beyond low-stakes use, especially in an enterprise, this “agentic model” must evolve to something that provides much more deterministic control.

Control vs. Capability: The 2×2 Taxonomy

I mapped AI adoption across two distinct axes:

X-Axis: Control Architecture

From left to right, the horizontal axis indicates moving from autonomy to guardrailed. As we move towards the left the system is more autonomous. The AI interprets the situation, self-selects the tools, and orchestrates the execution flow. As we move towards the right, the system is more Guardrailed. It has workflows, rules engines, deterministic software state machines, or human gatekeepers that own the control flow and side effects.

Y-Axis: AI Capability

From lower to higher, the vertical axis includes increasing AI capability. As we move higher, we have strong reasoning, complex multi-step tool usage, and wide domain coverage. And as we move lower down the vertical axis we have simpler AI capabilities such as simple assistance, classification, generation within tight bounds, or no AI at all.

Here is how we can look at the 4 quadrants:

• Quadrant 1: The Sovereign Agent (High Capability, Low Control): This is the current obsession. The model is given a sandbox for security. But this is a massive liability for core business operations. The probability of failure may seem low in testing, but the blast radius in production can be catastrophically high.
• Quadrant 2: The Enterprise Engine (High Control, High Capability): This is the target state for enterprise architecture. The system leverages the advanced capability of a frontier model or AI system, but the model cannot choose its own adventure. The control loop is externalized. This harness validates variables, checks policies deterministically, and isolates side effects before they hit real-world data.
• Quadrant 3: The Black-Box Autopilot (Low Capability, Low Control): Low-stakes controlled automation (e.g., auto-responding to emails, classifying tickets, recommending products, etc.). This introduces low risk failure modes while delivering reasonable cost savings and revenue upside.
• Quadrant 4: Traditional Automation (Low Capability, High control): Standard SaaS workflows and rule-based systems leverage AI but are safe and highly predictable. They often lack the profound efficiency gains of deep reasoning chains.

How to Get There? The 5 Levels of an Enterprise AI Maturity Model

I designed the model in 5 steps as below.

True enterprise maturity does not mean marching toward autonomous agents. For high-stakes organizations such as global financial institutions, unconstrained autonomy may represent an architectural failure.

Instead, maturity means moving toward scalable, deterministic, and verifiable systems where AI handles the cognitive weight but software engineering retains the control architecture.

Level 1: Assisted Execution

This level is about 100% externalized (Human-in-the-loop) control. The model is an inline generator. Humans write the prompts, the model outputs text or code, and the human manually reviews, copies, and pastes it into the execution environment.

Blast Radius: Completely contained by human reviews.

Level 2: Human-Validated Function Calling

This level is where the control is partially externalized with human guardrails.

Architecture at this level includes a model that can parse a user request and generate a structured output (like a JSON payload to fetch an account record, or a new social media post generated by the model). However, the harness intercepts the payload and forces a human-in-the-loop checkpoint as a review. The tool does not execute until a person clicks “Approve.”

An example could be a SaaS platform that is allowing the user to generate new question descriptions for a quiz they are creating. Or a CRM platform generating an email that is verified and edited by the user before sending.

Blast Radius: Minor. Restricted to individuals, Actions are authenticated and authorized by an active session.

Level 3: Unstructured Autonomy (popular today)

At this level the control is largely provided by the model and the instructions it has been given. This is a pretty popular level to operate at today but also potentially dangerous (hence colored in amber).

In the architecture at this level, the system enters a multi-step loop either autonomously or weakly orchestrated by a software program. It reads a prompt, generates a tool or API call, receives the system payload back from the harness, evaluates the data, and loops until the task is complete. One can think of Claude skills and MCP servers at this level.

This is the framework that dominates today. Claude Code and Antigravity typically operate at Level 3 (and a little of level 4). Their purpose is to navigate unpredictable environments.

For example, they could read a website, access data through an API, generate text, and update a Confluence page, or a WordPress site. A code agent can look at a file, realize a function is broken, autonomously decide to check a different file, run a terminal command, and fix the bug, with some approvals and refinements from the users. An insurance underwriter may process risk pricing tables by using AI agents.

The outputs are mostly accurate, and pass multiple checkpoints before going live. If we restricted these agents to a more rigid state machine, they would become useless for productivity higher than level 1 or 2.

Blast Radius: Potentially large. The models are vulnerable to prompt failures, inaccuracies left unchecked, hallucinations that amplify the errors, IP violations, and unintended side effects if the tools or API exposed have access to read or modify things they shouldn’t. These tools can often read local files with passwords or credentials in them unless configured correctly.

Hence, for an enterprise, this level is actually a development phase, not an operational tier we should think of as our final state for critical workflows.

Level 4: Policy-Enforced Agents

The control at this level is hybrid and enforced not just by humans but software enforced policies: Model proposes, external policy decides.

In this architecture, the model can still ideate multi-step paths, but the software harness stops relying only on system prompts and configuration files used by models for safety. Requests and outputs generated by the model are parsed  against strict data access rules and layers.

For example, we could use policy engines such as Open Policy Agent (OPA). Every time the model predicts that it needs to call a tool, the harness pauses execution and tests the parameters against immutable business rules. If an unauthorized transaction or access tier is requested, the policy engine issues a hard rejection.

This also protects against traditional prompt injection attacks. At lower maturity levels, a malicious user can trick an AI model into believing it has administrative rights, causing it to willingly output commands it shouldn’t. At Level 4, however, the AI model can be entirely convinced it is a super-user and output a flawless tool command, but it is physically incapable of bypassing the outer harness and policy checks. This guarantees that while AI remains free to reason and strategize dynamically, its operational blast radius is governed by traditional software engineering.

Blast Radius: Potentially large but controlled by business logic, not AI model.

Level 5: Fully Orchestrated Workflows

The control at this maturity level is 100% externalized or bounded by enterprise orchestration while allowing AI to execute cognitively intensive tasks (Top-Right Quadrant).

In this architecture, the limitation of a Level 4 ‘Policy-Enforced Agent’ is only about the capability of the traditional policy engines, for example, they can’t handle unstructured text. They can validate the parameters of a tool call (who, where, how much), but they cannot read the semantic intent inside a block of text. If a prompt injection tricks your model into generating a toxic or fraudulent message body, structured rules won’t catch it.

To cross the chasm into Level 5, we can use frameworks such as LangGraph and specialized nodes. The system routes unstructured data through specialized, semantic filters before a high-risk tool is unlocked. For example, when the model generates an email, the Level 5 harness takes that unstructured text and passes it to an isolated “Reviewer Node” whose only job is to scan for malicious intent or policy drift.

This reviewer node can also be an LLM. If the reviewer node outputs a structured validation score, the orchestrator reads that number and dynamically permits the system to move to the next step. This orchestration is made possible by native developer toolkits from major AI providers, such as the OpenAI Agents SDK and Anthropic’s Orchestrator-Worker pattern frameworks. These frameworks are LLM based but can be embedded inside traditional software harnesses to achieve the determinism we need.

At this maturity level, we allow engineers to explicitly write business logic that chokes or extends an AI’s autonomy at runtime.

For example, if a customer support thread follows a low-risk path like drafting a personalized response, the framework grants the model flexibility to generate text but verifies the content.

Similarly, if the transaction is in a high-risk category such as executing a financial transfer, the underlying state machine intercepts the execution, and enforces rigorous reviews including human intervention of financial limits, and other factors.

In summary, we force the data through a deterministic firewall or strict human-in-the-loop approval gates.

Blast Radius: Controlled. The enterprise gains the immense efficiency of autonomous loops without exposing its core infrastructure or reputation to unconstrained AI judgment.

Conclusion

It follows that any autonomous actor, whether AI or human, if run without checks, can cause unintended consequences. To prevent this, we need to build the right policy frameworks and technology architectures on how that intelligence gets applied.

An AI model is an incredibly powerful engine. When we deploy enterprise systems, we can’t rely on fixing the engine’s behavior by giving better prompts. We need to build better brakes into the software harness itself. The Enterprise AI Maturity model I outlined in this blog is about building deterministic guardrails around AI models. That way, AI innovation can be safely and efficiently put to work.

PS: I’m developing a detailed interactive maturity model which will be ready soon.