AI Agent Control Plane: Definition, Layers, and Tools

An AI agent control plane is the management layer that defines, observes, or enforces how a set of AI agents may operate. Its scope depends on the object it governs: workflow state, deployed infrastructure, runtime actions, enterprise identity, or organizational work.

The useful question is not whether a product calls itself a control plane. It is: What does the product keep under control, and where is that control enforced?

This distinction matters once agents stop being isolated experiments. You may have agents working through Claude Code, Codex, a custom framework, and hosted services at the same time. One system may decide whether a tool call can run. Another may manage credentials and deployment. A third may retain who owns a task, what it depends on, what it may spend, and which decision is waiting on a person.

All three can be control planes. They govern different objects.

What is the difference between the control plane and the data plane?

The data plane is where agents perform work: models generate responses, tools are called, code is changed, and services handle requests. The control plane manages some of the conditions around that work: configuration, policy, identity, ownership, budgets, review, or retained evidence.

This distinction is a useful systems pattern, not a promise that every control plane intercepts every action. A runtime-policy product may evaluate a proposed command before it executes. An organizational control plane may govern task admission and review without seeing each model response. An enterprise administration layer may register an agent and constrain its access without owning the agent’s work queue.

Fig 1 / Control plane vs data plane

One term, two enforcement relationships

The data plane is where agents perform work. A control plane manages conditions around that work — but products place the control boundary in different positions.

A / Enforced in the action path

CONTROL PLANE

allow · ask · deny

Proposed action Effect

Data plane

Governed object: The proposed action
Where control applies: Before the side effect executes

B / Governs conditions around the work

CONTROL PLANE

admissionreview · record

Actions run uninterrupted Work item

Data plane

Governed object: The unit of work and its conditions
Where control applies: Admission, ownership, budget, and review boundaries

Both systems can govern the same data plane, but they enforce control at different points. One evaluates actions before execution. The other controls admission, ownership, budgets, and review around a unit of work. Compare products by the object they govern and the point where they can stop work.

IBM describes an agent control plane as centralized infrastructure for managing, monitoring, and governing AI agents. That definition captures an important part of the category. In practice, current products place the control boundary at several different layers.

Where does the term “control plane” come from?

The vocabulary comes from networking and predates AI agents by decades. Telephone networks separated call signaling from the voice path before the term became common in computing. A 1991 ITU-T reference model for broadband networks, Recommendation I.321, formalized user, control, and management planes by name. In the 1990s, routers split route computation on general-purpose CPUs from packet forwarding on dedicated ASICs, a separation later documented in RFC 3746. The 2008 OpenFlow paper argued that this control logic should be centralized outside the switches. Cloud providers generalized the split into an API and configuration surface distinct from the serving path, and Kubernetes named its coordinating components the control plane.

Agent systems inherited the term. Later systems applied the same term to different governed objects, including network routes, cloud resources, cluster state, and agent work. Because the governed object has changed across domains, the label alone cannot define a product’s scope. The five-layer model below classifies agent systems by the object governed and the enforcement point.

Why “AI agent control plane” describes five different layers

The following model is a practical way to compare products. It is not an industry-standard ontology, and vendors may span more than one layer.

Fig 2 / Five control-plane layers

Same term, five governed objects

The category becomes clearer when every product is asked the same two questions: what object does it govern, and where does control apply?

Coexisting layers · not a maturity ladder · vendors can span more than one

01
Workflow or graph

Object governedNodes, state, transitions, checkpoints, and execution paths

Where control appliesGraph code, persisted state, and developer-authored interrupts
02
Infrastructure, service, or gateway

Object governedDeployed agents, runtimes, credentials, services, and production health

Where control appliesRuntime, workspace, endpoint, gateway, and deployment boundaries
03
Runtime action or model step

Object governedTool calls, commands, file operations, prompts, outputs, and policy decisions

Where control appliesBefore or during the proposed model, tool, or side-effecting action
04
Enterprise identity, access, and compliance

Object governedRegistered agents, lifecycle owners, permissions, risk, policy, and exceptions

Where control appliesTenant identity, administration, security, data, and lifecycle policy
05
Organizational work

Object governedGoals, roles, tasks, owners, dependencies, budgets, reviews, and retained activity

Where control appliesWork admission, ownership, budget, dependency, and review boundaries

