The Enterprise AI Battle Is Moving From Models to the Control Plane

As AI moves from answering questions to performing real work, the strategic layer is shifting from model intelligence toward the infrastructure that governs identity, permissions, policies, evaluation, and accountability.

For the last few years, enterprise AI strategy has been dominated by a deceptively simple question: which model should we use? Teams compare benchmark scores, context windows, latency, multimodal capabilities, coding performance, and price per million tokens. GPT competes with Claude, Gemini competes with both, and every major model release creates another round of architecture discussions about whether an organization should switch providers.

Those questions still matter, but I think they are becoming less decisive than they were during the first phase of generative AI. The reason is that enterprises are beginning to ask AI systems to do something fundamentally different. Instead of only producing text, agents increasingly work across company systems, retrieve sensitive data, call tools, execute multi-step workflows, run asynchronously, and take actions on behalf of employees or customers.

Once that happens, the hardest questions are no longer only about intelligence. They are about authority. What systems may the agent access? Which actions may it perform? Which identity does it operate under? When must it request approval? What happens when it is uncertain? Can its decisions be audited? How much can it spend? Who owns it when something goes wrong?

These questions belong to a different architectural layer.

I think of that layer as the AI control plane.

The emerging enterprise AI stack

A useful way to understand the transition is to separate enterprise AI into three layers:

Model Layer → Agent Runtime → Control Plane

The model layer supplies intelligence. It understands language and images, reasons about problems, generates code, selects tools, interprets context, and increasingly handles complex tasks that previously required substantial workflow logic around the model.

The agent runtime turns that intelligence into execution. It manages conversations and state, exposes tools, orchestrates multi-step workflows, runs code, invokes APIs, schedules background work, coordinates sub-agents, and allows the model to continue working beyond a single request-response interaction.

The control plane governs how all of this is allowed to operate inside an organization. It defines identities, permissions, policies, approval boundaries, evaluation requirements, observability, budgets, escalation paths, publishing rules, and lifecycle controls.

Early generative-AI applications could get surprisingly far with the first layer alone. A prompt went in, text came out, and the user remained responsible for deciding what to do with the answer. Even if the model hallucinated, the blast radius was usually limited because the model itself possessed little authority.

Production agents change that relationship. An agent may now have enough context and capability to perform meaningful business operations without a human manually translating every recommendation into an action. That makes the surrounding control architecture as important as the intelligence itself.

A payroll agent illustrates the difference

Consider a payroll agent asked to correct an employee's payroll record. Understanding the request is increasingly the easy part. A capable frontier model can probably determine what the employee is asking, retrieve relevant policies, identify missing information, and propose the appropriate correction.

The difficult questions begin when the agent tries to act. Is the requester authorized to modify this employee's information? Can the agent update all payroll fields or only specific ones? Should a bank-account change require stronger verification than correcting a misspelled address? Can the agent write directly into production, or must it propose a change for approval? What happens if policy documents disagree? Does the workflow vary by jurisdiction? How should an ambiguous case be escalated?

None of these questions can be solved merely by choosing a smarter model. A more intelligent model may reason about them better, but the organization still needs technical mechanisms that determine what the model is allowed to do.

The same pattern appears in customer refunds, HR cases, insurance claims, financial operations, infrastructure changes, incident response, and software deployment. As soon as AI becomes part of an operational workflow, intelligence is only one component of trust.

This is why I think enterprise AI architecture is beginning to resemble cloud architecture. Raw compute matters, but enterprises do not operate cloud infrastructure based on compute performance alone. They depend on IAM, policy enforcement, networking, deployment controls, monitoring, audit logs, budgets, service ownership, and incident response.

Agents are beginning to need the equivalent operating layer.

The major providers are already converging on this architecture

The clearest evidence for this shift is not any single feature. It is the pattern emerging across the major enterprise AI platforms.

OpenAI's July 2026 launch of Presence describes the enterprise problem explicitly: proving that agents can work is no longer enough; organizations need to make them reliable enough for high-value production work. Presence combines model reasoning with policies, guardrails, evaluations, approved actions, and escalation rules, beginning with a clearly defined job such as resolving billing issues, insurance claims, or employee IT requests. The architecture therefore treats agent behavior as something that must be constrained, evaluated, deployed, and continuously improved rather than merely prompted.

