Research from MIT, Forrester and Gartner converges on a number that should give pause to every executive who has approved an AI initiative: 95% of AI projects never reach production. They stay in prototype land — useful enough for internal demos, not trusted enough to face a customer.

Matthias Biehl, API and AI Strategist at IBM, works with organisations globally on closing that gap. His diagnosis is clear, and it isn't what most people want to hear. The problem is not the model. It's governance — and the industry has almost entirely skipped it.

The Model Upgrade Fallacy

When Biehl raises governance with organisations, a common response surfaces: we'll wait for the next version of the model and it will fix everything. He's direct about why this misses the point. Better models reduce hallucination and improve answer quality. They don't prevent an agent from going rogue, overwriting data it shouldn't touch, or taking actions outside its mandate. For that, you need something the prototype phase never required: constraints.

This is why governance is overlooked. In prototype mode, it doesn't matter if an agent roams freely — the stakes are low, the audience is internal, and no one is depending on the output. The moment you move toward customer-facing production in a regulated industry, the calculus changes completely. Banks, healthcare providers, telcos: all of them need an agent that can be trusted not just to answer correctly, but to stay within defined boundaries at all times.

Three Components, Three Control Points

Biehl's framework starts with a structural definition of what an AI agent actually is. Every agent has three characteristics: it is intelligent (powered by an LLM or AI model), it has skills and the ability to act (it integrates into enterprise systems and can change its environment), and it can collaborate with other agents (via agent-to-agent protocols). Understanding this structure is what makes governance tractable.

Each component has a corresponding control point:

• LLM gateway (intelligence layer): Sits between the agent and the models it calls — controlling which models are accessible, enforcing token budgets, and preventing runaway loops that consume cost without producing value.
• MCP gateway (skills layer): Applies standard API management policies — rate limiting, authentication, authorisation — to everything the agent tries to reach in the enterprise IT landscape.
• A2A gateway (collaboration layer): Governs which agents are permitted to work together and on what tasks.

The logic is the same as defence in depth in cybersecurity: no single control point is sufficient, because a sufficiently capable agent will find ways around isolated constraints. Biehl puts it plainly — agents are inventive. Given access to an LLM, they may try to work around guardrails in their agentic loop. The governance architecture has to be designed with that in mind.

Knowing When Not to Use an Agent

One of the more practically useful distinctions Biehl draws is between tasks that should use agents and tasks that shouldn't. If a process has a clearly defined rule set, finite known outcomes, and a path that has been thought through for each case — implement it deterministically. The existing automation works. There is no reason to replace it with an agent.

Agents are for the other category: problems where you cannot fully anticipate at design time what the user will bring. Customer service interactions are the clearest example — every complaint has a slightly different angle, every user comes with context that no playbook fully covers. In these cases, the agent's ability to think on its feet, handle the edge case that has never appeared before, and learn from novel situations is exactly the capability needed.

Rethinking the API Landscape for the Agent Era

The final piece of Biehl's framework concerns the data access problem: how do AI agents reach the enterprise information they need without requiring organisations to rebuild their entire API landscape from scratch?

His answer draws on a classification that dates back to Netflix engineering in 2011 — system APIs, process APIs, and experience APIs. The first two categories remain largely unchanged for the agent era. But the experience API — the top-level interface that creates tailored variants for different consumers — needs a new name and a new design intent. Biehl calls it a context API: an interface designed not for a human-facing application, but to supply the business and enterprise data context that an AI agent needs to operate.

This reframe matters because it shifts the design question. Instead of asking what a mobile app or web interface needs, teams are now asking what context the agent needs to do its job well. And the answer will be different for every organisation — different systems, different data, different agents, different mandates. No vendor can resolve this at scale. It has to happen inside each enterprise, built on the API and integration investments already in place.

Matthias Biehl is an API and AI Strategist at IBM. Connect with him on LinkedIn.