The AI platform team needs a place for the yes

Kevin Ferron has written a good piece on the AI platform team: the team he expects most large enterprises to have within two years, the way cloud gave us platform engineering and data gave us the data team. He is careful to call it a forecast. We think he is right about the shape, and we want to add one thing about the job.

Six things to own

Ferron gives the team six things to own: a gateway for model access, a registry of tools, agent identity, evaluations, cost control and policy. Then he lists what each kind of agent needs from it. Coding agents need repository permissions and gates that changes must pass. Research agents need budgets and tool access. Support and operations agents need identity, scoped permissions, an audit trail, and an escalation path to a person for actions that move money or cannot be undone.

That last line is the one we build for, so it is the one we want to look at closely.

Most of the list is plumbing, and you can buy it

A model gateway routes requests, holds keys and counts tokens. Several good ones exist. Evaluation platforms run test sets and score them. Identity providers already know who people are, and are learning about agents. A platform team can and should buy most of this, and the article's own build-versus-buy evidence points the same way.

Policy is different. Policy is where the platform team has to answer a question no gateway can: this agent wants to refund a customer €1,240, or drop a table, or email 3,000 people. Is that allowed? If not by a rule, by whom? And afterwards, can anyone show what they were asked and what they said?

Why the gateway cannot answer it

A model gateway sees the request to the model. It does not see the decision. By the time the model has proposed a tool call, the gateway's work is done, and the call itself goes from the agent to the tool. The point where a person should be asked is that call, not the model request before it.

So the yes needs its own place. It needs rules the platform team writes once and every agent follows. It needs a route to the person who owns the decision, wherever they work. And it needs a record that does not depend on each product team remembering to keep one.

What we built for it

Deliverd is that place. An agent declares what it is about to do. Your rules settle the routine cases, and anything no rule covers goes to a person, in Slack, Teams, email or on a phone. The answer, the rule and what ran are kept as one record.

For a platform team, two pieces matter most:

• Tools behind a gateway. Put an MCP server or an HTTP API behind Deliverd and keep its credential there. A call that changes something reaches the server only after a rule or a person has said yes. An agent that still holds the server's own credential can go around it, so the gateway has to be the only way in.
• It sits beside the gateway you already run. Deliverd checks tool calls, not model requests, so it works with any model gateway. We wrote recipes for apps on the AI SDK and for APIs behind Azure API Management.

What it does not do

Deliverd is not a model gateway. It does not route, meter or limit model requests, and it does not run evaluations; it can pull results from Langfuse, LangSmith, Braintrust and Weave in as evidence for a release decision. Agent identity is partly ours (each agent has its own name and keys) and partly your identity provider's. Of Ferron's six, we cover policy and parts of tools, identity and evaluations. Model access and cost stay with the tools that own them.

We think that is the right split. The platform team should buy the plumbing and spend its own time on the rules. Deliverd is where those rules run, and where the yes is kept.

If you run, or are setting up, an AI platform team, we would like to hear what is on your list.