OpenAI Frontier follows the same pattern at the platform level. Its current positioning emphasizes connecting agents to systems of record, running them across real business workflows, measuring their behavior through evaluation and optimization loops, and embedding enterprise security through explicit permissions and auditable actions. Workspace Agents add another operational layer through role-based access controls, app permissions, write approvals, scheduled execution, API triggers, publishing workflows, and controls over whether an agent uses an individual's account or an agent-owned shared connection.

Google has made the architectural direction even more explicit. Gemini Enterprise Agent Platform is described as an end-to-end environment for building, deploying, governing, and optimizing enterprise agents, with Google specifically calling its governance layer a single control plane. The platform includes an Agent Registry for discovering agents and MCP servers, unique Agent Identity, Agent Gateway as a central policy-enforcement point, runtime governance policies, security scanning, audit trails, and operational monitoring. It is notable that the same platform can expose more than 200 foundation models, including models beyond Google's own families, which reinforces the idea that governance can become a durable layer above individual models.

Anthropic's enterprise direction points toward the same operational concerns. Claude Enterprise already includes role-based permissions, SSO, audit logs, integration controls, and data-governance capabilities, while Anthropic and Google have jointly demonstrated architectures where Claude agents receive scoped identities, policies are enforced at tool boundaries, and traces and audit events flow into centralized observability. The important pattern is that autonomy creates requirements around identity, authorization, monitoring, and traceability that cannot live solely inside the model.

The providers use different names and product boundaries, but they are solving increasingly similar problems. Enterprise AI is evolving from model access toward agent operations.

Capability creates governance requirements

There is a simple reason this transition is happening: the consequences of a model error change when the model gains authority.

A chatbot that produces a weak paragraph creates a quality problem. An AI assistant that drafts an incorrect email creates a review problem. An agent that actually sends that email creates an operational problem. An agent that changes payroll, deploys infrastructure, issues refunds, edits customer records, or executes code can create security, compliance, financial, and reputational problems.

The model may only have made one incorrect decision, but the surrounding system determines whether that decision becomes a harmless suggestion or a production incident.

This creates an interesting inversion in AI engineering. During the earlier phase of generative AI, much of the application stack existed to compensate for models that were not capable enough. Teams built elaborate retrieval systems, prompt chains, routers, validators, and deterministic workflows because the model needed help performing complex tasks.

As model capability improves, another architectural problem becomes more important: how do we safely give increasingly capable systems more authority?

A strong model can make an agent more useful, but it can also make the consequences of excessive permissions larger. The more independently an agent can reason, navigate systems, and recover from obstacles, the less sensible it becomes to rely on behavioral instructions alone as the organization's primary control mechanism.

This is why governance is not a tax added after AI becomes useful. Governance is what allows useful AI to receive more authority without creating unacceptable risk.

Prompts cannot become the enterprise policy engine

One mistake I expect many organizations to make is embedding too much business policy inside natural-language instructions.

A system prompt might tell an agent never to approve refunds above $500, never to modify production infrastructure without authorization, or never to access employee records outside the requester's scope. Those instructions are useful because they help the model reason correctly, but they should not become the final enforcement mechanism for important business rules.

If refunds above $500 require approval, the refund service should enforce that threshold. If an agent should only access employees belonging to a particular organization, the downstream authorization layer should enforce the tenant boundary. If production writes are forbidden, the credential available to the agent should not possess that capability in the first place.

The distinction is fundamental:

The prompt describes what the agent should do. The control plane determines what it can do.

Enterprise software has spent decades separating application intent from authorization. A service may request access to a resource, but IAM decides whether the request is allowed. A user interface may offer an action, but the backend still validates permission. AI should not reverse that architecture simply because natural-language models can understand security rules.

The model is a reasoning component, not the root of trust.

An AI control plane needs several different responsibilities

If enterprise agents continue moving into production workflows, I expect control planes to converge around several broad responsibilities.

The first is identity. Every important agent needs a recognizable identity rather than functioning as an anonymous extension of a shared API key. Organizations need to know which agent performed an action, which user or workflow invoked it, and what authority was delegated for that execution. Google's Agent Identity architecture is an especially direct example of this direction, providing unique managed identities so permissions and auditability can be attached to agents themselves.

