Gartner forecasts that Fortune 500 companies will run more than 150,000 AI agents by 2028, up from fewer than 15 today. The way a company governs 15 agents does not carry over to 150,000. Most enterprises are building the first while the second arrives.
The category
The agent control plane is Kirto’s name for the layer that governs the second. Kirto states its job as: Observe, govern and prove every AI agent, across every vendor.
- Observe means seeing what an agent does while it does it, from a position the agent cannot route around.
- Govern means deciding at the moment of the call whether it goes ahead, under rules somebody wrote down beforehand.
- Prove means leaving a record that a third party can check without trusting the system that wrote it.
- Across every vendor means all three hold whichever model the agent calls, whichever framework built it and whichever runtime executes it.
The agent control plane is the layer that meets all four. Part 1 of this series argued that AI multiplies the places agents run. Part 2 argued that no platform can govern the agents it competes to host.
Where the word comes from
In networking and in Kubernetes, the control plane configures the data plane. The Kubernetes control plane holds cluster state, schedules workloads and decides policy, and the data plane carries the traffic. A control plane in that sense stays out of the call.
Kirto uses the word for the plane that controls agents. The agents’ calls and processes are what it controls, so the half that enforces sits in those calls. Gate is on the request path between an agent and the model, tool or peer agent it calls. Flow runs the process the agent is a step of. In infrastructure vocabulary, Gate is a data plane that is allowed to refuse a call. It also has a control plane of its own in the strict sense: a raft cluster that agrees its configuration, keys and budget spend across nodes and serves them to every node. The category’s name describes what is controlled, and that is the agents.
What analysts mean by it
Forrester Principal Analyst Leslie Joseph published the most formal definition in late 2025: an enterprise control plane that inventories, governs, orchestrates and assures heterogeneous AI agents across vendors and domains. Forrester organises it around five capabilities: agent inventory and identity; policies and guardrails; monitoring and insights; control and coordination; and risk, compliance and auditing.
Forrester separates three planes. The build plane is where agents are made. The orchestration plane, which Forrester calls adaptive process orchestration, is where processes coordinate agents, people and systems. The control plane governs the orchestration plane from outside it. Forrester’s reason is that governance needs independent visibility, consistent policy across environments, and control when a runtime behaves unpredictably. An orchestration layer that governs itself has nobody checking it.
Kirto follows Forrester’s names. Flow sits in adaptive process orchestration. Gate sits outside every orchestration plane, Flow’s included, on the calls agents make. Kirto as a whole is the agent control plane. Neither product is the control plane on its own.
Gate stands on the calls that leave any plane: from Flow’s processes, from other engines, and from agents that run under no orchestration.
flowchart LR B["Build plane: agents from any framework"] --> O["Orchestration plane: Flow and other engines"] B --> G O --> G["Gate, on every call"] G --> U["Models, MCP tools, peer agents"] G --> S["Signed audit trail"] O --> R["Flow case record, replayable"]
What it requires
A layer missing any of these fails at the case it cannot see.
Every vendor. Governance that covers one vendor’s agents ends at that vendor’s perimeter, and every new framework or model provider opens a gap. Gate covers this half. It speaks the OpenAI and Anthropic APIs, MCP and A2A, and passes a request through byte for byte when the client and the provider share a dialect. Whether an agent is governed does not depend on who built it.
Observation at runtime, from outside the loop. An audit of the plan says nothing about the execution. Which tools the agent called, what it sent and what came back can be recovered after the run only where something outside the agent recorded it. Gate records each call’s decision from the request path. Flow records each agent turn in the case record.
Enforcement outside the loop. Kaptein et al. (2026) put the limit of instructions plainly: “Prompting merely reduces the probability of policy-violating paths; it provides no enforcement.” Enforcement needs a mechanism the agent cannot reason around. Gate’s access rules and detectors run in a separate process, on the connection the agent needs to reach the model or the tool. A refused call never reaches its destination.
Readable intent. A compliance officer cannot review a raw execution log, and a regulator cannot take a code-first engine’s event history as a submission. Flow’s processes are BPMN, CMMN and DMN, standards a process owner and an auditor read without a developer. Its case record names the process element behind each command and the DMN rules that matched behind each decision.
Portability. Process definitions written to a standard survive a change of runtime. Flow’s engines are deterministic reducers that do no I/O, driven by interchangeable durable hosts. The default is Flow’s own broker, a replicated log that needs no Postgres on a single node. DBOS on Postgres runs the same engines. An agent’s model and tools are declared in its own spec, apart from the process. A model upgrade changes the spec and leaves the BPMN as it was.
Proof. The record has to come from the system that acted, in a form a third party can check without trusting that system. Gate’s trail is a per-node hash chain signed with ed25519, and kirto-gate audit verify names every record that was altered, removed, moved or forged. Flow’s record re-derives: kirto-flow-replay re-feeds a case’s recorded inputs through a fresh engine and reports whether the stored chain matches.
How Kirto divides the work
Gate watches every agent from outside its loop. Flow runs the processes agents work inside. Both leave proof.
The unauthorised tool call. An agent calls an MCP tool it was never meant to reach. Gate’s access rules read the server, the method and the tool name from the request body, and the key’s rules refuse it. The refusal is a signed record carrying policy_denied and the name of the rule. It does not depend on the agent having been told to log anything.
The mid-flight crash. A workflow fails after 47 steps. Flow’s engine holds the whole state of the run as data, and each external effect runs in the host as a journalled step outside the engine. A durable host resumes from the last recorded state, and the record says which steps committed.
The regulator’s question. A regulator asks for every AI-driven credit decision in Q3, with the reasoning for each. Flow’s case record holds each branch condition with its expression and result, each command the process dispatched, and each agent turn with the model’s response, readable per case through the history API. Gate’s trail shows which calls each key made and what the rules and detectors decided about them. Both records exist before the request arrives.
The model upgrade. A new model beats the current one on a workload. In Flow the change is the provider and model in the agent spec. In Gate it is a provider entry or a model alias, and clients keep calling the same name.
What Kirto does not do
Gate authors no policy. It keeps no risk register, no control library and no questionnaire, and has no opinion about which framework you follow. It takes rules somebody decided, enforces them in the call and signs what it did. A governance platform that owns the register writes its rules into a configuration source it owns, each rule naming the controls it stands for, and reads the decisions back from the trail. See connect your AI governance platform.
Gate’s trail proves what the node’s key signed. Retaining it is the collector’s job. Its records carry no prompt content. Gate sees the traffic sent through it, or shown to it over ext_proc by a gateway you already run. An agent that reaches a provider by another route is outside what Gate sees, and closing that route is a network control.
Flow runs the processes you model in it. Discovering agents that run elsewhere and governing their calls is Gate’s half. Flow’s case record is verified by replay against the pinned model and carries no signature of its own.
Kirto builds no agents and trains no models. It has no agent framework to adopt.
Why standards hold it together
Forrester’s evaluation of the market found three standards missing for a control plane that spans vendors: OpenTelemetry semantic conventions for AI, a portable agent identity, and schemas for propagating policy across planes.
OpenTelemetry’s conventions for AI are incomplete. Telemetry in proprietary formats does not compose across vendors. Gate exports traces in the OpenTelemetry GenAI semantic conventions and writes its audit records on the OpenTelemetry Logs API. Flow’s agent turns carry the same GenAI attributes.
No portable agent identity exists. An agent’s governance identity does not travel with it between environments. Gate identifies a caller inside one deployment, by a gateway-issued key or by a token from the deployment’s identity provider. A portable identity across vendors is still missing from the market, and Kirto does not claim to supply one.
No schema carries policy from one plane to another. Each vendor encodes policy in a format built for its own runtime. Gate’s access rules are written in CEL, the expression language Kubernetes admission policy uses, and each rule can carry the identifiers of the controls it implements.
BPMN, CMMN and DMN predate the current AI wave by years. Regulators recognise them, auditors read them, and they outlast vendor consolidation. A process definition in BPMN belongs to the enterprise that wrote it and runs on any engine that implements the standard.
The job
The agent control plane gives three readers the same two records: the enterprise running the agents, the regulator overseeing them, and the engineer on call when one goes wrong. Each reads it without trusting the agent that acted. Self-hosted: the control plane runs in your network. The platform overview shows how Gate and Flow fit together.