An agent control plane is the surface a person uses to see what a set of autonomous agents is doing and to decide what they do next: which agents exist, what state each is in, what they are waiting on you for, and the closed set of actions you may take against them. The agents themselves run somewhere else. The control plane holds the view and the verbs.
The phrase is borrowed from networking, where a control plane decides how traffic should move and a data plane moves it. In Klingbar the split is literal. klingbar.com is the control plane: it holds what a crew is — its configuration, prompts, standing rules, learnings, members, and approvers — and the record of what it did. The box is the data plane: a machine you control, running one daemon, where engines run, files are written, and every secret lives. The box is also the source of truth for what is happening right now.
Most teams end up with a control plane 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 crews, which personas on each roster, which channel each reports in, which seat each runs on, and which tasks run on which schedules. This has a correct answer only if the shape is written down somewhere the runtime reads. In Klingbar that is the crew’s versioned configuration, covered in org chart as code.
What state each thing is in, and how old that answer is. A box synced thirty seconds ago, or it has gone quiet. A run finished with a verdict, or it is still going. A card is waiting, decided, or being carried out. A Slack token passed its check, or it was never delivered. Every one of those readings has an age, and the age is part of the reading.
What is waiting on you. Open cards, open questions, proposed learnings. A control plane for agents that act on their own is mostly a queue of decisions, and the rest is context for making them well.
What happened, and what it cost. Who asked for what, who decided it, what the box did, and what each run spent as the engine reported it: tokens, turns, and the engine’s own cost estimate where it gives one. klingbar.com records spend; it does not compute a budget or stop a run for cost. The record itself is the subject of audit trails for AI agents.
Freshness is half the reading
A number on a page has two timestamps: when it was true on the box, and when the control plane learned it. A single “last updated” collapses them and produces a quiet lie, in which a stale reading looks current because the page was rendered a second ago.
Klingbar keeps both. Every event carries the box’s own time and the time it arrived. A box syncs every 30 seconds by default, and one that goes five minutes without a sync is marked stale, with one email per transition rather than one per check.
The rule underneath is that the surface never invents a green. Anything the box did not report renders “not reported”, which is a different fact from zero and a different fact from empty. A crew on no box says so, and “this crew is on no box” is kept distinct from “we could not read the box it is on”, because a broken read must never invite you to pair a second box. A daemon too old to report a field gets “not reported” for that field, not a healthy default.
Even a fresh sync is not proof that all is well. A box whose home directory is moved underneath a running daemon can keep syncing while its writes land somewhere empty. The daemon checks for exactly that every 30 seconds: a box that cannot prove its own home refuses every write and says so, and its page reads faulted rather than green. The general lesson is broader than that one fix — a heartbeat only measures the heartbeat.
The verb list is the product
The most consequential decision in a control plane is not what it displays. It is what it can cause.
An unbounded surface — one that composes shell commands, forwards arbitrary configuration, or keeps 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.com can send a box exactly 17 verbs: run, pause, resume, schedule, cancel, digest, decide, answer, learning.decide, doctor, slack.otp, channels.join, secret.transfer, import.legacy, upgrade, crew.retire and seat.switch.
Each verb declares a closed set of parameter keys, and a verb with none declares that explicitly. klingbar.com never builds an argument list: it names a verb and supplies values, and the box builds its own command lines from them. The list is pinned by a test on each side of the wire, so a verb added on one side and not the other fails a build rather than a box.
What is missing from the list is as deliberate as what is on it. No verb carries credential material — a sealed secret travels as an opaque parameter. No verb starts or stops the daemon. No verb mints an approval: the box mints cards, and only a decision travels back.
Closing the list makes the system something you can reason about. With 17 things that can happen, you can read the whole list, say what each one touches, and know that nothing else can be caused from a browser. A decision from the web counts only if it comes from the crew’s owner or from a member whose Slack identity is linked and on the approver list. The shape of the approval itself is covered in human approval workflows.
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 standing credentials. That is a lot to defend for the sake of a dashboard.
Klingbar makes the box the client. The box dials out over HTTPS, pushes what it wants seen, and picks up commands on its next sync. klingbar.com never reaches a box: no inbound port, no listener, no firewall exception. Every request after pairing is signed with the box’s Ed25519 key, over a timestamp, the method, the path, and a hash of the body, and checked against the public key stored when the box paired. Only public keys are stored, so a database leak forges nothing.
Events are written to disk on the box before anything is sent, and trimmed only once klingbar.com acknowledges them. A box that loses its connection for a day loses nothing; the history ships when it reconnects.
The trade is real and worth naming: a dial-out design cannot make anything happen instantly. A command waits for the next sync. One nobody picks up expires after 24 hours by default, and one delivered to a box that then goes silent is redelivered once and then marked failed. The surface has to say which of those happened rather than animate 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.com holds no private key: the box’s signing and sealing keys live on the box and never leave it. It holds no plaintext secret: a credential is sealed in your browser to the box’s own public key before it leaves the page, relayed as ciphertext klingbar.com cannot open, and deleted once the box confirms it arrived. The one credential it does hold is each Slack workspace’s bot token for Klingbar’s own Slack app, encrypted under a server key; it never holds a box’s Slack token. The web shows that a secret is present — and, for Slack tokens, whether Slack accepted them — never a value and never a length. It holds no engine login either: you log in to the engines on the box, and your own subscriptions pay for the runs. The details are in sealing agent credentials.
The test to apply to any control plane, 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”. Only the second question has an answer that survives a support session or a stray log line.
The box keeps the last word
An unattended machine has to stay safe when the console is unreachable, wrong, or compromised. In Klingbar several decisions stay with the box on purpose.
The box builds its own command lines. Its own loader judges every rendered configuration: a version it cannot load is rejected with the loader’s error, and the last good one keeps running. It checks a Slack approver against its own list when a button is tapped. It takes a new release on its own only after that release has been advertised for 30 minutes, and [box] auto_upgrade = false pins it where it is. Starting and stopping the daemon happens on the box and nowhere else. That asymmetry is what 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.
How to judge one
Eight questions, in the order that finds problems fastest. Does it show how old each reading is? What does it render when it does not know something? Can it cause anything that is not on a list you can read? Which of those actions need a human decision, and whose? What does it hold that would matter if it were breached? Can the machine refuse it? Is the record of transitions append-only, or can it be tidied? And when a box goes quiet or an older daemon cannot report a field, does the page degrade into an honest “not reported”, or does it quietly keep painting the last good value?
Regulators are converging on the same instinct from the other direction: the EU AI Act’s Article 14 asks that high-risk systems be designed so 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 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 it relays. How Klingbar puts those pieces together end to end is on how Klingbar works.