The second is capability and permission management. An agent should receive access only to the data, tools, environments, and operations required for its job. Reading a CRM record and deleting a customer account are different capabilities even if they belong to the same application. The control architecture needs enough granularity to make that distinction enforceable.

The third is approval and escalation. Production agents should not operate on a binary model of either full autonomy or constant human review. Some actions can be executed automatically, some should require approval, and some situations should cause the agent to stop and escalate because uncertainty itself is meaningful. OpenAI Presence explicitly incorporates approved actions and escalation rules into its production-agent architecture, reflecting this move toward configurable autonomy.

The fourth is evaluation and release management. Once agent behavior affects real workflows, prompts, tools, models, policies, and orchestration changes should be treated as production changes. Teams need regression evaluations, simulation, controlled rollout, monitoring, and rollback. A new model may be more capable in general while still changing behavior in ways that break a specific workflow.

The fifth is observability and audit. Organizations need to reconstruct not only the final answer but the path through which an agent reached an outcome. Which context did it consume? Which tools did it invoke? What privileged operations occurred? Which policies were evaluated? Where did it escalate? How much did it spend? Google explicitly places request-response logging, data-access audit trails, health, utilization, and cost-efficiency inside its agent governance model.

Finally, the control plane needs lifecycle management. An organization with five agents can manage them informally. An organization with five thousand cannot. Agents will need owners, registries, versions, publishing controls, dependencies, evaluation suites, deprecation processes, and kill switches in much the same way organizations already manage services, APIs, cloud resources, and user identities.

At that scale, “Who created this agent?” should not be a forensic investigation.

The durable layer may sit above the model

This architecture also changes how organizations should think about model selection.

Many AI applications today are tightly coupled to a single provider:

Application → Model

A more mature agent architecture may instead look closer to:

Business Workflow → Control Plane → Agent Runtime → Model

That distinction creates optionality. A simple extraction task may use a low-cost model. A difficult investigation may escalate to a stronger reasoning model. A coding subtask may route to a specialized coding model. A high-risk decision may use a frontier model while also requiring human approval. Different models can serve different operating points while the organization's policies, audit requirements, approval rules, and workflow ownership remain stable.

Google's Agent Platform is particularly interesting in this context because its governance infrastructure sits above access to a large Model Garden rather than being synonymous with one Gemini endpoint. The platform is designed to combine agent identity, gateway policy, registry, observability, and security with a broad model-selection layer.

This suggests that model intelligence may increasingly become a replaceable component inside a more durable enterprise architecture. Models will still differ significantly, and those differences will matter. But model generations change quickly, while organizational permissions, compliance requirements, approval policies, and accountability structures evolve much more slowly.

The durable enterprise asset may therefore be less about which model an organization uses today and more about the operating system it builds around model intelligence.

This is similar to what happened in cloud infrastructure

Cloud computing provides a useful analogy, although the comparison should not be pushed too far.

Early cloud conversations often emphasized raw compute economics and the convenience of renting servers on demand. As cloud adoption matured, enterprise differentiation moved into a much broader stack: IAM, policy management, VPC architecture, logging, deployment automation, managed services, compliance tooling, cost governance, infrastructure as code, and organizational controls.

Nobody evaluates AWS, Azure, or Google Cloud solely by asking which provider offers the fastest CPU.

Raw compute is necessary but insufficient for running a large organization.

AI appears to be moving toward the same maturity curve. Model intelligence is the underlying computational resource, but enterprises need infrastructure that lets them expose that intelligence to thousands of employees, applications, workflows, and autonomous agents without losing operational control.

Google's own production-agent guidance now makes this analogy explicit in practice, arguing that moving from demos to production requires infrastructure for state, security, governance, orchestration, and operational rigor rather than model capability alone.

The enterprise competition therefore becomes larger than the leaderboard. The winning platform may not always be the one with the highest benchmark score in a given month. It may be the one that lets a security team answer who accessed what, an engineering team evaluate a behavioral change before deployment, a finance team understand agent spend, and an operator immediately stop a workflow that is behaving incorrectly.

Those properties are less exciting in a demo.

They are extremely important in production.

The competitive moat shifts toward operability

