You can't buy an AI platform off the shelf

In my last post I argued that AI proved code was never the bottleneck. It made the typing cheap and left the real constraint standing in the open: the months-long gauntlet of tickets, approvals, reviews and handoffs a change runs before it reaches production.

The natural response, and the one I keep seeing, is to point the agents at the gauntlet too. If AI can write the code, surely it can raise the ticket, find the approver and push the change through. So the budget goes to an “AI platform”, some combination of agents, copilots and connectors that promises to do exactly that.

I think that is the wrong purchase, and this post is about why. The short version is that an AI platform is not something you buy. It is something your organisation either already has the foundations for, or does not.

How long does it take to get an API into production?

Try this. Go and ask a developer in a large enterprise how long it takes to go from nothing to a new API running in production. Not a toy, a real service with a database, a pipeline, monitoring and a route the rest of the business can call.

You will most likely hear months.

Now ask them how much of those months they spent writing code. The answer is usually a small fraction, often days. The rest went on finding out who owns the thing they depend on, waiting for an environment, getting onboarded to three platforms, chasing an approval, and asking the one senior engineer who knows how the networking actually works.

That gap is the whole argument. We have spent the last couple of years buying tools to shrink the days. Almost nobody is shrinking the months.

An agent scales only as far as your platform enables humans

This is the idea I want to land more than any other, so I will say it plainly. An agent can only go as far as your platform already lets a human go without asking someone.

If a developer has to ask around to find out who owns a tool, guess how hard that is for an agent. If onboarding to your platform means a meeting, a form and a week of access requests, an agent is not getting onboarded. If consuming a capability means knowing which Slack channel to post in and who to tag, the agent does not have a Slack channel, a name to tag, or the social capital that gets a human’s request picked up first.

Humans are remarkably good at routing around a broken platform. They remember who helped last time. They know which wiki page is stale. They can read the room in a review and know when a “quick question” in a DM will unblock them faster than the official process. That is the invisible glue holding most engineering organisations together, and it is not available to an agent at all.

An agent faced with a gap has two options. It stops and asks, which puts a human straight back in the loop and wipes out the speed you paid for. Or it guesses, which is worse, because a confident guess about who owns a service, which environment is safe or what a standard says is how you end up with a very fast mistake.

So the ceiling on what AI can do in your organisation is not the model. It is the platform. Whatever a human can self-serve, an agent can too. Whatever a human has to ask for, an agent cannot.

Ways of working that are fine for people and fatal for agents

None of what follows is new. Most organisations have lived with these patterns for years, and for teams of humans with enough tenure they are survivable, even comfortable. They stop being survivable the moment you expect a machine to do the work.

Knowledge lives in threads and heads. Who owns the payments API, why the retry policy is set the way it is, which pattern is approved for event consumers: in most places the answer is a Slack or Teams thread from eighteen months ago, or a senior engineer who has been around long enough to remember. An agent cannot search someone’s memory, and it cannot tell which of four contradictory threads is the current truth. What it needs is services, owners and standards recorded somewhere it can query.

Workflows are clicked, not invoked. Creating a project, requesting a database, opening a firewall rule, rotating a secret. If the way to do it is a console, a portal form or a runbook that says “click here, then here”, it is invisible to an agent. Anything a human does by clicking, an agent can only do by pretending to be a human clicking, which is fragile at best. What it needs is workflows exposed as APIs that can be called, retried and audited.

Approvals happen by asking the right person. The change is safe if the right senior person says it is safe, and knowing who that is takes experience. An agent does not know who to ask, and even if it did, routing every agent-generated change through a person rebuilds the exact queue we were trying to escape. What it needs is policy enforced as code: the rules that person was applying, written down so they run every time, on every change, with no one in the path.

Each pair is the same story. The left-hand version works because a human fills the gaps with judgement and relationships. The right-hand version works because there are no gaps to fill.

What does a true AI platform need?

When I strip it back, a platform that can genuinely support agents needs three things: context, execution and governance. Context so the agent knows what is there and how things are done. Execution so it can actually do the work through an interface, not a person. Governance so it can be trusted to do that work without someone watching every step.

Context: can it find out what it needs to know?

Good context is the difference between an agent that guesses and an agent that knows. In practice it looks like:

Accessible service discovery. The applications, APIs, dependencies, environments and owners in your estate, recorded as data and kept current. Not a diagram on a wiki, a catalogue that answers “what calls this, who owns it, where does it run” with a query.
Organisational knowledge as code. Your standards, patterns, documentation and runbooks, versioned and reviewed like anything else that matters, living next to the things they describe rather than in a slide deck someone presented once.
Accessible interfaces. Service catalogues, knowledge bases and APIs that a person and a machine can both read. If the only way into your knowledge is a search box built for humans, you have locked the agent out.
Rules as code, so you know what not to do. This one gets overlooked. Context is not only “here is how things work”, it is “here is what is not allowed”. An agent that can read the rules before it acts makes far fewer mistakes than one that discovers them in a failed review.

