Cheap to create, expensive to manage.

Added into Microsoft 365, Google Cloud, ServiceNow, Slack, data warehouses, support queues, and custom applications, enterprise AI agents have become an operating estate that the market wants to operate. So the market is now increasingly focused on the operating aspects of agents rather than the small trick of getting an agent to respond in a chat. I just read about Microsoft Agent 365, which is framed around observing, governing, and securing agents through a unified registry. Google announced Gemini Enterprise Agent Platform, build, scale, govern, and optimize. ServiceNow is talking about AI Control Tower. LangChain describes LangSmith Fleet as the management layer for ownership, authentication, auditing, sharing, and permissions.

The layer to care about is the control plane above the builder.

The builder layer is no longer enough

For the first phase of enterprise AI, the focus was business building AI agents quickly. A platform team could create a vendor intake workflow agent in minutes. A data team could create an agent that reads from a warehouse with a click of a button. A consulting team could create a research agent within an afternoon and deploy it to Slack in minutes. The focus now moves to who owns an agent, whose credentials it uses to access systems, what systems it touches, and what happens when the owner leaves, the workflow changes, the prompt drifts, the cost spikes, or the tool that the agent was built for gets deprecated.

As agent creation gets cheap, the pressing problem of AI agent management does not go away by itself. A business team describes a workflow. A platform team wraps a Jira action. A data team grants read access to a warehouse. A consulting team builds the Slack research bot. The only thing that looked hard last quarter becomes a thing a team can ask for before lunch.

Who owns the agent?

Whose credentials does it use?

What systems can it touch?

What happens when the owner leaves, the workflow changes, the prompt drifts, the cost spikes, or the tool gets deprecated?

It turns out, agent programs are more like semi-autonomous workers than ordinary applications. They have memory and operating instructions. They access and manipulate data through APIs. They work through human collaboration surfaces, which means agent behavior crosses and spreads across app state, permissions, approvals, and the frontend runtime surfaces of applications. We have written before about enterprise agents leaving the server. The same problem shows up one level higher. The enterprise needs a single place to name, manage, govern, monitor, and eventually retire the operating agents.

The control plane is where agent creation turns into an operating model.

The market has already named the missing layer

Another way to look at the control plane is that it is the administrative surface for the set of enterprise AI agents: registry, owner, identity, policy, and all the boring bits that follow. Microsoft's Cloud Adoption Framework says every agent must be observable, governed, and secure. Leaders have to know the AI agents in the organization, who owns them, what they do, and which ones should be stopped. That is an operating model before it is a prompt-engineering checklist.

Agent 365 turns these ideas into a surface to administrate agents. Register. Manage. Permissions. Policies. Reviews. Entra. Purview. Defender. The builder of the agent becomes another object managed inside the enterprise by Agent 365's administrative surface.

Google is moving Vertex AI into the same broader control-plane view. The Gemini Enterprise Agent Platform announcement details Agent Identity, Agent Registry, Agent Gateway, runtime, memory, sandboxing, runtime monitoring, and governance. Build and connect sit in the interface, while govern, optimize, and monitor are the verbs that make it an enterprise platform.

ServiceNow approaches the problem from operations. Shadow AI, adoption problems, inefficiencies at scale, and fragmented data all have to be addressed. No surprise that the AI governance vendor also describes how to manage AI. AI Control Tower allows IT and business leaders to see what has been deployed, review usage of models and associated skills, and ask whether the work is aligned to company strategy.

LangChain's Fleet post starts from the mess created when agent programs become easy to create. The hard part becomes who owns which agents, how they authenticate across tools, who can audit what the agents are doing, and how a good agent gets shared safely. Same shape again. Registry. Identity. Permissions. Audit. Sharing. The control plane is emerging because the builder layer has finally reached critical mass.

Sprawl is the failure mode

I argue that enterprise AI fails as an unmanaged worker estate with tool access growing as semi-autonomous workers of ambiguous purposes, expanding scopes, and stale owners. These enterprise AI agents have shared identities, little or no audit trails, silent cost growth, overlapping jobs, and no clear way to be retired or decommissioned. One embarrassing misstatement by a chatbot is what everyone sees; the unmanaged worker estate with tool access is what has to be governed.

A governance maturity paper calls this agent sprawl: redundant, ungoverned, conflicting agents across business functions. A healthcare lifecycle paper describes the regulated version: duplicated agents, unclear accountability, inconsistent controls, tool permissions that persist beyond the original use case, and decommissioning tied to credential revocation and audit logging. The control-plane layers that travel across both domains are the useful part: identity registry, mediation, bounded context, runtime policy, lifecycle, decommissioning, credentials, audit logging.

