The control point has moved
For the past three years, enterprise AI conversations in the DACH mid-market have centred on model selection, cloud hosting, and chatbot interfaces. Geschäftsführung asked whether to use OpenAI, Anthropic, or a European alternative; whether to deploy on-premise or in the cloud; whether to trust a public model or fine-tune a private one. Those questions mattered, and they still do. But the real control point—the layer that will determine whether your organisation can change direction, switch vendors, or even understand what your AI systems are doing—has quietly shifted one level up the stack.
The orchestration layer is where the decisions happen. It is the tier that translates a user's request into a sequence of model calls, database queries, approval workflows, and system-of-record updates. It is the code that decides which ERP table gets touched, which customer record is surfaced, which compliance check runs before a contract amendment is approved, and which exceptions escalate to a human. It is the harness that wraps around your models, your data, and your business logic. And it is rapidly becoming the most economically powerful position in the enterprise AI stack.
As orchestration platforms evolve, vendors are increasingly positioning agentic development tools as complete infrastructure that can be purchased, deployed, and governed inside existing enterprise security frameworks. Once orchestration infrastructure moves from the developer's expense account into the IT budget, it compounds—usage expands, the data flywheel builds, and switching costs harden. This is not middleware in the boring 1990s sense. It is the layer that decides what your organisation can do.
Why orchestration is different from automation
Traditional enterprise automation—workflow engines, robotic process automation, integration platforms—was slow to build and expensive to change. That friction was a feature, not a bug. It forced design reviews, security sign-offs, and governance checkpoints. The assumption was that only experienced developers with specialised knowledge would build production workflows, and that those workflows would be reviewed at the same pace they were created.
That assumption no longer holds. AI-assisted development has collapsed the time required to generate a PowerShell script, a Graph API integration, or a Power Automate workflow from weeks to minutes. A user who does not understand the security model behind what they are deploying can now create powerful automation that touches core systems. Security teams are no longer reviewing automation at the same pace it is being created. The speed has changed, but the governance model has not.
The orchestration layer is where this tension surfaces. It is the place where a natural-language request ("update all customer records in region DACH where contract renewal is overdue") gets translated into a sequence of API calls, database writes, and approval triggers. If that orchestration logic lives inside a vendor's platform—whether that vendor is your ERP provider, your IT services partner, or an agent gateway supplier—then the vendor owns the decisioning layer. You own the data, but they own the logic that decides what happens to it.
This is not a theoretical risk. Consider a scenario where a DACH automotive supplier might discover that its procurement agent, built on a third-party orchestration platform, has been approving purchase orders below a certain threshold without human review. The logic might be correct—matching the company's stated policy—but no one in procurement or IT can explain where the threshold is set, how it is calculated, or how to change it without opening a support ticket. The orchestration layer becomes a black box.
The three places orchestration hides
Orchestration logic does not announce itself. It hides in three places, and most DACH mid-market organisations have all three running in parallel without a unified view.
First, inside ERP and SaaS platforms. Your ERP vendor has been adding "AI-powered workflow automation" to its product roadmap for two years. Those workflows touch your chart of accounts, your approval hierarchies, and your compliance audit trails. The orchestration logic is embedded in the platform's update cycle. You do not control the versioning, the rollback path, or the logging. You get what the vendor ships.
Second, inside IT services contracts. Your managed-services provider or system integrator has built custom agents to handle tier-one support tickets, provision user accounts, or route compliance exceptions. The orchestration code lives in their repository, not yours. The knowledge of how it works lives in their team, not yours. When the contract ends or the relationship sours, you lose the ability to change the logic without starting from scratch.
Third, inside agent platforms and gateways. The newest category of vendor is the agent gateway—the control plane that sits between your agents and everything they touch. These platforms handle tool execution, authorization, policy enforcement, and observability. They are infrastructure, and infrastructure is sticky. Once your agents depend on a gateway's API, permission model, or logging format, moving to a different gateway means rewriting every agent that touches it.
Each of these layers makes sense in isolation. ERP vendors add intelligence to their platforms because customers demand it. IT services providers build custom automation because that is what they are paid to do. Agent gateways exist because someone has to solve authorization, observability, and policy enforcement at scale. The problem is not that any single vendor is acting in bad faith. The problem is that orchestration logic, by its nature, becomes a dependency—and dependencies become control points.
What DACH leaders should map now
The first step is not to ban orchestration platforms or insist on building everything in-house. The first step is to map where orchestration decisions are being made today, who controls the logic, and what it would cost to move that logic somewhere else.
Map the decisioning layer. For every AI-powered workflow or agent in production or pilot, ask: where does the logic live that decides which system of record is touched, which approval path runs, and which exception reaches a human? If the answer is "inside the vendor's platform," ask what it would take to export that logic, host it yourself, or replace it with a different vendor's implementation.
Map the approval and exception paths. Orchestration is not just about happy-path automation. It is about what happens when something goes wrong, when a rule does not match, or when a human needs to intervene. If your orchestration layer does not log every decision point, every exception, and every escalation in a format you control, you do not have observability. You have a black box with a dashboard.
Map the data flows and system-of-record writes. Every orchestration decision ultimately writes to a database, updates a record, or triggers a downstream process. If you cannot trace which agent or workflow touched which table, you cannot audit, you cannot debug, and you cannot comply with regulatory expectations. DACH regulators are increasingly focused on AI system traceability—not just for model outputs, but for the automated decisions that follow.
Map the switching costs. If you decided tomorrow to replace your orchestration platform, your IT services provider, or your ERP vendor's AI module, what would break? How many workflows would need to be rewritten? How much institutional knowledge would be lost? Switching costs are not inherently bad—every platform has them—but they should be visible, quantified, and factored into the decision to adopt.
The emerging pattern: orchestration as a service
The market is moving toward orchestration-as-a-service, and the vendors that win this layer will capture more economic value than the model providers. Agent gateways are becoming the control plane for enterprise AI—not because they are technically superior to alternatives, but because they solve the coordination problem that every organisation faces when agents start to proliferate. One gateway can enforce policy, log decisions, and manage tool access across dozens of agents. The alternative is dozens of bespoke implementations, each with its own security model and observability gap.
This is why vendors are racing to own the routing layer. The orchestration tier abstracts the model zoo away from the end user and translates business intent into model calls. It is the most economically powerful position in the stack because it sits between the models (which are commoditising) and the business logic (which is proprietary). The company that controls orchestration controls the switching costs, the data flows, and the upgrade path.
For DACH Mittelstand firms, the implication is clear: orchestration is not a feature you buy as part of a larger platform. It is a capability you either own or rent, and if you rent it, you should know the terms.
What to negotiate before the lock-in hardens
If you are evaluating an orchestration platform, an agent gateway, or an AI-powered ERP module, negotiate these terms before the contract is signed and the integration is built.
Data portability for orchestration logic. Insist that workflow definitions, decision rules, and approval paths are stored in a format you can export, version, and redeploy elsewhere. If the vendor's orchestration logic is proprietary and non-portable, the switching cost is infinite.
Observability and auditability. Every orchestration decision—every model call, every database write, every exception—should be logged in a format you control. If the vendor's logging is internal to their platform and cannot be exported to your SIEM or audit trail, you do not have compliance. You have a compliance theatre.
Separation of orchestration and execution. The best architectures separate the orchestration layer (which decides what to do) from the execution layer (which does it). If your orchestration logic is tightly coupled to a specific model provider, cloud platform, or agent runtime, you cannot change any of those components without rewriting the orchestration. Insist on abstraction layers and standard interfaces.
Governance and policy enforcement. If your orchestration platform does not support policy-as-code—rules that can be versioned, tested, and enforced automatically—then governance becomes a manual process that does not scale. Orchestration without governance is automation without control.
The wedge question
The wedge question for Geschäftsführung is not "which orchestration platform should we choose?" The wedge question is "do we understand where orchestration decisions are being made today, and do we have the ability to change them?"
If the answer is no, the next lock-in has already started.
A Fit Call maps your current orchestration footprint—where decisioning logic lives, who controls it, and what it would cost to move—before that logic becomes the control plane for core operations.