Execution: can it actually do the work?

Knowing what to do is useless if the only way to do it is to ask. Execution is where the platform turns intent into action:

Strong golden paths. Repeatable, approved ways to do the common engineering work: a new service, a new database, a new pipeline, a new topic. Paved enough that taking them is easier than not.
Self-service workflows. Provision, test and deploy without undocumented manual handoffs. The word that matters there is undocumented. Every “and then you message Sam” buried in a process is a place an agent stops dead.
Automation that can be invoked, not clicked. Every workflow on the golden path has an API behind it. The portal, the CLI and the agent are all just different callers of the same thing.

Governance: can it be trusted to do the work?

This is the part that lets you take the human out of the path without losing your nerve. Governance is the rules from your context, enforced rather than merely published:

Policy as code at the point of change. Every request is checked against the same rules, every time, whether it came from a senior engineer, a graduate or an agent.
Guardrails over gates. The safe option is the default and the dangerous one is not on offer, so the ordinary change needs no approval at all.
Identity and audit for every caller. An agent acts with its own scoped, attributable identity, and everything it does is recorded. “The bot did it” is not an audit trail.
Humans for the genuine exceptions. People still make the calls that need judgement. They stop making the calls a rule could make for them.

Context tells the agent the rules. Governance makes sure the rules hold even when the agent, or the human, gets it wrong.

Why can’t you just buy this?

Because the hard part is not the AI. It is yours.

You can buy an agent. You can buy a copilot, a coding assistant, a connector for every tool in your stack. Plenty of vendors will sell you something with “AI platform” on the box, and some of those products are genuinely good. But every one of them plugs into whatever you already have. Point a brilliant agent at a stale catalogue, a contradictory wiki and a provisioning process that is really a ticket queue, and you get a brilliant agent that is stale, contradictory and waiting in the queue.

You can buy tools that hold context. You cannot buy your context. Nobody can sell you an accurate record of who owns your services, the standards your teams actually agreed, or the golden paths that reflect how your organisation really ships. Those come from doing the unglamorous platform work, and they compound only for the organisations that do it.

If your organisation will not invest in that foundation, it will spend a great deal on AI and then act surprised by the lack of return. The pilots will demo beautifully. The agent will write the code in minutes. And then the change will sit in the same gauntlet as everything else, for the same months, and someone will conclude that AI was overhyped.

The same investment pays off twice

Here is the reframe I think platform teams should be taking into every budget conversation. Everything on those three lists is just as valuable for people as it is for agents.

A queryable catalogue helps the new starter on their first day as much as it helps an agent. A golden path with an API behind it is faster for a developer than a ticket, whether or not an agent ever calls it. Policy as code means the human change goes through without a review queue too. None of this is speculative AI spend. It is the platform work we have been under-funding for years, which now happens to be the prerequisite for the AI everyone is already paying for.

That matters, because in the last post I talked about platform work losing every prioritisation fight against the shiny tool with a logo. This is how it stops losing. Platform investment is not competing with the AI budget. It is the part of the AI budget that makes the rest of it pay off.

Our platforms are falling behind

The uncomfortable truth is that the gap is widening. Agent capability is improving every few months. Most internal platforms look much the same as they did before any of this started: knowledge in threads, workflows in consoles, approvals in people. The tools are racing ahead and the ground they have to run on is standing still.

Every month that holds, the return on AI spend gets worse, not better, because the agents are more capable of doing work the platform will not let them do.

Doesn’t our existing self-service already cover this?

Most organisations will read the execution list above and think they are most of the way there. They have tickets with SLOs. They have infrastructure as code. Some have pushed it all the way into each team’s repository. It is worth being honest about where each of those stops, because every one of them was designed around a human in the loop.

Tickets. A person asks, a person does the work. It is legible and auditable, and it moves exactly as fast as the people working the queue. One engineer with an agent can now generate a week of requests in a morning. A queue staffed for human demand does not survive machine demand, and you cannot hire your way to a queue that does.

Pull requests to a central infrastructure repo. Getting to code is a genuine step up, and I would never argue against it. But look at what happens after the pull request is opened: it waits for a platform engineer with enough context to understand the blast radius, who is working through everyone else’s pull requests too. The human gate has not gone anywhere. It has moved from a ticket field to a review comment. That is a ticket wearing a pull request as a costume.

