AI Agents' Real Problem Is Platform Orchestration, Not the Model

AI agent demos are easy to sell when there is one developer, one repo, and one clean use case. This is how the demo ends up in production. The excitement leads to time pressures, and then that same capability has to work across eight hundred developers and two hundred repos. Over time, each of these repos changes and upgrades on its own schedule, and nobody can say what's actually running where.

When questions about these long-term challenges are raised early, they tend to change the mood in the room. Defensiveness comes out, with arguments that this isn't a problem yet, both because no one wants to be seen as missing such a big risk and because they worry that raising these questions so early in a project will slow down innovation. Unfortunately, these risks do turn into long-term issues if not dealt with early. AI rollouts rarely stall because a model underperforms. They stall when early success creates a fleet of AI systems that becomes harder to govern, operate, and evolve than anyone anticipated.

Platform orchestration closes the gap between demo and fleet management

Model capability keeps improving, and the industry keeps talking as though that's the whole story. But an agent that competently does a task once, for one person, in a controlled demo, tells you almost nothing about what happens when that capability opens up to an entire engineering organisation. At that point the questions stop being about intelligence and start being about operations: who can request this, what's the blast radius if it's wrong, what version is running, how do we roll it back.

Managing a capability that's unique to your organisation but common across your teams is a platform engineering question that predates AI. Platform orchestration is the discipline of defining a capability once, whether that's a database, a Kubernetes cluster, or an AI agent, and managing its full lifecycle centrally. Done well, teams consume the capability through a simple, governed interface and never need to understand the machinery behind it. This is the layer that turns "we have an agent that works in a demo" into "we have an agent we can run safely at scale."

Agent configuration is a resource with a lifecycle, not a special case

Treat an agent's configuration (its skills, permissions, allowed repos) as something to hand-wire per team, and you get what you'd expect: inconsistency, no audit trail, and a slow accumulation of local variants nobody can reason about six months later.

That configuration doesn't sit still, either. The model behind the agent gets upgraded. The system prompt gets rewritten. New MCP servers get connected, and old ones get deprecated. Skills get added, permission scopes creep or shrink, allowed repos change as teams reorganise. Every one of those is a change to something already running in production, not a setting configured once and left alone.

Agent configuration evolves continuously. Treating it like any other platform-managed resource enables safe upgrades, governance, and recovery.

We saw this exact pain with infrastructure provisioning before platform engineering existed as a discipline. AI-enabled software delivery is now recreating it one layer up the stack, faster than anything that came before it.

The fix doesn't need to be novel either: define the resource once, expose it through an API-first interface, and invest in its full lifecycle. Architected that way, a capability becomes versioned, upgradeable, checkable for drift against a known baseline, and reversible when something goes wrong. None of that is agent-specific. It's what a mature platform already does for everything else it manages, applied consistently instead of waived for the new, exciting thing.

Governed self-service beats YOLO and centralisation

There are two easy ways to get this wrong, and both are common.

One is fully open self-service: give every team the raw capability and hope discipline emerges on its own. It rarely does, because nothing is enforcing it. This is the “YOLO” strategy.

The other is routing everything through a central review queue. That enables strong controls but slows delivery to a crawl and turns the platform team into a bottleneck everyone resents. It's also why "shadow AI" has become a real worry inside platform teams over the past year: the same shadow IT problem that shows up whenever a capability exists but the sanctioned path to it is too slow or too rigid, now showing up for agents instead of infrastructure.

Platform teams encode governance into the platform itself, allowing application teams to self-serve while maintaining consistency and control.

Platform engineering starts in earnest when organisations shift from controlling users to enabling them. In that model, a platform team codifies guardrails once, which are built into the API contract and the backing service itself. This means individual teams can consume these without needing platform expertise of their own. Governance sits in the platform rather than in documentation nobody maintains or processes that run outside it. Self-service still means managed: the management is built in, not bolted on after something breaks.

What this looks like when an enterprise actually tries it

We've recently been working through this with a global hospitality enterprise with several thousand application developers, and a mandate to move faster on software delivery tied directly to revenue, not just cost savings. Their instinct wasn't to roll out an agent and see what happened. It was to prove they could govern agent rollout the same way they govern everything else that touches production.

Their proof-of-value goal is deliberately focused: distribute agent configuration consistently across a first batch of repositories, prove central governance can coexist with local autonomy for the teams consuming it, and prove that lifecycle support (upgrading the underlying model, rolling out prompt changes, adding or retiring MCP server connections, catching configuration drift and remediating it) won't degrade effectiveness over time. 

The stakeholder showcase they're building towards, covering agent-skill requests, configuration reconciliation, and team adoption reporting across repos, is designed to drive exactly the internal discussions that matter: at any point, what's actually running, and does it match what should be running? That question hasn't changed for AI. It's the same one platform teams have always had to answer.

It's a proof-of-value in progress, not a finished result. However, the signal is that when industry-leading organisations roll out AI, they are reaching for the platform orchestration discipline by default, without anyone needing to make the case for it.

Final thoughts

None of this needs new technology or a different mental model than the one platform teams already use. It needs that model applied honestly to a new category of resource, instead of treating AI as exempt from the discipline everything else has to follow. 

The enterprises that end up succeeding with AI at scale won't be the ones with the cleverest prompts. They'll be the ones who already knew how to run a platform, and enabled it for one more type of (agentic) user.

If you're working out what that looks like for your own AI rollout, see how platform orchestration applies to AI agents.