AI Agent Control Plane: The Layer That Has to Answer for the Fleet

Containers went through this. Docker made it easy to package and run something; running fifty of them across ten machines without orchestration was a mess, and Kubernetes brought scheduling, health checks and resource limits to the fleet as a whole. Nobody now argues you should run a production container fleet without that layer.

Agents are on a similar path, with one difference that changes what the layer has to do. A container fleet answers to its operators. An agent fleet, in a regulated sector, eventually has to answer to somebody outside the company.

The sprawl underneath

The shape is consistent across companies. The backend team built something with LangChain. The data team runs a CrewAI crew. Marketing has an assistant on a provider SDK. Someone in operations wrote a Python script that has quietly become production. Each brings its own logging format, its own cost accounting, its own notion of what an agent even is.

The visible symptom is reconciliation. Asked for total model spend, four teams produce four numbers that do not agree, because each tool computes cost differently and none of them is wrong about its own scope. The less visible symptom is that no single person can say what the fleet is permitted to do, which is the thing a questionnaire asks about.

The question only the fleet can answer

For a company selling AI into financial services, the control plane stops being an operations concern the day a vendor-risk pack arrives. The questions are not about your architecture. They are: which systems act without a person, what bounds them, and produce the record for the period under review.

All three are answerable only at the fleet level. An individual framework can tell you about its own agents. None of them can tell you about the ones built somewhere else, and a reviewer is not asking about the ones you remembered.

A fleet you can describe is not the same as a fleet you can evidence. The gap between them is where vendor reviews stall.

What the layer is actually for

A control plane is not another framework. It does not replace CrewAI or LangChain, any more than Kubernetes replaced Docker. It sits above them and does four things none of them can do alone:

• **Connect** — reach agents built on the frameworks your teams already chose, over whichever protocol they speak. How much work this is depends on how each agent was built: frameworks using a standard client underneath are straightforward, agents that construct their own requests need individual attention.
• **See** — a tamper-evident record of actions, cost attributed to the agent that incurred it, and behaviour observable across frameworks rather than per-framework.
• **Control** — approval gates on consequential actions, a halt that does not require a deploy, spend bounds, and model restrictions applied consistently rather than reimplemented per team.
• **Scale** — workspace isolation, regional data residency, single sign-on and role-based access, so the layer survives contact with an actual enterprise.

These compound. Connectivity produces data; data makes behaviour observable; observation is what policy can act on; and the resulting record is what lets an organisation extend trust to more agents. Remove one and the others degrade — a layer that connects but cannot evaluate is a dashboard, and one that evaluates without seeing the whole fleet is enforcing policy on a sample.

Coverage is the honest part to interrogate

Any vendor, us included, should be pressed on what they cannot see. Coverage depends on what each platform emits: some surfaces expose full request and response content, others expose only metadata, and a few expose nothing useful at all. A layer that reports uniform confidence across all of them is not measuring, it is assuming.

This is why a verdict needs somewhere to put "I could not verify this". A pass and a fail are the easy cases. The state that keeps a compliance report honest is the one saying the available telemetry was not sufficient to prove this control — because the alternative is a green tick that means nothing.

Why the timing has changed

Two things shifted. Deploying an agent got easy, so there are more of them in more places, built by people who are not on a platform team. And the obligations arrived: DORA has been in force since January 2025 and flows down from the financial entity to its providers, SOC 2 expects access control and change management, and the EU AI Act sets record-keeping and human-oversight duties for high-risk uses — with high-risk enforcement deferred to December 2027, which makes it the horizon rather than the deadline.

The deadline that binds sooner is commercial. Bank procurement is asking for AI documentation now, ahead of any statutory date, and a vendor that cannot produce it stalls in review.

What to ask when evaluating one

Five questions that separate categories usefully, without needing anyone to be dismissive about anyone else's product:

• Does it work with the frameworks we already run, and what specifically does connecting each one require?
• Is the audit record tamper-evident in a way a third party can verify without trusting us, or does its integrity rest on our own assurance?
• When it cannot verify a control, does it say so — or does insufficient evidence come back as a pass?
• Can data stay in the region our customers require, and which parts of it genuinely do?
• Can we halt agent activity without shipping code, and is there a record of the last time that was exercised?

The second and third are worth pushing hardest on. Plenty of tools produce a compliance view; far fewer will tell you where their own visibility ends.

In the path, or beside it

There is a genuine architectural fork here. A control plane can sit in the request path and gate every call, or beside it, reading what agents emit and evaluating out of band. Both are defensible; they fail differently.

Dobby is out of band by default: it reads run telemetry rather than proxying traffic, so it is not a dependency of your production path and cannot take your agents down. The trade is equally plain — a layer that is not in the path cannot block a call on its own. Where a decision has to be enforced in-line, the agent's code becomes the enforcement point by asking for a verdict and acting on it. That is opt-in, and it does add time to the call it guards.

The connection itself is ordinary. For agents that use a standard client underneath, it is a base URL and a key:

import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: 'gk_svc_your_service_key',
  baseURL: 'https://dobby-ai.com/api/v1/gateway'
});

Where to start

Start with the inventory, because it is the artefact everything else depends on and the one most teams cannot produce on request. List the agents, the framework behind each, the credentials each holds, the systems each can reach.

Then get telemetry landing centrally, so cost and behaviour are observable at all. Then write down what is permitted. The organisations that do well here are not the ones running the most agents — they are the ones that can answer a stranger's questions about last quarter with records instead of assurances.