Note: This video was generated using AI, adapting the original content and technical insights created by the author of the blog post.

Most organizations already understand the foundations. APIs connect agents to enterprise data and capabilities, while MCP provides a standard way for them to discover and use those tools. The technology works, and companies are moving agents closer to real operations. Some let them read order data. A few allow them to update records or trigger refunds. Others are still deciding where that line should sit.

That is where the harder questions begin. How much authority should an agent receive? Which actions still require human approval? And what happens when nobody is watching it work? In our latest podcast, API strategy expert Dr. Matthias Biehl explains how enterprises can put AI agents into production without losing control over them.

From Naked LLMs to AI Agents

A chatbot can answer a question but an agent can do something about it. In 2023, many companies started experimenting with large language models through prompts and chat interfaces. These systems could write, summarize, and answer questions, but they had little connection to the business itself. Matthias calls this the “naked LLM”: “There was nothing around those LLMs. They didn’t do anything except produce text, they were kind of passive, and they were not very specific to your enterprise.”

Retrieval-Augmented Generation or RAG, was the next step. It gave models access to internal documents and company knowledge. That made answers more relevant, but the systems were still mostly passive.

An agent changes that. Through MCP, it can connect to live enterprise systems, retrieve current data, call business functions, and take action. “It can write something to a database or it can maybe do a refund.” That marks a bigger shift than simply using a better model. Enterprise AI is moving from generating information to taking part in real workflows.

For Mathias, that requires three things: intelligence from AI models, access to enterprise systems through MCP, and collaboration between agents through agent-to-agent protocols. The value of an agent, then, comes not only from what it knows. It comes from what it can access, what it is allowed to do, and who it can work with.

AI agents don´t know your business

Developing an AI agent can feel like bringing in a brilliant new employee. It learns quickly, handles complex tasks, and arrives with broad experience. But it still needs onboarding and supervision. Enterprise agents need more than general knowledge. They need contextual knowledge about the department, goals, and practices. The next step is having access to the data and tools that drive daily work. Matthias Biehl describes this future as the “agentic enterprise”: “In every department, for every role in an organization, you will have AI agents sitting right next to the people who are already filling this role.”

But agents only become useful when they understand the business around them. Without enterprise context, they remain generic. “They’ve read all the Wikipedia articles, basically, but they don’t know anything about the specific enterprise,” Biehl says. Between general knowledge and direct system access, agents therefore need a context layer. Biehl describes context APIs as simplified interfaces that filter and structure business data for a specific task.

MCP builds on that layer by giving agents a standard way to discover and use approved data and business functions. Instead of creating a separate integration for every agent, companies can expose selected enterprise capabilities through a common protocol without opening direct access to the systems behind them.

Companies Don’t Trust Agents in Production 

“We have cool prototypes being built all over,” Matthias says, “but there’s this big gap between prototypes and production.” This gap is not necessarily caused by a lack of technical capability. Many companies have already shown that their agents can retrieve data, call tools, and complete tasks. The harder question is whether they are prepared to give those agents access to real systems and responsibility for real business processes.

The reason is simple: “People don’t trust these agents. That fear is not theoretical. Air Canada’s chatbot is a commonly known example who gave a customer false information about a bereavement fare, and the airline was later held responsible. The bot never executed a transaction, it only answered a question and still created a financial and legal consequence. Once agents can act directly, the risk becomes much greater.

Security therefore cannot come later. Matthias warns that teams often “cut corners on security” while rushing to build prototypes, especially under top management pressure. That may be acceptable in a controlled test environment, but it becomes dangerous once an agent can access customer data, update records, or trigger business transactions.

In production, MCP endpoints need strict access controls, clear permissions, and limits on what each agent is allowed to do. An agent should only receive access to the data and functions required for its specific task. A customer-service agent, for example, may be allowed to view an order and request a refund, but not change payment details or access unrelated customer records.

Good “common practices” such as OAuth 2.1 can help authenticate agents, issue limited access tokens, and define which systems and actions are permitted. Organizations also need logging, rate limits, approval steps for sensitive actions, and the ability to revoke access quickly when something goes wrong.

The goal is not to trust the agent without limits. It is to create a governed environment in which the agent can only operate inside clearly defined boundaries, while every important action remains visible, traceable, and controllable.

Learn more: Explore these talks at API conference Berlin for more on secure AI agent integration.

• What AI Agents Are Teaching Us About Integration — Erik Wilde, Jentic
• Beyond OpenAPI: Workflows That AI Agents Can Actually Execute – Frank Kilcommins, Jentic

MCP Builds on the APIs You Already Have