Frontier intelligence will remain strategically valuable. There will continue to be meaningful differences in reasoning, coding, multimodality, latency, context handling, tool use, and cost, and a sufficiently large capability gap can absolutely change what products are possible.

The point is not that models are becoming commodities.

The point is that model quality is no longer the whole enterprise product.

Once multiple providers can supply sufficiently capable intelligence, differentiation moves upward into the systems that make that intelligence operable. Can an organization integrate agents with its systems of record? Can permissions be inherited from existing identity architecture? Can security policies be enforced independently of the model? Can agents be evaluated before they receive more autonomy? Can their actions be inspected afterward? Can one business unit safely use different agents and models from another without creating governance chaos?

These capabilities are difficult to reproduce with a thin API wrapper.

They also become stickier as organizations scale. A company can potentially replace a model after running the necessary evaluations. Replacing the entire governance layer that encodes identities, permissions, audit requirements, deployment processes, policies, integrations, and hundreds of production workflows may be significantly harder.

That is why the control plane could become one of the most strategically important layers of enterprise AI.

Engineering leaders should start with the job, not the model

For engineering leaders, this shift changes the order in which AI architecture should be designed.

A common approach is to begin by selecting a model, building a prototype, and only later deciding what governance is needed to move it into production. That sequence makes sense during experimentation, but it becomes risky when the prototype begins performing meaningful work.

For a production agent, I would begin with the job. Define the workflow the agent is responsible for, the systems it needs, and the outcome the organization considers successful. Then define the agent's authority: what it can read, what it can change, what requires approval, what should cause escalation, and which boundaries must never depend solely on model judgment.

Next define accountability and evaluation. Who owns the agent? How do we know it is performing the job correctly? Which historical failures should become regression tests? How will a new model, prompt, tool, or policy be evaluated before release? What happens when production behavior deviates from expectations?

Only after those constraints are understood should model selection become the primary optimization problem. At that point, the team can choose intelligence, reasoning effort, latency, and economics that fit a clearly defined operating envelope.

This reverses the usual prototype mindset. Instead of asking, “What can this model do for us?” the organization asks, “What job are we willing to delegate, under what authority, and what intelligence is required to perform it?”

That is a much stronger foundation for production AI.

AI readiness may depend more on organizational architecture than model access

This perspective also changes what it means for an organization to be “AI ready.”

A company can purchase access to the strongest available models almost immediately. That does not mean it is prepared to operate agents safely at scale. If APIs have inconsistent authorization, business processes depend on undocumented tribal knowledge, production permissions are overly broad, policies cannot be translated into clear rules, and nobody owns evaluation or incident response for AI workflows, better models will not remove those constraints.

In some cases, more capable agents may expose them faster.

Conversely, an organization with well-designed APIs, strong identity boundaries, observable workflows, explicit operational policies, good engineering ownership, and mature release practices may be positioned to adopt increasingly capable agents very quickly. Its existing software architecture already provides many of the controls agents need.

The bottleneck therefore shifts. Access to intelligence becomes easier while integrating intelligence safely into an organization becomes the harder engineering problem.

This is why enterprise AI will increasingly overlap with platform engineering, security engineering, FinOps, compliance, and organizational design rather than remaining a specialized machine-learning concern.

The next abstraction layer

The terminology around this layer will continue to change. Vendors will use names such as agent platform, governance stack, agent gateway, runtime, orchestration layer, admin plane, enterprise agent system, or control plane. Some products will combine these responsibilities while others will separate them across multiple services.

The exact label matters less than the architectural function.

An AI control plane is the layer that answers a difficult organizational question:

How do we remain in control when software can reason and act?

The model determines how much intelligence the system can apply to a problem. The runtime gives that intelligence memory, tools, and the ability to execute work. The control plane determines the boundaries under which that work can happen, how it is evaluated, what happens when the agent becomes uncertain, and how the organization responds when something goes wrong.

That is why I think the next major enterprise AI competition will increasingly be fought over identity, permissions, policy enforcement, evaluation, observability, economics, escalation, and lifecycle management.

The smartest model will still matter.

But as AI moves deeper into real organizations, the more important question may become whether companies can safely put that intelligence to work at scale.

The enterprise winners may therefore be determined not only by who builds the best intelligence, but by who builds the best system for operating intelligence.