AI Agent Control Plane

An AI agent control plane is the governance layer around agents: it decides who an agent is acting for, what context and tools it can access, which credentials are available, which actions need approval, and how the resulting work is audited.

The agent’s reasoning loop is not the control plane. Neither is the model. The control plane sits around those components so agents can operate inside real organizational boundaries.

Control plane vs agent runtime

The distinction is similar to other infrastructure systems:

the runtime/data plane performs the work: model calls, tool calls, code execution, retrieval, and actions
the control plane defines and enforces the allowed environment: identity, policy, access, approvals, configuration, and audit

One product can provide both, but the responsibilities should remain conceptually separate.

Lobu can run managed agents, but it also exposes the control/context layer to external agents such as ChatGPT, Claude, Codex, and other MCP clients.

Minimum capabilities of an agent control plane

1. Scoped identity

An enterprise agent should not be one global superuser. It needs a clear identity and, often, the identity of the human or role it is acting for. That scope determines which company context and actions are available.

2. Credential isolation

Agents need access to tools without receiving a bag of raw API keys and OAuth tokens. A control plane can broker credentials at the gateway or tool boundary so the agent gets capability without directly owning the secret.

Lobu’s MCP proxy and gateway inject credentials when requests are made. See MCP proxy and secret proxy.

3. Tool policy

Not every visible tool should always be callable. Policy may depend on the agent, user, environment, connector, or operation. Some tools can run automatically; others should be hidden or require approval.

See Tool policy.

4. Human approvals

Autonomy is not binary. A useful system can let an agent investigate freely, draft a change, and stop at the point where a person must approve a sensitive action. The approval itself should become durable state rather than an ephemeral chat message.

5. Guardrails

Policies can also apply before or after a model/tool boundary: input checks, output checks, pre-tool rules, and egress controls. See Guardrails.

6. Audit and provenance

Operators need to answer:

what did the agent observe?
what context did it use?
which tool did it call?
who approved the action?
what changed afterward?

That requires durable events and traces, not only application logs.

Why shared context belongs next to control

Permissions cannot be bolted on after retrieval. If company context is separate from the identity model, agents can accidentally retrieve information the human they represent could not access.

For that reason, Lobu treats context and control as one operating layer: the same identity that scopes tools also scopes organizational state.

See Company context for AI agents.

Agent control plane vs orchestration

Orchestration answers questions such as:

which step runs next?
should this task retry?
which subagent should handle this branch?

A control plane answers different questions:

is this agent allowed to see the source?
which identity is it acting under?
can it call this operation?
does the action require approval?
where are the credentials held?
what evidence and audit trail must be preserved?

A system may provide both, but orchestration alone does not solve governance.

How Lobu acts as an agent control plane

Lobu provides:

org- and user-scoped identities
connections to company systems
permission-aware shared context and memory
gateway-mediated MCP and credential injection
isolated execution for managed agents
per-tool policy and guardrails
human approvals
append-only events and audit history
self-hosted or managed deployment

Existing agents can connect over MCP rather than being rewritten into a Lobu-specific harness.

When you need a control plane

A dedicated control layer becomes useful when agents:

operate for multiple employees or customers
use credentials for real company systems
take actions with financial, operational, security, or customer impact
run proactively outside a supervised chat turn
need different access depending on the user or organization
must produce a reliable audit trail

A local personal agent using your own shell and files may not need this abstraction.