“AI agent control plane” can describe several governed objects. Vendors may span layers, and a team may need more than one. Compare the object and enforcement boundary before comparing feature labels.

1. Workflow and graph control

A workflow framework controls execution logic. LangGraph, for example, lets developers define nodes, transitions, shared state, and long-running graph behavior. Its persistence system retains checkpoints and supports fault recovery. Its interrupts can pause a graph for an approval, edit, rejection, or other external response.

Those are real controls. Their durable object is the graph run and its state. A developer authors the path and decides where an interrupt belongs. That is different from maintaining accountable owners, priorities, and dependencies across a portfolio of work performed by several runtimes.

2. Infrastructure, service, and gateway control

An infrastructure control plane governs deployed agents and the services around them. It may inventory agents, supply execution environments, mediate credentials, expose endpoints, record sessions, apply rate limits, or monitor production health.

Guild documents a governed runtime, agent catalog, workspaces, scoped credentials, approval flows, action traces, cost visibility, and production operation. IBM watsonx Orchestrate spans agent building, orchestration, operational visibility, policy, evaluation, and governance for supported agents, models, and tools.

Guild and IBM watsonx Orchestrate both govern deployed agents and supporting infrastructure, although their documented coverage differs. Compare their runtime support, deployment boundaries, and enforcement mechanisms rather than treating their feature labels as equivalent.

3. Runtime-action and model-step control

A runtime-policy layer decides whether a proposed action should proceed. That control is placed close to a tool call, model response, command, filesystem operation, or other side effect.

Exemplar Relay evaluates supported coding-agent actions and can return allow, ask, or deny before side effects. Its behavior guards add session-level detection for patterns such as loops, destructive bursts, or sustained tool volume. Galileo Agent Control instruments model and tool calls so centrally managed policies can block or steer behavior during execution.

Choose runtime-action control when you need to approve, block, or modify a proposed model or tool action before execution. Runtime policy does not by itself establish the purpose, owner, or dependencies of the larger task.

4. Enterprise identity, access, and compliance control

An enterprise governance layer treats the agent as a managed identity and organizational asset. It may register agents, assign lifecycle owners, control access, investigate risk, apply tenant policy, and connect activity to security or compliance systems.

Microsoft Agent 365 covers Microsoft-built, partner-built, and custom agents through a registry and governance surfaces connected to Microsoft Entra, Defender, Purview, and Intune. In this layer, “owner” usually means the person accountable for an agent’s lifecycle. It does not necessarily mean the agent or person currently responsible for a business task.

Identity ownership assigns responsibility for an agent’s lifecycle, while work ownership assigns responsibility for a specific task. You may need both forms of ownership.

5. Organizational-work control

An organizational control plane governs the work around agent runs. It connects a goal to tasks, owners, dependencies, budgets, review states, decisions, and retained activity across connected runtimes.

Its critical unit is not the model response or deployment. It is the durable unit of work: why the task exists, who may claim it, what blocks it, what it may spend, when a person must decide, and what record remains after the run ends.

Organizational-work control becomes useful when several agents can act but you cannot reliably answer:

Which agent owns this task?
Is it safe to start before another task finishes?
Where is human attention required?
Which budget or review state applies?
What evidence supports the reported status?

Paperclip is designed for this layer. It does not make the other four unnecessary.

How do current control-plane products differ?

Products are easier to compare when the same questions are asked of each one. The table below summarizes the primary object, control mechanism, retained evidence, and boundary documented in the reviewed first-party sources. It is a responsibility map, not an overall ranking.

