What Is an AI Agent Control Plane?

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?

Orchestration coordinates execution: order, routing, handoffs, and workflow state. Observability records and analyzes what happened: traces, quality, latency, errors, and cost. A control plane manages operating conditions for a defined object; at its declared enforcement point, it can stop or gate work.

Paperclip operates at the organizational-work layer: goals, tasks, owners, dependencies, budgets, and reviews across connected runtimes. It does not intercept every tool call or replace runtime policy, observability, or deployment systems; it may be unnecessary when one person can inspect a small agent workflow directly.

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 conditions around that work.

If your agents run through Claude Code, Codex, and hosted services, one system may gate tool calls while another governs task admission and review. Both can be control planes. They govern different objects, at different boundaries.

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. A 1991 ITU-T reference model for broadband networks, Recommendation I.321, formalized user, control, and management planes by name. RFC 3746 (2004) describes separating control elements from forwarding elements, including processor- and ASIC-based implementations. AWS distinguishes administrative resource APIs from primary service functions as control and data planes, and Kubernetes describes a control plane that manages worker nodes and Pods.

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.

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. Configured checkpointers retain thread state for recovery and continuation; in-memory checkpoints do not survive a restart. Developer-authored interrupts pause a graph for external input, such as an approval, edit, or rejection.

Those are real controls. These controls govern graph execution and thread state; LangGraph also supports cross-thread stores. A developer authors the path and decides where an interrupt belongs. An organization-wide ledger of task accountability across arbitrary runtimes is not documented in the reviewed sources.

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 managed runtime, catalog, workspaces, scoped credentials, action approval gates, session records, and cost visibility. Its page marks framework-agnostic deployment as “Coming soon.” IBM watsonx Orchestrate documents agent building and orchestration alongside visibility, evaluation, policy, and identity controls for connected agents, tools, and models.

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.

Galileo Agent Control wraps model and tool calls with controls, evaluates inputs and outputs, and supports deny and steer decisions with control-event telemetry. Some checks run after a call, so a control is not always a gate before a side effect.

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 provides a tenant registry and lifecycle, access, security, and compliance surfaces through Entra, Defender, and Purview. Registry types include Microsoft, partner, organization-published, and creator-shared agents; available actions vary by agent type and publisher state. Intune contributes device and application posture controls. 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. Vendor capabilities are documented claims, not independently tested results. This is a responsibility map, not an overall ranking.

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.

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. Ask each vendor the same eight questions, then compare the mechanism and its boundary. Paperclip’s answers below describe organizational-work control.

For a broader purchase decision, use the governance platform evaluation guide.

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.

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, capability descriptions, and reporting relationships. Goals and projects connect tasks to their purpose, while atomic checkout lets an agent claim a task and returns a conflict when another agent owns it. Paperclip separately records blocked-by task relationships.

Company and per-agent budgets can warn near a configured limit. When an enabled hard-stop policy blocks a scope, Paperclip pauses that scope, blocks new agent runs in that scope and requests cancellation of active and queued runs. Cancellation and cost reporting can lag, so actual spend can exceed the limit. Execution policies can require review or approval before an issue reaches done when that issue has a configured policy. 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.

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.

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:

1. What is the primary object governed?
2. Where is control enforced?
3. Which agents and runtimes are in scope?
4. What does “owner” mean?
5. Which limits merely alert, and which stop work?
6. Which decisions require a person?
7. What evidence is retained, and for how long?
8. How does the system recover from failure or disagreement?
9. Where can it be deployed, and what data leaves that boundary?
10. 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

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.