MCP gives AI agents a new way to use without replacing an organization’s API landscape. Most companies already expose data and business functions through REST APIs. An MCP layer sits on top of selected APIs, describes their capabilities in a format agents can understand, and turns an agent’s request into the corresponding API call.

As Matthias Biehl explains, companies can “go a small step on top of [their] existing API landscape.” The underlying systems stay in place. The task is to decide which capabilities should be made available to agents.

• Low-level system APIs are rarely the best candidates. They expose technical operations from databases, SAP, or CRM systems and require detailed knowledge of the backend.
• Business and process APIs are a better fit because they represent complete actions, such as creating an order, checking eligibility, or processing a refund. “AI agents are thinking kind of abstractly, top-down,” Biehl says. In other words, an agent starts with the outcome it wants to achieve, not with the technical steps required inside the backend. 
• Context APIs can narrow access further by exposing only the fields and functions an agent needs. 

Once the right APIs are selected, an MCP server can publish them as tools and route requests back to the existing services. “It doesn’t require a lot of additional engineering,” Biehl says. MCP is therefore not a new integration landscape. It is an agent-facing layer built on the APIs companies already operate.

Enforced Governance Outside the Agent 

A strong API landscape gives agents structured access to enterprise systems. But as companies connect more agents to more data sources and business functions, the number of possible interactions grows quickly. Access that is manageable in one prototype becomes harder to control across dozens of agents.

That raises the next question: where should those limits be enforced? For Matthias Biehl, the answer is clear. An agent should not be responsible for policing itself. Rules embedded in prompts or individual systems may work in one context and fail in another. Control therefore needs to sit outside the agent, in shared architectural checkpoints that can apply the same policies across the entire environment.

“We need to operationalize these constraints”. The best place to do that is where agents connect to models, enterprise systems, and other agents. Mathias sees three key control points.

• An LLM gateway controls how agents and applications access foundation models. It can authenticate requests, route them to approved models, apply usage and data policies, and monitor interactions, whether the model is externally hosted or runs within the organization’s own infrastructure. 
• An MCP server exposes tools and data to an agent. An MCP gateway adds a control layer around that access. Sitting between agents and enterprise systems, it can verify identity, enforce permissions, set rate limits, and restrict which business functions an agent may use. “At this place of access, that’s where we can enforce those rules and constraints,” Biehl explains. 
• An A2A gateway controls interactions between agents. It can verify which agent is making a request, decide which other agents it may contact, restrict what information they can exchange, and define which tasks may be delegated. This prevents one agent from freely passing sensitive data or operational authority to another without oversight. 

This creates a governance layer that does not depend on every agent following the rules on its own. The controls sit at the points where access happens. Who owns this layer is still an open question. Some companies may give it to an AI competence center. Others may extend existing API governance teams or combine both roles.

AI agents are gaining more access and autonomy, therefore governance must become shared infrastructure.

Agent-to-Agent Collaboration Must Be Enabled by Design

One agent cannot do everything. A customer service agent may understand support cases. A finance agent may know payments and refunds. Another may handle software operations. Complex business processes will often need several of them. “An AI agent is like a specialist,” Matthias explains. The next step is therefore not just giving agents access to enterprise systems. It is giving them a way to find one another, exchange information, and hand off work without losing control over who can do what.

“There will be the need for AI agents to find other AI agents they can collaborate with and hand off a part of their work,” Agent-to-agent protocols, or A2A, can provide a common way for those interactions to happen. But communication alone is not enough. Agents also need to know which other agents exist and what each one can do.

That may require directories where agents register their skills and search for the right specialist when a task falls outside their own scope. The agentic enterprise will therefore look like a network of specialists instead of just one powerful AI. The challenge is to let them find each other and work together.

Learn more: Explore these talks at API conference Berlin for more on agent-ready API architecture

• AI-Ready APIs — Matthias Dangl, ATVANTAGE GmbH
• Transforming into an Agentic Enterprise – Matthias Biehl, API-University.com

Where This Gets Practical

Bringing AI agents into production is not only an AI problem. It requires API teams to define safe access to enterprise systems, governance teams to establish enforceable boundaries, and engineers to build agents that can operate reliably within them. It also changes how developers and architects design software when AI becomes part of the system rather than an external tool.

Making an enterprise agent-ready requires specialists from different domains to work through the same questions together. Access, governance, security, and control can no longer be solved in separate rooms. The people who once met at different events now sit at one table.

That is why we created AI Native Week, bringing API Conference, MLCon, and VibeKode together for the first time. Same week, same place, one shared program.

Dr. Matthias Biehl will be there alongside experts from across these fields, returning to the question at the heart of this article: what does it take to let an agent operate in production without losing control over what it can access and do?

We look forward to comparing approaches, challenging assumptions, and working out together what production-ready enterprise agents actually require.