Essay
AI platform capabilities start with two journeys, not a stack diagram
Most AI platform pictures are layer cakes of products. I drew ours from two journeys instead: how an agent gets created, and how it gets consumed. Eight capabilities fell out of that, and the gaps that matter most are not the ones the market is selling.
I spent a day this week drawing an AI platform capability model. My first three drafts were layer cakes: infrastructure at the bottom, models in the middle, agents on top, a governance bar down the side. Every vendor deck has this picture. It is not wrong, but it does not tell you what to build next, because it describes products, not the work people are trying to get done.
The version that finally held up started somewhere else. Not with layers, but with two journeys.
Two journeys share one platform
The first journey is creating an agent. A maker builds something, it gets approved, it gets deployed. This happens once per agent, and the maker is the customer.
The second journey is consuming an agent. A person, or an event, finds an approved agent and invokes it. The agent thinks by calling a model and acts by calling tools, on behalf of whoever invoked it. This happens on every single request, and the user is the customer.
Walk both journeys step by step and ask, at each step, what has to exist for this to work safely at scale. The capabilities fall out:
- Governance decides: which AI use cases are approved, at what risk tier, under which policies.
- Security enforces: agent identity, guardrails, secrets, data loss prevention.
- Build and test is where makers work: SDKs, templates, low-code builders, evaluations.
- Model access is how agents think: an LLM gateway with routing, quotas, cost and a model allow-list.
- Tool and data access is how agents act: an MCP gateway, a catalogue of connectors, certified data sources.
- Agent runtime is where agents live: orchestration, memory, triggers, channels.
- Agent catalog and lifecycle is where users find approved agents, and where every agent is versioned, re-certified and eventually retired.
- Operate keeps it honest: tracing, cost, evaluation in production, incident response.
Plus the foundation underneath (cloud, Kubernetes, key vault, network) that already exists in most enterprises.
What counts as a capability
The hardest part was not the list. It was deciding what belongs on it. Every component in the space wants to be a box on the diagram: prompt libraries, vector stores, guardrail models, eval frameworks.
The rule I settled on: a capability is something a team consumes through a clear contract, an API or a self-service flow, with one owning team and an SLA. Anything smaller is a component inside a capability. A prompt library is a component of build and test. A vector store is a component of tool and data access. One product can also serve two capabilities: the same gateway product might front both your models and your MCP servers, and that is fine, as long as the capabilities stay separate in the model.
This rule kills a lot of arguments early. If nobody would own it with an SLA, it is not a capability yet.
Governance belongs at graduation, not at the door
My first instinct was to put governance at the start of the create journey: propose a use case, get approval, then build. That is how most enterprises run AI today, and it is why so many sit in pilot purgatory. The approval queue becomes the bottleneck, and the people who would have learned the most by building give up before they start.
So governance moved. Makers build freely in a sandbox with baseline guardrails: models reached through the gateway, no production data, no production tools. Governance applies at registration, the moment an agent graduates from personal experiment to something other people depend on. That is where it gets a risk tier, an owner and an identity. This is the same idea as governance as platform, not policy: the guardrails are built into the road, so you do not need a gate at the entrance.
Where the real gaps are
When I mapped what actually exists today against the eight capabilities, most of them came out partial. Some identity, some gateways, some observability, some approved tools. That is normal, and the market is busy selling products for exactly those boxes.
The two real gaps were elsewhere: the agent catalog and a standard agent runtime. Agents today run in four or five different places (low-code builders, coding assistants on laptops, vendor agents, a few custom containers), each with its own idea of identity, tracing and shutdown. There is no common kill switch. No common trace. No single place to see what is running.
A runtime standard is less about choosing a product and more about agreeing on a template every agent ships with: state and checkpoints, triggers, identity that can act on behalf of a user, tool wiring through the gateway, a human approval step for risky actions, tracing and cost hooks, versioned rollout and rollback, retries and model fallback. Hosting is the easy part; most enterprises already have it. This is why I think the harness is becoming a platform capability in its own right.
Trace in open formats
One concrete recommendation from the exercise: instrument agents with the OpenTelemetry GenAI conventions from day one, and send traces to the observability tool you already run. Gateway logs are not enough. They show you the calls, not the reasoning chain that connected them, and when an agent misbehaves the chain is what you need. One trace per agent run, tagged with agent, version, user and AI product, and scrubbed of personal data before it leaves the runtime.
What I would tell another platform team
Draw the journeys before the boxes. Use an ownership rule to decide what counts as a capability. Put governance at graduation. Then look hard at the runtime, because that is where the shared platform is still missing, and it is the part no vendor will solve for you by default.
The market is immature here. Gartner only named the agent management category this year, and most registries and gateways I looked at are still in preview. That is a reason to anchor on open standards and clear ownership now, not a reason to wait.