Governance follows the execution path. That earlier piece matters because written policies cannot possibly know that the vendor-intake AI has just gained email capabilities through a new tool. A launch approval from three months ago does not know that a different region is using the same sales-research agent. A static spreadsheet will never know that two teams have built agents to calculate renewal risk with different scoring.

Agents act through paths. Therefore, the control plane has to live near those paths.

As an alternative to building a single massive platform for every enterprise AI problem, the control plane can be assembled from basic data structures and operating systems already lying around: identity, a registry, a gateway, observability data, CI processes, runtime policy, and existing platform management data. A company could run that inside Microsoft, Google, ServiceNow, LangSmith, or a custom internal platform. Importantly, someone in the organization needs to own the control plane, the inventory of agents, and the action boundary for that inventory.

Identity turns management into live work

Agent identity is where the conversation starts to become concrete.

Microsoft's Agent 365 sharing docs detail three forms of access: delegated access, app agent access, and an agent with its own user identity. The third one is spicy. Agents with their own identity can be added to Teams, Outlook, Office documents, SharePoint, and OneDrive. The agent can accumulate access over time and receive responses based on the agent's full access unless guardrails exist.

That is a runtime boundary.

An agent with persistent identity is a workforce of one that should be managed like a workload. The agent has a purpose, an owner, a scope, credentials that need to move through a lifecycle, and a pile of boring audit questions that need answers after the agent does something useful or dumb. Who made the change? Who invoked the agent? What policy allowed the tool call? What data did the agent have access to? What trace shows how the agent arrived at that decision? What kill switch can be flipped at 2:00 a.m.?

Also key to our view of AI inside the enterprise is the notion that policy has to run at the action boundary. Policy that runs after the action leaves the team doing a post mortem. The lock has to be on the write operation before it occurs, whether the action is a ticket transition, a file move, a payment operation, a database query, or a customer email.

Truly managing AI agents, as with any workload, means managing identity to action to evidence for the actions the agent performs.

The lifecycle is longer than creation

Control planes make everything after creation visible.

The work must become boring after creation: register the agent, assign the owner, determine the purpose, bind identity, approve tools and data sources, deploy the agent through known and managed deployment paths, observe behavior in the runtime environment, review cost and usage, update evidence of changes, suspend the agent when it behaves badly, retire it when the workflow ceases to exist, and revoke the credentials. Boring is the point. Boring will survive growth.

Creation is the easy row. The control plane owns the rest of the lifecycle.

Microsoft's manage-agents guidance translates create and register into enterprise words: integrate, manage, operate, standardize, secure, comply, retire. Agents have to move from isolated pilots into managed assets with deployment, operation, standardization, cost control, security, compliance, and retirement. Without that oversight, Microsoft warns about shadow AI proliferation, budget overruns, and unused agents expanding the attack surface.

This pattern predates AI. Cloud, SaaS, RPA, and Kubernetes follow a similar lifecycle. First, there is the initial thrill of having an accelerator. Later, as the bill arrives, the speed is replaced by naming, owners, policies, access, monitoring, incident response, and lifecycle management. Agents add the nastier bit: the managed objects can reason about tasks, call tools, and maintain context between tasks.

No mysterious new governance discipline for AI. Normal operating discipline is enough for a new type of actor in the runtime.

What I would look for

When we evaluate an enterprise AI agent platform now, I care less about the first five minutes and more about month five.

Does it list all deployed agents and show the owner of each agent? Does it keep builder identities separate from runtime identities? Can it list the tools, data sources, channels, and memory stores each agent can interact with? Before tool calls are made, can it enforce the right policies? Can it show receipts for the actions performed by the agents, instead of a pile of logs? Can it connect usage and cost to a business workflow? Can it suspend an agent without deleting evidence of what the agent did when running? Can it later retire that agent and revoke credentials without a scavenger hunt?

A single control plane is still an early product claim. Do not get suckered by a vendor screenshot of a control plane. Match that against the actual operating model. It is entirely possible to compose together existing tools, IAM, CI, policy management, distributed tracing, deployment metadata, to serve as a rough control plane for AI agents. The real question is whether the estate has change records and rollback owners for agents that are doing real work for the business.

This also changes the buyer question. The weak question is, "How fast can this tool create an agent?" Speed matters, but it is table stakes now.

The better question is what the agent does after it starts acting for the business.

Registry. Owner. Identity. Tools. Data. Channels. Runtime evidence. Cost. Updates. Suspension. Retirement. If these elements exist, the organization has the germ of an operating model. A prompt. A Slack channel. A shared API key. A dashboard that nobody ever looks at. Current state: drifting agent estate.

Enterprise AI agents are not waiting for a management layer. Microsoft, Google, ServiceNow, LangChain, and the research community are circling this primitive. The builder creates the agent. The control plane decides whether the agent belongs in live systems.