Infrastructure code in each team’s repo. This removes the central queue, and if you are here you are ahead of most. But the developer, or the agent, is still authoring infrastructure: the module, the provider, the account, the networking primitive underneath. Patterns get copied across dozens of repos and drift apart, and every one of those copies is something an agent has to read, interpret and hopefully get right.

Many front doors. Underneath all three sits a problem none of them fix. Most organisations do not have one platform team, they have several: cloud, APIs, events, observability, CI/CD. Each one picks its own way to be consumed. One is a ticket, one is a Terraform module in a specific repo, one is a YAML file in exactly the right place, one is “post in the channel”. A developer has to learn five front doors to stand up one service. An agent has to be taught all five, and taught again every time one of them changes.

Each of these is a reasonable answer to “how do humans get infrastructure”. None of them is an answer to “how does anything, human or agent, get infrastructure without a human on the other end”.

Can’t we just buy a developer portal?

This is usually the next move, and it deserves its own warning, because it is the same mistake as buying an AI platform wearing a different badge.

A developer portal, Backstage being the best known, is genuinely useful. A good one is the best discoverability tool most organisations will ever have: one place to see the services, the owners, the docs, the APIs and the golden paths. If your context is scattered, a portal is a great place to bring it together.

But a portal is an interface, and an interface is only as useful as the platform behind it. Watch what happens when someone actually uses one. They search for the thing they need, find the right page, and the page tells them to raise a ticket. Or the “create a database” button opens a form that lands in someone’s queue. Or the owner field links to a Teams channel, where they post and wait. The portal did its job perfectly. It found the front door. The front door was still a person.

People work this out fast. After a couple of trips that end in a channel, they stop opening the portal and go straight to asking, because asking is where they were always going to end up. Usage drops, the catalogue goes stale because nobody is looking at it, and a year later someone writes a slide asking why adoption is low.

The same is true for agents, only more so. Plugging an agent into a portal that ends in “ask someone” is just a faster way to arrive at the human. A portal can surface self-service. It cannot create it. You have to build the thing behind the button.

So what is a control plane, actually?

The missing piece is not another tool or another front end. It is the layer underneath them: one place where a request, from a person, a portal, a pipeline or an agent, is understood, checked against the rules and actually carried out, with no human waiting on the other side for the ordinary case. Context, execution and governance scattered across a catalogue here, a pipeline there and a policy engine somewhere else will not do it, because you are back to needing to know which door to knock on. The shape that pulls them together is a control plane, and since the term gets used loosely, it is worth being precise about what it means.

The idea comes from networking. A network has a data plane, which does the work of moving packets, and a control plane, which decides where those packets should go. The data plane is fast and does what it is told. The control plane holds the intent and keeps the data plane honest.

A platform control plane applies the same split to your infrastructure and services. Your databases, clusters, queues and pipelines are the data plane, the things that actually run. The control plane is the layer above them that:

Takes intent through an API. You describe the outcome, “a production-grade database for this service”, not the steps to build it. The same API serves the portal, the CLI and the agent.
Knows what exists. It holds the desired state of everything it manages, who asked for it and who owns it. That is your context, kept current because it is the thing doing the work rather than a document describing it.
Makes it so, and keeps it so. It does not run once and forget. It continuously compares what should exist with what does and reconciles the difference, so drift gets corrected rather than discovered in an incident. That is your execution.
Checks policy at the door. Every request is validated against your rules before anything is built, and refused with a clear reason when it breaks them. That is your governance.

It also helps to say what a control plane is not. It is not a developer portal; the portal is the window, and the control plane is what sits behind the button. It is not a CI pipeline; a pipeline runs a set of steps and then forgets what it built. It is not a service catalogue; a catalogue describes the world but cannot change it. A control plane is the one place where describing, deciding and doing happen together.

That is exactly why it suits agents so well. An agent does not need to learn fifteen bespoke processes. It needs one declarative interface where it can ask what exists, ask for what it wants, be told no with a reason, and try again. The same is true for the human sitting next to it.

Where this leaves you

If you want a quick read on whether your organisation is ready for agents, skip the vendor demo and ask your platform three questions:

Could someone with no history here find out who owns a service, and what it depends on, without asking a person?
Could they get a database, an environment or a deploy without raising a ticket or sending a message?
Would they know a change breaks the rules before they made it, rather than in a review?

Every “no” is a place your agents will stop, or guess. Every “yes” is something you built, not something you bought.

None of this is out of reach. The control-plane pattern is not a moonshot, and the open, Kubernetes-native tooling to build one is mature and widely used. In the next post I want to stop talking about the shape and actually build one end to end, so you can see what intent, reconciliation and policy look like when they are running rather than drawn on a whiteboard.