Product	Primary object governed	Where control applies	Evidence retained or exposed	Explicit boundary
LangGraph	Workflow graph, state, and execution path	Developer-authored nodes, transitions, persistence, and interrupts	Checkpoints, thread state, replay, and recovery	Graph tasks and threads are execution primitives, not organization-wide work ownership
Guild	Deployed agents, runtimes, credentials, and services	Guild runtime, workspaces, endpoints, credentials, and approval flows	Session inputs, tool calls, model calls, outputs, and activity	Strongest controls apply to agents run or deployed through Guild; a neutral organizational work ledger was not documented
IBM watsonx Orchestrate	Supported agents, models, tools, controls, and operational health	Central controls and guardrails across supported agent forms and services	Deployment state, activity, health, quality, controls, alerts, and failures	Availability and coverage vary by agent and deployment; arbitrary cross-runtime work ownership was not documented
Exemplar	Coding-agent and framework-agent actions	Relay and SDK policy checks before supported side effects	Action, policy, verdict, surface, and outcome events	Governs proposed actions; it does not replace shared goals, task ownership, or dependencies
Galileo Agent Control	Instrumented model and tool steps	Centralized policies that block or steer runtime behavior	Agent traces, controls triggered, and reasons	A durable organizational work graph and financial budget ledger were not documented
Microsoft Agent 365	Registered agent identity, access, risk, and lifecycle	Microsoft tenant administration, Entra identity, Defender, Purview, and Intune controls	Registry, usage, ownership gaps, risks, exceptions, and lifecycle state	Lifecycle ownership is not active ownership of cross-agent business tasks
Paperclip	Goals, agent roles, tasks, owners, dependencies, budgets, and reviews	Paperclip task admission, checkout, budget, approval, and activity boundaries	Work state, decisions, artifacts, and Paperclip mutation records	Does not universally mediate external tool calls or prove tests, deployment, compliance, or outcomes

Is a control plane the same as orchestration, observability, or MCP?

No. The concepts may appear in the same product, but they describe different responsibilities.

Concept	Primary responsibility	The evidence it should provide
Orchestration	Coordinate execution order, routing, handoffs, tools, and workflow state	Which step ran, under what state, and what should run next inside the workflow
Observability	Record and analyze behavior, quality, latency, errors, and cost	What happened during execution and how the system behaved
Runtime policy	Evaluate or constrain proposed model and tool actions	Which rule evaluated the action and what decision it returned
MCP	Standardize how an AI application connects to tools, data, and prompts	Which server and capability were available through the protocol
Control plane	Manage a defined object and its operating conditions	What was governed, where control applied, who decided, and what state remains

Observability can inform a control decision without enforcing it. Orchestration can pause for human input without becoming an organization-wide work record. MCP can expose tools without deciding who should use them or why. A product can combine these responsibilities, but buyers should still verify each boundary separately.

What capabilities should an AI agent control plane have?

No universal checklist applies across all five layers because each layer governs a different object. Evaluate a product by the following seven responsibilities and the mechanism it uses for each one.

Inventory and ownership. Which agents, workflows, services, identities, or tasks are registered? Does “owner” mean lifecycle owner, active task owner, or both?
Work coordination. Can the system connect work to goals, owners, dependencies, handoffs, and blockers? Can two agents silently claim the same task?
Runtime control. Does the product merely recommend behavior, or can it enforce a decision? Is enforcement at the graph, gateway, command, model step, or task-lifecycle boundary?
Cost control. Does the product show spend, send alerts, impose rate limits, or actually stop new governed work? What spend remains outside its boundary?
Human review. Which decisions are gated? Who may decide? Is the gate attached to a tool action, agent deployment, organizational approval, or task state?
Evidence and recovery. Does the record identify the actor, action, decision, state, and time? Can an operator recover or replay work? What activity is not captured?
Deployment and lifecycle. Does the product build, host, schedule, pause, retry, update, or terminate agents? Which runtimes and deployment models are actually supported?

Feature labels are not enough. “Approval” could mean approving a shell command, registering an agent in a tenant, reviewing a completed task, or authorizing a budget exception. “Audit trail” could mean a model trace, an administrative event, or a work-state history. Record the object and boundary beside every claimed capability.

Fig 3 / Governed object × enforcement point

Where can this product actually stop work?

Any layer can observe and recommend broadly, and that influence is advisory. Enforcement is narrower: each layer stops work only at a named point, and never beyond the boundary the product declares.

Graph runWorkflow layer

Stops work atDeveloper-authored interrupts and checkpoints in graph code

Beyond its declared boundaryOwners, priorities, and dependencies for work performed across several runtimes

Deployed estateInfrastructure layer

Stops work atRuntime, workspace, credential, endpoint, and gateway boundaries

Beyond its declared boundaryAgents and services that never pass through its managed runtimes or gateways

Proposed actionRuntime layer

Stops work atAllow, ask, or deny before the supported side effect executes

Beyond its declared boundaryWhy the work exists, who owns the larger task, and what must finish first

Agent identityEnterprise layer

Stops work atTenant registration, access, and lifecycle policy

