Agent Control Plane Architecture

An agent control plane manages fleets of agents and workers: provisioning, identity, credentials, routing, schedules, policies, traces, approvals, usage, and recovery.

Boundary

An agent control plane is not the agent. It is the system that makes agents operable at fleet scale.

Plane Owns Example
Data plane The actual running agent, tools, sandbox, process, browser, filesystem, and model calls A Claude Code process in a VM, a Hermes worker, a LangGraph run
Control plane Desired state, provisioning, routing, credentials, schedules, policies, observation, approvals, lifecycle Agent Machines, a cloud agent console, a managed workflow dashboard

The analogy is Service Mesh and Service Discovery Architecture and Kubernetes: the data plane does the work, while the control plane decides what should exist, where it runs, what it may access, and how operators see it.

Agent Company OS gives the same control-plane idea an organization model: department leads own KRs, memory-skill overlays keep workers scoped, and the runtime command plane owns wakeups, cron, permissions, model routing, and proof ledger state. Source: X/@DerekNee image, 2026-06-25

Core components

Component Responsibility
Identity and tenant model Users, orgs, service accounts, agent identities, access boundaries
Capability registry Approved runtimes, skills, MCP servers, CLIs, tools, model providers, and presets
Provisioner Creates and destroys sandboxes, persistent machines, browsers, volumes, and runtimes
Credential broker Stores and injects model keys, service tokens, OAuth grants, and scoped secrets
Router Chooses runtime, model, substrate, region, and tool path for a workload
Scheduler Cron, timers, wakeups, queued runs, backoff, and retry policies
Run/session store Durable record of runs, machine state, artifacts, traces, approvals, and logs
Policy engine Permissions, approval gates, spend limits, network rules, tool allowlists
Observation surface Live status, logs, traces, screenshots, costs, health, and task outcomes
Operator interface Dashboard, CLI, MCP/API, webhooks, Slack/mobile approvals
Billing and quotas Usage attribution across model calls, machines, storage, and tool providers

Control flow

IRL comparison

System Control-plane lesson
Kubernetes Desired state, reconciliation, scheduler, API server, and controllers make many containers operable. Agents need a similar management layer when they become long-lived workers.
Vercel / cloud PaaS Developers pay for deploy, routing, logs, env vars, preview URLs, rollback, and domain wiring, not just a Node process. Agents need the same productization.
LangSmith / managed LangGraph Tracing, evaluation, deployment, and prompt/version management become the operational layer around LangGraph runs.
Agent Machines The product thesis is a neutral control plane for persistent skilled workers across runtimes, substrates, skills, and model routes.
Enterprise MCP/governance tools Capability discovery is not enough; orgs need approval, inventory, audit, and revocation. See Agent Capability Registry.

2026 state of the art

  • Neutral routing. Model, runtime, and substrate are separate axes. Agent Machines frames this as OpenRouter for agents and containers.
  • Persistent workers. The control plane needs pause, wake, fork, snapshot, volume, and resume semantics, not only "start a job."
  • Recursive operation. A human is one caller, but a head agent may also provision workers through MCP/API and supervise them.
  • Governed capabilities. MCP, skills, CLIs, and remote agents must pass through a registry and policy layer before use.
  • Trajectory-aware observability. Logs are insufficient. Operators need model/tool/handoff/approval traces and artifacts to evaluate behavior.
  • One-click cancel and rollback. Long-running autonomy without interruption paths is a liability.

Invariants

  • The control plane is the source of desired state; workers report observed state.
  • A worker can disappear without erasing the run record.
  • Credentials are injected by policy, not pasted into prompts.
  • Routing decisions are recorded so failures can be reproduced.
  • Every destructive or costly capability has an approval or budget boundary.
  • Operators can answer: who ran what, where, with which tools, at what cost, and with what outcome?
  • Department leads can dispatch work, but worker output is not complete until it returns proof artifacts that update the workspace brain or memory/skill system.

Kevin-stack implication

Any serious agent product in Kevin's ecosystem should identify whether it is building:

  • a harness,
  • a runtime,
  • a control plane,
  • a capability registry,
  • or a vertical preset on top.

Confusing those layers is how products become a pile of buttons around a terminal. The control plane is the company when the user is paying to avoid rebuilding deployment, observation, permissions, and routing.

Architecture Position

Axis Value
Family Agent runtime and control plane
Boundary owned Fleet operation: provisioning, identity, credentials, scheduling, observation, policy, billing.
Read with Agent Runtime Architecture, Agent Harness Architecture, Agent Machines
Use this page when designing a platform that manages many agents/workers

Timeline