AI Agents Are Becoming Infrastructure. Who Controls the Control Plane?

Signup Write New Story AI Agents Are Becoming Infrastructure. Who Controls the Control Plane? by Atul Kumar by Atul Kumar | @ katul1512 Chief Product & Innovation Architect at Spotlyf AI Engineer and Enterprise Architect passionate about building scalable AI systems and production-ready agentic platforms. I write about AI.

AI Engineer and Enterprise Architect passionate about building scalable AI systems and production-ready agentic platforms. I write about AI.

We have spent the last few years asking whether AI agents can actually do useful work. Can an agent search across systems? Can it call tools? Can it write code? Can it analyse a document, update a ticket, send an email, approve a workflow, or coordinate with another agent?

Those questions made sense when agents were mostly experiments. The question is changing now.

Once an organisation has hundreds or thousands of agents operating across different teams, models, frameworks, clouds, databases, APIs, and business processes, the problem is no longer simply whether an individual agent works. The harder problem is knowing what agents exist, who owns them, what they can access, what they are doing, which policies apply to them, and how to intervene when something goes wrong.

That is where I think the idea of an agent control plane becomes important. This is no longer just a theoretical architecture. Microsoft now describes Agent 365 as a control plane for observing, securing, and governing agents, with capabilities including an agent registry, identity, access control, security, data governance, and analytics. Microsoft also describes its Foundry Control Plane as a developer-facing layer for evaluation, observability, runtime controls, and fleet operations. Google Cloud similarly describes its Agent Registry and governance layer around agent inventory, identity, gateways, policies, security, auditing, and operational oversight. [ Ref ]

What interests me, however, is not the product naming. It is the architectural problem underneath it. If agents are becoming another class of software infrastructure, what controls them?

A traditional application usually has a relatively well-defined boundary. There is an application, a deployment, a database, some APIs, a team that owns it, and an operational process around it. We know where the application is deployed and, at least in theory, who is responsible for it.

Agents complicate that model because an agent is not always a single static application. An agent can have a model, prompts, memory, tools, credentials, policies, external dependencies, and runtime state. It can interact with another agent, invoke an MCP server, retrieve information from several systems, and make decisions about which tool to use next.

A simple customer-support agent might look like this:

Customer Support Agent | ┌──────────────┼──────────────┐ ↓ ↓ ↓ Customer DB Order API Knowledge Base | | | └──────────────┼──────────────┘ ↓ Decision | ┌──────────────┼──────────────┐ ↓ ↓ ↓ Ticket API Refund API Email API That looks manageable. Now imagine an enterprise with 2,000 such agents.

Some were built using different agent frameworks.

Some can create or delegate work to other agents.

Suddenly, the organisation has a fleet of autonomous software actors.

At that point, treating each agent as an isolated application becomes difficult. The organisation needs a layer above the individual agents. That is the role I see for the control plane.

A control plane is not where the actual business work necessarily happens. It is the layer that establishes how the workloads are configured, governed, observed, secured, and managed. Kubernetes provides a useful analogy.

You don't manage every container independently by logging into the machine where it happens to be running. Kubernetes gives you a control layer for desired state, scheduling, policies, workloads, and cluster management.

The same architectural idea can be applied to agents. The agent itself performs work. The control plane manages the conditions under which that work can happen. I think about the architecture like this:

┌─────────────────────────────┐ │ AGENT CONTROL PLANE │ │ │ │ Identity Policy Registry│ │ Security Memory Audit │ │ Observability Lifecycle │ │ Cost Governance │ └──────────────┬──────────────┘ │ ┌─────────────┼─────────────┐ ↓ ↓ ↓ Agent A Agent B Agent C │ │ │ ↓ ↓ ↓ Tools APIs Agents │ │ │ └─────────────┼─────────────┘ ↓ Enterprise Systems The important part is that the control plane does not replace the agents. It gives the organisation a consistent way to manage them.

The first thing I would want from an enterprise agent control plane is surprisingly simple: Tell me what agents exist.

This sounds obvious, but it becomes difficult when agents can be created through different platforms and teams. Imagine discovering that your organisation has:

Finance Agent 01 Finance Agent 02 Invoice Agent Invoice Review Agent Legacy Invoice Bot Procurement Agent Procurement Agent v2 Vendor Risk Agent Temporary Finance Agent Now ask:

Without an inventory, the security team is effectively operating blind. This is why an agent registry should be one of the first components of the control plane.

Google's current Agent Registry, for example, is designed as a centralised catalogue for agents, MCP servers, tools, skills, and endpoints, while Microsoft's Agent 365 includes a unified registry intended to give organisations an inventory of their agent fleet. [Ref] I would represent an agent registry entry roughly like:

{ "agent_id": "finance-reconciliation-42", "name": "Finance Reconciliation Agent", "owner": "finance-platform-team", "environment": "production", "model": "model-x", "version": "3.4.1", "risk_level": "high", "status": "active", "capabilities": [ "invoice.read", "transaction.read", "reconciliation.create" ], "data_access": [ "finance.transactions", "vendor.records" ] } Now the agent becomes a managed entity rather than an anonymous piece of automation.

This connects directly to something I wrote about recently: agents need identities of their own. A control plane should know that an agent is not simply a model with an API key. The identity should remain stable even when the underlying model, credential, or deployment changes. For example:

Agent Identity | ├── Model Version ├── Agent Version ├── Credentials ├── Capabilities ├── Owner ├── Policies └── Runtime That gives us a stable object to govern. An agent might move from one model to another without becoming a completely different organisational entity. Similarly, credentials can rotate without changing the agent's identity.

This is important for auditability. If an agent approves a payment today and another credential is issued tomorrow, we still need to know that both actions came from the same managed agent identity.

Google's current agent platform documentation explicitly treats agent identity as a mechanism for agents to authenticate to resources, endpoints, and other agents, while Microsoft integrates agent identity and access controls into its enterprise management approach. [Ref]

Identity tells us who the agent is. It doesn't tell us what the agent is allowed to do. That is the policy layer. Suppose a procurement agent has access to a purchasing system. Its capabilities might be:

vendor.read purchase_order.create purchase_order.read invoice.read But perhaps:

purchase_order.approve requires human approval, and perhaps anything above $50,000 requires an additional authorisation step. That policy could look conceptually like:

agent: procurement-agent permissions: - vendor.read - purchase_order.read - purchase_order.create restrictions: purchase_order.amount: max: 50000 requires_human_approval: - purchase_order.approve - purchase_order.amount > 50000 The model should not be responsible for enforcing these rules. The model can propose:

Create purchase order for $72,000 The policy engine can respond:

Amount exceeds autonomous approval threshold. Human approval required. This is an important architectural boundary. The model reasons. The control plane enforces.

One of the easiest mistakes in agent development is putting important business rules into the prompt. For example:

You are a procurement agent. Never approve purchases above $50,000. Always check the vendor. Never access payroll data. This can help guide the model. It should not be the actual security boundary. If a $75,000 payment would be dangerous, the system should not rely on the model remembering a sentence in its system prompt. The enforcement should happen outside the model. A better architecture is:

Agent | "Approve $75,000" | ↓ Policy Engine | ┌───────┴────────┐ ↓ ↓ Allowed Restricted | | ↓ ↓ Execute Human approval That separation becomes increasingly important as agents become more capable.

The tool layer is another area where a control plane becomes useful. An agent might have access to:

search() get_customer() get_order() create_ticket() send_email() issue_refund() update_account() delete_record() Giving the agent access to all of them because "it might need them" is a poor boundary. The control plane should know which tools are available to which agents. It should also understand the risks associated with those tools. For example:

Tool Risk customer.read Low order.read Low ticket.create Low email.send Medium refund.create High account.update High record.delete Critical This becomes even more relevant with MCP and other tool-discovery mechanisms. Google's Agent Registry now treats MCP servers, tools, skills, endpoints, and agents as governance objects, reflecting the fact that the agent ecosystem is no longer just about models and prompts. The control plane, therefore, needs to understand not only: "Which agent exists?"

but also: "Which capabilities surround that agent?"

The next complication is multi-agent systems. Imagine:

Customer Support Agent | ↓ Refund Verification Agent | ↓ Fraud Detection Agent | ↓ Payment Service From the outside, a customer might simply see a refund being processed. Inside the system, several autonomous actors may have participated in the decision. The control plane needs visibility into those relationships. A useful topology might look like:

Customer | ↓ ┌──────────────────┐ │ Support Agent │ └────────┬─────────┘ | ↓ ┌──────────────────┐ │ Refund Agent │ └────────┬─────────┘ | ↓ ┌──────────────────┐ │ Fraud Agent │ └────────┬─────────┘ | ↓ Payment API This is not just useful for visualisation. It matters for security. If an agent suddenly starts communicating with a service it has never interacted with before, that relationship may deserve investigation.

Google's current governance tooling includes topology views of agent and MCP-server relationships and traffic flows, while Microsoft describes agent maps and usage visualisation as part of its management model. [Ref] That is a sign of an important shift: agent relationships themselves are becoming operational data.

This is where my own experience with production systems strongly influences how I think about agents. A normal application log might tell you:

10:32:14 POST /refund 10:32:15 200 OK That's useful. For an agent, it isn't enough. I want to know:

Agent: refund-agent-42 Task: refund-request-9812 Decision: refund approved Inputs: order.status = delivered payment.status = captured fraud.status = clear Tools: order.read payment.read fraud.check refund.create Policy: refund-policy-v18 Authorization: approved Execution: success The control plane needs to connect the entire decision path. A useful trace might look like:

User Request | ↓ Agent Invocation | ├── Context Retrieval | ├── Model Decision | ├── Tool Selection | ├── Policy Check | ├── Authorization | ├── Tool Execution | └── Result Verification This is much closer to distributed tracing than conventional application logging. Microsoft's current guidance explicitly points to OpenTelemetry-based traces, metrics, and logs for agent observability, while its Foundry Control Plane is designed to provide runtime observability across heterogeneous agents. [Ref]

For me, that is an important direction because agent failures rarely happen at a single point. The model, tool and API may be fine. The final decision can still be wrong because something changed between those steps.

This connects directly to another problem I've written about: an agent can make a reasonable decision and still act incorrectly because reality changes between reasoning and execution. Suppose an agent reads:

Payment is eligible for approval. Before execution, another service change:

Pending → Flagged If the control plane simply allows the action because the agent was authenticated, it has missed the real problem. The control plane needs to support conditions such as:

Payment version = 42 Policy version = 18 Fraud assessment = clear Authorization = valid Then, before execution, critical conditions can be revalidated. Conceptually:

Agent Decision | ↓ Decision Preconditions | ├── Identity valid? ├── Permission valid? ├── Input still current? ├── Policy still active? ├── Business invariant valid? └── Resource still available? | ┌────┴────┐ ↓ ↓ Valid Invalid | | ↓ ↓ Execute Re-read / Re-plan / Stop This is where the control plane becomes more than an administrative dashboard. It becomes part of the execution safety boundary.

Memory is often discussed as if it were simply a feature that makes an agent more useful. In production, memory becomes another governed resource. An agent might remember:

Customer preference Past conversation Business decision Previous tool result Internal document Temporary workflow state But not all memories should live forever.

And some memories may have different access restrictions.

A control plane could therefore maintain memory metadata such as:

{ "memory_id": "mem-92831", "agent_id": "support-agent-42", "source": "customer-conversation", "created_at": "2026-09-29T10:32:00Z", "expires_at": "2026-12-29T10:32:00Z", "sensitivity": "confidential", "retention_policy": "90-days", "source_version": "conversation-781" } This changes the way we think about agent memory. It isn't just context, it is data. And once it becomes data, it needs lifecycle management, access control, provenance, retention, and deletion policies.

One of the weaknesses I see in many architectures is treating security as something that happens outside the agent runtime. For agents, that separation becomes harder. An agent can access sensitive information, invoke external tools, communicate with other agents, and perform actions continuously. Security, therefore, needs to be connected to identity, tools, policy, and runtime behaviour. Imagine an agent that normally communicates with:

CRM Payment API Customer Database Suddenly, it begins requesting access to:

Production Kubernetes API The security system shouldn't need to wait for a human to notice that pattern in a log. The control plane should already know that this is outside the agent's normal scope. The response might be:

Unexpected capability request ↓ Policy evaluation ↓ Access denied ↓ Security event ↓ Agent flagged ↓ Human investigation Current enterprise approaches are moving in this direction. Microsoft positions Agent 365 around identity, security, data governance, and threat protection, while Google describes identity, gateways, security/compliance, audit trails, and operational oversight as parts of its agent governance layer. [Ref]

This is one area where control-plane architecture becomes particularly tangible. Imagine an agent begins behaving abnormally.

