Key facts (as of 27 September 2026):
- The Model Context Protocol (MCP) has been a mature standard since 2026, with authorisation based on OAuth 2.1 and Enterprise-Managed Authorization; the integration problem for AI agents no longer lies in the protocol but in the system landscape.
- AI agents in mid-sized companies fail at five breaks: applications without central SSO, core systems without an interface, servers behind the firewall in flat networks, write operations without guardrails, and content that contains instructions (prompt injection).
- The blueprint against them has five building blocks: identity as the foundation, tools by business transaction, a central gateway as control point, guardrails in the infrastructure instead of the prompt, and autonomy as a ladder.
- Incomplete digitalisation protects jobs from AI today because an agent only automates what it reaches end to end; that is a grace period companies should use for upskilling and agent-ready systems.
In November 2024 Anthropic published the Model Context Protocol. Almost two years later MCP has grown up: the protocol sits with the Linux Foundation, the specification of 28 July 2026 treats authorisation like an enterprise standard, and the extension for Enterprise-Managed Authorization has been stable since July. Even SAP now has an MCP gateway.
On paper the problem is solved. Every model talks to every tool, through one plug.
In practice it looks different. Ask the agent in a typical mid-sized company “Where is order 0815?” and it may still answer cleanly. Tell it “Move the delivery by a week, inform the customer and adjust production planning” and the chain breaks. Not in one place. In five.
The protocol is ready. Our system landscape is not.
This post is the short version of my full analysis, published on LinkedIn on 26 September 2026 (in German): Das Protokoll ist fertig. Unsere Systeme nicht. The complete diagnosis with all sources is there. Here we focus on the core: the five breaks, the blueprint against them, and an uncomfortable thesis at the end.
An agent is a new employee, and on day one everything is missing
Anyone building a cloud-native application thinks in layers: who may enter, how do you get there, what do you talk about, what may you change, and who makes sure nothing wrong happens? Nobody takes an app into production with one of those layers missing.
With agents we often act as if the protocol were enough. Yet an agent is nothing but a digital employee reaching across every system. Anyone who has ever onboarded a new colleague knows the list: badge, keys, phone numbers of the contacts, signing authority, induction on the shop floor.
In this picture MCP is the shared language. Valuable, but only the language. Teach your new employee German and then give them no badge, and you still have nobody who works.
The five breaks
1. Identity. At protocol level identity is solved: OAuth 2.1 and Enterprise-Managed Authorization make the central identity provider the control centre. IT defines in Entra ID or Keycloak which agent may access which MCP server on behalf of which employee. But that only works for applications attached to the identity provider. In the Mittelstand, time tracking has its own login, the industry software manages users locally, and the supplier portal uses a shared account. At each of these breaks two bad options remain: a service account with broad rights whose audit log says “bot” instead of a name, or an interruption in the middle of the transaction.
2. Interfaces. The large SaaS providers ship official MCP servers. The gap lies with the systems where the actual business happens: production planning, MES, CAQ, PLM, warehouse management, DACH industry solutions grown over decades. Below them sit applications without any interface. Then the tinkering begins with MCP proxies, CLI wrappers or browser automation, and every variant has its price. Even at the ERP market leader it remains one building block: SAP’s API policy in version 4 has, since April 2026, prohibited the use of SAP APIs by partially autonomous AI systems outside the routes SAP explicitly supports. Agent access thus becomes a licensing and platform question, not a protocol question.
3. Network. The agent runs in the cloud, the ERP stands in the basement, and between them sits a firewall that for good reason allows no inbound connections. The controlled path in between is technically no rocket science, organisationally often a project of its own. The bigger problem is segmentation: in historically flat networks an MCP server that reaches the ERP usually also reaches the file server and, in the worst case, production.
4. The write side. Almost every demo reads. The real lever is writing, and that is where it gets serious. A delivery date change is not a database update but a business transaction with consequences for scheduling, purchasing and the customer. MCP supplies hints, not guarantees: a tool can declare itself “read-only”, but that is a server’s self-declaration, not enforcement. A chatbot that says something wrong embarrasses itself. An agent that books something wrong creates a credit note.
5. Guardrails and security. An agent cannot reliably separate data from instructions. To a language model, the supplier mail, the PDF attachment and a tool’s response are simply text, and text can contain commands. Prompt injection tops the OWASP list for LLM applications. Then there is the supply chain: in September 2025 the npm package postmark-mcp was the first malicious MCP server found in the wild, blind-copying every sent e-mail to the attacker. And rights assignment: an MCP server working with its own broad rights instead of the user’s becomes a confused deputy.
On the shop floor different laws apply again. Controllers that are twenty years old, real time instead of “at some point”, zones per IEC 62443. Our stance for OT is sober: an agent may observe the machine long before it may operate it.
The blueprint: five building blocks
For every break there is a proven pattern. None of them is exotic; most are familiar to anyone who has run a cloud-native platform. What is new is thinking them through consistently for agents.
- Identity as the foundation. Every application without SSO goes on a list and is connected via OIDC or SAML. When an agent acts on behalf of a person, that person’s identity travels along and every request is checked against their rights. Tokens are valid only for the system they were issued for.
- Tools by business transaction, not by database table. “Check delivery status” instead of “read table ORDER”. Which fields an agent sees is decided by the business unit. Start small: one server in front of the most important core system, a few strictly read-only tools.
- One control point for all agents. All agent traffic runs through a central gateway: authentication, policies, audit, rate limits and cost in one place. MCP servers live in their own network zone; every call is logged following the OpenTelemetry conventions for GenAI.
- Guardrails in the infrastructure, not in the prompt. Policies are enforced deterministically: which role may use which tool with which parameter limits. The dangerous triple combination is deliberately broken up. MCP servers come only from a vetted catalogue with a pinned version.
- Autonomy as a ladder. Write rights are earned, not granted: read, prepare drafts, write after approval, write independently within clear limits.
None of this is magic. It is platform engineering, thought through to the end for a new type of colleague.
That control point from building blocks three and four is exactly what we build with the AI Gateway: an infrastructure component in your own cloud tenant that takes identity from Entra ID or Keycloak, enforces budgets per cost center, places guardrails in front of model and MCP calls and makes every transaction traceable. And so that agents do not emerge beside the organisation but inside it, this comes with an AI stack of your own rather than individual tools. Ours is called CompanyGPT, operated in your Azure tenant or sovereignly on STACKIT.
When no bridge holds: rebuild, agent-ready from day one
Isn’t all this done in a few days with coding agents? An MCP proxy for an OpenAPI interface is built in an afternoon today. But a prototype answers the question “does it work?”. Production answers other questions: who runs the proxy when the vendor changes its API? Who decided that this agent may trigger this booking? What is in the audit when the auditors ask?
For some systems there is nothing left to attach a bridge to. We are currently building new core systems for several customers whose predecessors run on unmaintained PHP or on Visual Basic 6, whose development environment Microsoft has not supported since April 2008. The big-bang rewrite is precisely the mistake not to make. What works is the step-by-step rebuild, module by module, while the legacy system keeps running. Coding agents read the old code nobody understands any more and surface the hidden business rules. Tests pin today’s behaviour before anything is rewritten.
The decisive difference lies in the target picture: central login via the identity provider, API first instead of UI first, every business function as a cleanly described tool over MCP, write operations with approvals and idempotency. The five layers are then not a retrofit but part of the architecture. Vibe coding builds prototypes. AI-native engineering builds core systems that carry agents.
The uncomfortable thesis: the media break is Germany’s secret job protection
Put all the layers together and you arrive at a conclusion nobody likes to say out loud: our half-finished digitalisation currently protects more jobs from AI than any regulation.
An agent can only automate what it reaches end to end. Wherever a person sits between two systems retyping data or transferring a PDF order into the ERP, that person is the interface. The numbers fit: according to the KfW digitalisation report, only 30 percent of mid-sized companies completed a digitalisation project in the 2022 to 2024 period. At the same time, in an ifo survey from summer 2025 around 27 percent of companies expected AI-related job cuts within the next five years. The intent is there. The wiring is missing.
But that is a grace period, not protection. Competitors do not wait. Demographics work against us; in its AI scenario the IAB expects around 800,000 jobs to disappear and about as many to be created within 15 years, so work shifts. And the gaps close with every specification round. The media break saves jobs today. In five years it will cost them. Honest leadership means using this time: for upskilling, for new roles, and for making sure people steer the agents rather than being replaced by them.
What you should do now
Agent readiness is not an AI project but an infrastructure project. Four steps for the next 90 days:
- Draw the map. Four questions for your ten most important systems: is it attached to SSO? Is there an API or an MCP server? May you write through it? Which network zone is it in?
- Build one transaction end to end. One use case, read-only, through a central control point, with real identity and audit. Not ten pilots, but one cut through all five layers.
- Decide per legacy system: patch or rebuild. And add agent readiness as a requirement to every upcoming migration.
- Bring AI under your own control. Copilot or a SaaS app is not an AI strategy. In the long run companies need their own AI stack, not just tools that contain shadow AI.
The bottleneck is not the model. The bottleneck is no longer the protocol either. The bottleneck is whether your systems can onboard a new colleague at all.
Further reading
The full analysis with all sources, the shop-floor section and the blueprint in detail is on LinkedIn (in German): Das Protokoll ist fertig. Unsere Systeme nicht.
I have also condensed my thinking on AI agents, an AI stack of your own and the path to get there into a book, written with the help of AI: Das agentische Unternehmen: Wie der Mittelstand mit KI-Agenten handlungsfähig wird (in German) – from the foundations of language models via a reference architecture for mid-sized companies, security, law and governance to a twelve-month roadmap from pilot to scale, backed by more than 130 sources. Available on Amazon as paperback, hardcover and for Kindle.
Related posts from our blog:
- AI Harness explained: the seven building blocks that turn a model into an agent
- AI Gateway: cost control, guardrails and identity in your own tenant
- CompanyGPT: the AI stack of your own for business users
Where does the chain break first in your system landscape? We draw the map with you and build the first end-to-end cut. Talk to us.
