An agent control plane is the surface a person uses to see what a fleet of autonomous agents is doing and to authorise what it does next: which bots exist, what state each is in, what they are spending, and the closed set of actions a human may take against them. The agents themselves run somewhere else. The control plane holds the view and the verbs, and nothing else.
The phrase is borrowed from networking, where a control plane decides how traffic should move and a data plane moves it. The borrowing is exact and worth keeping straight. For a team of bots, the data plane is the machine where engines run, files are written, and money is spent. The control plane is the thing you open in a browser to find out what happened overnight and to decide what happens next.
Most teams end up with one whether or not they meant to. It starts as a Slack channel, acquires a spreadsheet, and gets a dashboard bolted on the first time somebody asks a question nobody can answer. This guide covers what such a surface has to do to be worth building, what it has to refuse to do to be worth trusting, and how to judge one you did not build.
The four questions it has to answer
A control plane that cannot answer all four is a status page with ambitions.
What exists. Which bots, in which units, holding which roles, under which budgets. This is the organizational question, and it has a correct answer only if the organization is written down somewhere the runtime reads — which is the case for an org chart written as code and is not the case for a diagram.
What state each thing is in, and how old that answer is. A bot is paused or ticking. A duty ran or did not. A credential slot is connected or was never configured. Every one of those readings has an age, and the age is part of the reading.
What it costs. Spend per bot, per unit, and per run, close enough to the action that a person can connect one to the other. Cost that only appears on an invoice is not observability, it is archaeology.
What happened. Who asked for what, who approved it, what the machine actually did, and when each of those occurred — kept in a form that reads the same next quarter as it did on the day. That is the subject of audit trails for AI agents, and it is the part most implementations discover they need after an incident rather than before one.
Provenance is half the reading
A number on a dashboard has two timestamps and both matter: when the fact was true on the machine, and when the control plane learned it. A single “last updated” collapses them and produces a class of quiet lie in which a stale reading looks current because the page itself was rendered a second ago.
Klingbar renders both clocks on every panel and classifies staleness rather than hiding it. The rule underneath is simple and unglamorous: the surface never invents a green state. A document the runner has not reported reads “not reported” rather than zero, because absent and zero are different facts and only one of them is good news. A degraded organization never renders in the calm colour. A fetched log body that has aged past its retention window reads expired rather than current.
This is the property that costs the most to hold and pays back the most. Every convenience that fabricates a default — a missing count shown as zero, an unknown state shown as healthy — trains people to stop reading the page, and a page nobody reads is worse than no page, because its existence is used as evidence that somebody is watching.
The verb list is the product
The most consequential design decision in a control plane is not what it displays. It is the list of things it can cause.
An unbounded surface — one that composes shell commands, forwards arbitrary configuration, or exposes an escape hatch “for advanced users” — has the security posture of the machine it talks to, minus a session cookie. A closed vocabulary inverts that. Klingbar drives exactly thirty-six wire verbs. The browser never composes an argument list; it names a verb and supplies operands that are validated against that verb’s schema on both sides of the wire. A verb that does not exist cannot be smuggled through as a flag, and no verb carries a key, a token, or a signing secret as a parameter.
Closing the list has a second effect that is easy to miss: it makes the gates enumerable. When there are thirty-six things that can happen, you can state, per verb, which ones need a human and what shape that gate takes — the subject of human approval workflows. When the surface can cause anything, “which actions need approval” has no answer that survives contact with the next feature.
Dial out, not in
A control plane that reaches into your machines needs a route to them: an inbound port, a tunnel, a set of credentials with standing access. That is a large surface to defend for the sake of a dashboard.
The alternative is to make the machine the client. The runner dials out, pushes what it wants seen, and claims commands off a queue when it is ready. No inbound port opens, no firewall exception is needed, and a machine that goes quiet simply stops reporting — which the control plane renders as a stated fact rather than as silence.
Klingbar authenticates each of those calls with a signature over the method, path, and body digest, verified against a public key it stored at pairing time, inside a bounded time window. Only public keys are stored, so a database compromise forges nothing. The trade is real and worth naming: a dial-out design cannot make anything happen immediately. Commands wait in a queue for the next claim, and the surface has to say so rather than animating a spinner that implies otherwise.
What it must never hold
The strongest statement a control plane can make is not about how it encrypts things. It is about what it never has.
Klingbar stores public keys and relays ciphertext it cannot open. A credential is sealed in the browser to the runner’s own key before it leaves the page, travels the vocabulary as an opaque parameter, and is opened only on the box that will use it; the mechanics are in the guide to sealing agent credentials. Snapshots carry handles and short references rather than values, and an entropy tripwire on the ingest path treats a secret-shaped string in a snapshot as a defect rather than as data.
The test to apply to any candidate — including one you are building — is not “are secrets encrypted at rest”. It is “is there a code path in which a secret arrives here in the clear at all”. Those are very different questions, and only the second one has an answer that survives a subpoena, a support session, or a stray log line.
The box keeps a veto
An unattended machine has to remain recoverable when the console is unreachable, wrong, or compromised. That means some gates must be clearable from the machine itself, and it means the machine’s own operator can refuse a command the browser is confident about — including a command to rewrite the machine’s own configuration or to replace its own binary.
Klingbar keeps that asymmetry deliberately. A person at the runner’s command line can clear or veto the gates that block, and the console has no verb that starts a daemon which is not running, because a control plane that could do that would be a control plane you had to trust absolutely. This is the same reasoning that makes self-hosted agents a coherent posture rather than a compromise: the box is the authority, and the browser is a way to ask it politely.
How to judge one
Eight questions, in the order that finds problems fastest. Does it show two clocks or one? What does it render when it does not know something? Can it cause anything that is not on a list you can read? Which actions require a human, and is that mapping fixed per action or decided per call? What does it hold that would matter if it were breached? Can the machine refuse it? Is the record of decisions append-only, or can it be tidied? And does the whole thing degrade into an honest read-only view when billing lapses, when a runner goes quiet, or when a feature is not yet available on that box — or does it fail in a way that hides the fleet?
Regulators are converging on the same instinct from the other direction: the EU AI Act’s Article 14 obliges providers of high-risk systems to design them so that people can actually oversee them, and the NIST AI Risk Management Framework treats traceability as a governance function rather than a feature. Neither tells you what to build. Both make the same point this guide does: oversight that was not designed in is not available later.
Build the smallest control plane that answers the four questions honestly, close its verb list before you close anything else, and hold the line that it never learns a secret. Everything else is presentation.