Maybe it starts calling a tool repeatedly.

Maybe it attempts to access an unexpected system.

Maybe its request volume suddenly increases.

Maybe its actions don't match its declared purpose.

A traditional monitoring system might generate an alert. An agent control plane should ideally be able to do more. For example:

Anomaly detected ↓ Evaluate agent state ↓ Reduce capabilities ↓ Block risky tool ↓ Pause agent ↓ Preserve evidence ↓ Notify owner The ability to intervene is just as important as the ability to observe. Recent industry developments underline this direction. NVIDIA announced the Open Agent Safety Platform in September 2026, including controls intended to constrain agent authority and monitoring intended to detect and quarantine suspicious behaviour. [Ref]

The specific implementation will evolve, but the architectural principle is straightforward: An autonomous system needs a mechanism outside the agent that can stop or constrain it.

Another thing I would put directly into the control plane is lifecycle management. An agent should not simply be:

Created → Running forever A more realistic lifecycle is:

Create ↓ Register ↓ Validate ↓ Deploy ↓ Activate ↓ Operate ↓ Update ↓ Monitor ↓ Suspend ↓ Retire Each transition should have controls. When a new agent is created, the organisation should establish its owner, purpose, identity, capabilities, and risk classification. Before production deployment, it should pass the required validation and policy checks. During operation, its behaviour should be observable. When its model or configuration changes, the system should know what changed. If the agent becomes unnecessary, it should be retired, and retirement should not mean deleting its history. Historical actions need to remain available for auditing and investigation. This is where the agent registry, identity system, observability platform, and policy engine need to work together.

One problem that sounds administrative but becomes very technical very quickly is ownership. Imagine an agent has been running for six months. The employee who created it has left the organisation. The agent still has production access. Who is responsible for it?

Without explicit ownership, the agent becomes what I would call an orphaned agent. That is dangerous because nobody is clearly accountable for its permissions, data access, configuration, or behaviour. A registry should therefore capture ownership as a first-class property:

Agent: finance-reconciliation-42 Owner: Finance Platform Team Business Sponsor: Finance Operations Technical Owner: AI Platform Team Security Classification: High Production Access: Yes Ownership also needs a lifecycle. If the owner leaves, changes teams, or loses responsibility, the control plane should trigger a review rather than leaving the agent untouched.

Microsoft's current governance guidance explicitly emphasises agent ownership alongside inventory and observability as foundational controls for scaling agents. [Ref]

There is another dimension that is easy to overlook: cost. An agent that can continuously reason, retrieve information, call tools, and delegate tasks can also continuously consume resources. Imagine:

Agent A ↓ Agent B ↓ Agent C ↓ 10 tool calls ↓ 5 model calls ↓ Another agent Without usage controls, a workflow can become expensive very quickly. The control plane should therefore understand:

Model usage Tool usage Execution time External API usage Memory consumption Agent-to-agent calls That allows organisations to define budgets and limits. For example:

agent: research-agent limits: max_runtime: 30m max_model_calls: 50 max_tool_calls: 100 max_child_agents: 3 daily_budget: 25 Cost control isn't separate from reliability. A runaway loop is simultaneously a reliability problem, a security problem, and potentially a cost problem.

If I put all these pieces together, my mental model looks something like this:

┌───────────────────────────────┐ │ AGENT CONTROL PLANE │ │ │ │ ┌────────┐ ┌───────────┐ │ │ │Identity│ │ Registry │ │ │ └────────┘ └───────────┘ │ │ │ │ ┌────────┐ ┌───────────┐ │ │ │ Policy │ │ Security │ │ │ └────────┘ └───────────┘ │ │ │ │ ┌────────┐ ┌───────────┐ │ │ │ Memory │ │Observability│ │ │ └────────┘ └───────────┘ │ │ │ │ ┌────────┐ ┌───────────┐ │ │ │Lifecycle│ │Cost/Usage │ │ │ └────────┘ └───────────┘ │ └───────────────┬───────────────┘ │ ┌────────────────────────┼────────────────────┐ │ │ │ ↓ ↓ ↓ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ Agent A │ │ Agent B │ │ Agent C │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ ┌───────┼────────┐ ┌───────┼───────┐ ┌────┼─────┐ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ Tools APIs Memory MCP APIs Agents DB APIs Tools │ │ │ └────────────────────────┼────────────────────┘ ↓ Enterprise Systems The key idea is that agents remain autonomous at the execution layer, but the organisation gets a consistent management layer above them.