Beyond its declared boundaryActive ownership of the business task an agent is working on right now

Unit of workOrganizational layer

Stops work atTask admission, checkout, budget, approval, and review states

Beyond its declared boundaryEach external model response, shell command, or API side effect

Stops work at: the one named point where this layer can enforce — not a claim about anything else Declared boundary: enforcement never extends past it Beyond the boundary: the layer can observe or recommend there, but it cannot stop work

Use the matrix to identify the object a product governs, the point where it can stop work, and the responsibilities outside its boundary. A product may observe or recommend action beyond its enforcement point, but those capabilities do not constitute control.

How should responsibility be divided?

A control plane records responsibility within its declared boundary, but source systems remain responsible for the facts they alone can verify.

The human operator sets the objective, decides which decisions remain human, establishes limits, and defines sufficient evidence.
The agent and its runtime execute assigned work through configured models and tools.
The control plane governs and records the state inside its declared boundary.
The source systems remain authoritative for facts they alone can prove, such as passing tests, repository history, deployment status, policy compliance, and business outcomes.

This boundary prevents a common failure: treating a green task state as proof that the underlying work succeeded. A completed task is a workflow fact. It is not, by itself, proof of merge, deployment, correctness, compliance, or customer impact.

Where does Paperclip fit?

Paperclip is an open-source, self-hosted application for coordinating agents connected through multiple runtimes. Its primary governed object is organizational work.

Paperclip assigns agents roles, capabilities, and reporting relationships. Goals and projects connect tasks to their purpose, while atomic checkout allows one agent to claim a task and preserves blocked-by relationships.

Company and per-agent budgets can warn near a limit and stop new Paperclip-managed work at a hard limit. Execution policies can require review or approval before governed completion. The activity log records the actor, action, entity, details, and time for Paperclip mutations.

Two narrower examples make that boundary concrete. Paperclip decisions retain a human choice in the work record, while configured task watchdogs can inspect a defined task subtree and open review work when needed. Neither mechanism claims authority over every external action an agent may take.

The limits belong beside the capabilities:

Paperclip connects to multiple runtimes, but adapter capabilities differ. It does not work identically with every agent.
Its budget hard stops govern Paperclip-managed work, not all provider billing outside Paperclip.
Its task-review policies do not universally intercept every model response, shell command, API call, or external side effect.
Its activity record covers Paperclip state and decisions. It is not proof of everything that happened in an external runtime.
A completed Paperclip task does not prove tests, merge, deployment, compliance, or business impact.

Fig 4 / Responsibility boundary

What Paperclip governs — and what stays authoritative elsewhere

Paperclip’s governed object is organizational work. Systems on the other side of the boundary are referenced as evidence, not controlled.

Governed in PaperclipObject: organizational work

GOAL — why the work exists

TASK A

One owner via atomic checkout Review required before governed completion Decision retained in the work record

TASK B

Blocked-by relationship recorded Budget can warn, then stop new Paperclip-managed work

Retained activity: actor · action · entity · details · time

Authoritative in their own systems

Runtime & tool calls

model steps · commands · side effects

Repository & tests

code history · verification

Deployment

release & operating state

Enterprise identity

tenant access & lifecycle

Outcomes & measurement

business impact

Referenced as evidence — not controlled

Paperclip governs organizational work: goals, tasks, owners, dependencies, budgets, review states, decisions, and retained activity across connected runtimes. Runtime actions, repositories, deployment, identity, and outcomes remain authoritative in their own systems — a completed task is a recorded workflow state, not proof of merge, deployment, compliance, or business impact.

Paperclip is a fit when agents already perform useful work and the missing layer is shared goals, accountable task ownership, dependencies, budgets, review, and retained organizational evidence. It is not the first tool to choose when the immediate problem is building an agent, hosting its runtime, blocking an unsafe tool call, or debugging model quality.

How do you choose the right control-plane layer?

Start with the object you need to govern and the specific action the product must be able to stop.

If the failure is…	Start with…	Verify this before buying
The workflow loses state or resumes incorrectly	Workflow or graph control	Persistence, interrupt, replay, and recovery semantics
Deployed agents lack consistent credentials, health, or operating policy	Infrastructure, service, or gateway control	Runtime coverage, enforcement point, credential boundary, and deployment scope
An agent can take a prohibited action before review	Runtime-action or model-step control	Pre-action enforcement, policy decision types, bypass paths, and audit evidence
Agents are unregistered, ownerless, or outside tenant policy	Enterprise identity, access, and compliance control	Registry coverage, identity model, access enforcement, lifecycle, and exceptions
Work has unclear owners, dependencies, budgets, or review states	Organizational-work control	Task admission, ownership semantics, dependency behavior, stopping rules, and retained decisions

