Blog

Why your agents need a control plane

A single LangGraph (or CrewAI, or Autogen) script is fine — until secrets, human approvals, kill switches, and audit logs have to work the same way for every agent you ship.

The moment one script stops working

You start with one graph, one .env, one deploy. Then a second agent needs the same GitHub token. A third needs HITL on a write tool. Someone asks “who called Salesforce last Tuesday?” and the answer is three log formats and a Slack thread.

That is not a framework problem. Frameworks are good at thinking. The gap is operating: credentials, admission, reclaim, kill, spend, audit — shared across agents and languages.

What a plane is (and is not)

Runkite is a control plane for agents. Clients talk Agent Protocol to the plane. Workers talk Runner Protocol to the plane. The plane owns run lifecycle, connector sessions, grants/HITL, fencing under reclaim, and audit.

It is not:

The split that matters

Clients create threads and runs. Runners execute your graphs wherever you already run them — laptop, Kubernetes, your VPC. The plane does not need to own your compute; it needs to govern what that compute is allowed to do when it calls out.

Connectors mint short-lived sessions. Optional secret_ref keeps long-lived Vault/K8s secrets out of agent env. Optional Postgres RLS is defense-in-depth under application tenant filters. Kill and break-glass are operator tools, not afterthoughts.

When to skip it

Still prototyping prompts on one laptop? Stay in the framework. One agent, one env, no shared connectors? You do not need a plane yet. Need a fully hosted cloud CP today with no self-host path? That is on the roadmap (CLOUD) — self-host is what ships first.

Try it

Five-minute try · Why a plane (docs) · Big picture chapter · Blog index

Next in this series: Two protocols, one plane — the mechanism that actually makes "any framework, one plane" true.