I think this distinction is important because a control plane shouldn't become a giant centralised bottleneck. The runtime should be responsible for executing the agent's work. The control plane should be responsible for establishing and enforcing the rules around that work. A simplified division could look like:

Some capabilities will naturally overlap, especially observability and policy enforcement. The important architectural principle is that the agent should not be the ultimate authority over its own permissions.

There is also a risk in taking this idea too far. An organisation could build a massive central platform that every agent must communicate with for every tiny decision. That can create latency, complexity, and a new single point of failure.

I would rather think of the control plane as logically centralised but operationally distributed. For example:

Central Governance | ┌────────────┼────────────┐ ↓ ↓ ↓ Region A Region B Region C | | | Agents Agents Agents Some policies can be distributed to local enforcement points. Identity can be validated close to the workload. Observability data can be collected locally and aggregated centrally. High-risk authorisation can call a central policy service. This is similar to how modern distributed systems separate centralised configuration and governance from distributed execution. The goal isn't centralisation for its own sake, but the goal is consistent control without unnecessarily centralising execution.

There is a temptation to think of a control plane as a beautiful dashboard showing hundreds of agents. That is useful, but a dashboard alone isn't governance. Governance means the system can actually enforce decisions. For example:

Policy: Production agents cannot access development databases. The important part isn't that the dashboard shows a warning. The important part is:

Agent requests development DB ↓ Policy evaluation ↓ Denied ↓ Audit event created Similarly:

Policy: Agents cannot create financial transactions above $50,000 autonomously. The system should enforce that rule regardless of what the model says. This is why I think the control plane should be policy-first rather than dashboard-first.

This is an uncomfortable question, but it has to be asked. If the control plane is responsible for identity, authorisation, policy, and security, what happens when it becomes unavailable? The answer should depend on the action.

For low-risk operations, cached policy decisions may be acceptable.

For high-risk operations, fail-closed behaviour may be appropriate. For example:

Read public documentation ↓ Control plane unavailable ↓ Cached policy permits ↓ Continue But:

Transfer $500,000 ↓ Control plane unavailable ↓ Cannot validate authorization ↓ Stop This is another reason to classify agent actions by risk. Not every operation deserves the same consistency and availability trade-off.

What we're really seeing is a change in the role of AI inside software systems. The first generation of enterprise AI was mostly about assistance.

A person asked a question. The model generated an answer, and the human decided what to do, whereas agents change that relationship. The agent can decide which information to retrieve, which tool to call, which workflow to follow, and sometimes whether an action should happen at all. That makes the agent an active participant in the system. And once software becomes an active participant, it needs infrastructure around it.

We already built infrastructure for humans. We have identity systems, access management, audit systems, security monitoring, workflow engines, deployment platforms, and organisational ownership. We are now beginning to build similar infrastructure for autonomous software actors. That is what the control plane represents.

I don't think the next major challenge in agentic AI is simply making agents more capable. The harder challenge is making their capability manageable at scale.

One agent with five tools is an engineering problem. A thousand agents with thousands of tools, different models, different owners, different permissions, different data sources, and the ability to interact with one another becomes an infrastructure problem. At that scale, asking every development team to individually implement identity, authorisation, lifecycle management, observability, security, memory governance, and policy enforcement doesn't make much sense.

We need a layer above the individual agent. That layer needs to answer some very basic questions:

Which other agents do they interact with?

Can we stop them when something goes wrong?

That is the job of an agent control plane. The interesting part is that this doesn't mean agents become less autonomous. Quite the opposite. A good control plane can actually make greater autonomy possible because organisations don't have to choose between autonomy and control.

They can give agents more responsibility while keeping identity, policy, security, observability, and intervention mechanisms outside the model itself. That distinction is important to me because I've spent a lot of time thinking about what happens when AI moves beyond demos and into production systems. The difficult part isn't getting an agent to call a tool. The difficult part is building the infrastructure that lets thousands of those actions happen without losing visibility or control.

We spent the first phase of agent engineering figuring out how to make agents act. The next phase is figuring out how to control the infrastructure that allows them to act. And that may be where the real enterprise agent architecture begins. [Ref]

Your RAG System Can Be Healthy and Still Be Wrong