Why a control plane?
A single LangGraph (or CrewAI, or AutoGen) script is genuinely fine — right up until you have more than one of them, and they all need the same credentials, the same "pause and ask a human" behavior, the same emergency stop, and the same answer to "what did this agent actually do last Tuesday." That's the point where copy-pasting the same glue code into every agent starts costing more than building it once, in one place.
What actually breaks first, in practice
It's rarely the agent logic itself. It's usually one of these, showing up right as you try to ship a second or third agent:
- Secrets — the same Salesforce/GitHub token gets copy-pasted into every agent's environment, and now revoking it means finding every place it was pasted.
- Human approval — one agent needs "pause before sending an email," another needs "pause before a refund." Each team reinvents this from scratch, differently, with different bugs.
- Emergency stop — an agent misbehaves in production and there's no single button to stop it; someone has to find the process and kill it manually.
- "What happened?" — three agents, three different logging formats, and the honest answer to "who called Salesforce last Tuesday" is a Slack archaeology project.
A control plane is where you solve each of these once, centrally, instead of once per agent. Your agent code keeps using whatever framework it already uses — LangGraph, CrewAI, plain LangChain, whatever — the plane sits underneath and handles the parts that have nothing to do with what the agent is actually thinking about.
- You have (or will soon have) more than one agent that needs the same connectors, human-approval rules, kill switch, and audit trail.
- You want a clean split: clients talk a stable Agent Protocol API, workers (in any language) talk a separate Runner Protocol — so you can change frameworks or add a second language without touching client code.
- You need admission and failure handling that fails closed by default (a misconfigured deploy refuses to start rather than quietly running insecurely), and a worker crash mid-job to be handled correctly instead of silently losing or duplicating the run.
- You have one agent, one environment, and nothing else needs to share what it uses.
- You're still prototyping prompts and don't have a "production" yet — add the plane when you do, not before.
- You need a fully managed cloud control plane today with zero self-hosting — Runkite is self-host first; a hosted option is on the roadmap, not available yet.
Next: Scenario — a worked example of the "without a plane" vs "with Runkite" difference · Try it — see it running in 5 minutes · Big picture chapter