A team can need more than one layer. LangGraph may define a workflow, Galileo may enforce step-level policy, Microsoft Agent 365 may govern tenant identity, and Paperclip may retain the organizational work around the runs. That is a stack of control boundaries, not four interchangeable products.

Before choosing, write down ten answers:

What is the primary object governed?
Where is control enforced?
Which agents and runtimes are in scope?
What does “owner” mean?
Which limits merely alert, and which stop work?
Which decisions require a person?
What evidence is retained, and for how long?
How does the system recover from failure or disagreement?
Where can it be deployed, and what data leaves that boundary?
What important responsibility does it explicitly not own?

A product should document the responsibilities it does not own as clearly as the controls it provides.

Frequently asked questions

What does an AI agent control plane do?

An AI agent control plane manages a defined part of an agent system, such as workflow state, deployed infrastructure, runtime actions, enterprise identity, or organizational work. Depending on its layer, it may provide policy, permissions, ownership, budgets, approvals, observability, lifecycle controls, or retained evidence.

Is an AI agent control plane the same as an orchestration framework?

No. An orchestration framework defines how agents, tools, and workflow steps execute together. A control plane manages operating conditions around a defined object. A framework can include control-plane features, but graph state is not the same thing as enterprise identity or organization-wide task ownership.

Is an agent control plane the same as MCP?

No. Model Context Protocol standardizes connections between AI applications and tools, data, or prompts. A control plane may govern agents that use MCP, but MCP does not by itself assign work, set budgets, approve actions, or establish organizational responsibility.

Is observability the same as agent governance?

No. Observability records and analyzes what happened. Governance defines which identities, assets, actions, or workflow states are permitted and who may decide. Observability supplies evidence for operators and policy, but it does not automatically enforce a decision.

Do I need an AI agent control plane?

Probably not for one narrow agent with a clear owner, low consequence, and a workflow a person can inspect directly. The need grows when agents multiply across runtimes, run unattended, share tools, accumulate cost, depend on one another, or require durable human decisions.

Can an AI agent control plane be open source or self-hosted?

Yes. Deployment models vary by product, and open source does not by itself prove privacy, security, isolation, or zero telemetry. Verify the repository and license, deployment path, data flows, credential handling, update process, and which capabilities remain hosted services.

Can several control planes coexist?

Yes. A workflow framework, runtime-policy layer, enterprise identity system, and organizational-work layer can govern different objects in the same architecture. Verify their interfaces and decide which system is authoritative when their states disagree.

Which control-plane layer is Paperclip?

Paperclip operates at the organizational-work layer. It coordinates goals, agent roles, tasks, owners, dependencies, Paperclip-managed budgets, review states, and retained activity across connected runtimes. It does not replace agent frameworks, universal runtime guardrails, specialized observability, repositories, or deployment systems.

When is Paperclip unnecessary?

Paperclip is unnecessary when your main problem is building a first agent, hosting a service, evaluating model quality, or enforcing individual tool calls. It may also be unnecessary when one person can reliably manage a small number of low-risk agents in the runtime itself. Choose the smallest layer that owns the problem you actually have.

Define the boundary before comparing products

“AI agent control plane” is becoming a useful category name, but it is not yet a precise product specification. Two vendors can use the term accurately while controlling different objects.

Begin with the durable thing that must remain governed: the graph, the deployed service, the proposed action, the enterprise identity, or the organizational work. Then locate the enforcement point, name the evidence that remains, and state what the layer cannot prove.

If the missing object is the work itself, including its purpose, owner, dependencies, budget, review path, and retained decisions, evaluate an organizational control plane such as Paperclip. Keep the runtime, repository, deployment system, and outcome measurement authoritative for the evidence they alone can provide.

Source registry

Sources were reviewed on September 1, 2026. Product capabilities and availability change quickly; re-check them before publication.

Category and layer sources

Term history sources

Term-history sources were verified on September 2, 2026.

What Is an AI Agent Control Plane?