The model layer is yesterday's battleground. DACH mid-market leaders spent the past eighteen months navigating the OpenAI-versus-Anthropic-versus-open-weights decision, only to discover that the real strategic choice was never about which foundation model to run. It was about which system would own the routing logic, the permission fabric, the memory store, and the workflow context when agents begin to act autonomously across your enterprise stack. That system is the orchestration layer, and the platform war to control it is already underway.
Salesforce is pursuing one of the market's most aggressive strategic pivots, attempting to evolve beyond CRM into a generalised orchestration platform for autonomous enterprise execution. Agentforce, MuleSoft, and Data Cloud collectively represent an effort to transform Salesforce from a customer engagement platform into an API-first operational system capable of coordinating machine-driven enterprise workflows across heterogeneous environments. Microsoft is assembling a similar stack through Agent 365, Azure AI Foundry, Microsoft Graph, Fabric, Entra ID, Purview, and Copilot Studio. ServiceNow is building agent capabilities designed to bring regulated agentic AI to enterprise workflows, establishing a unified semantic, trust, and orchestration fabric that bypasses the data lineage and siloed infrastructure problems that plague legacy automation. SAP, Oracle, and a dozen vertical SaaS vendors are building their own agent layers, each designed to make their suite the natural home for agentic execution.
The contrarian insight is that the suite-first argument hinges on integration convenience, not orchestration capability. The vendor that already manages your customer records, your procurement workflows, or your service tickets will argue that embedding agents inside that system is the path of least resistance. For many DACH Mittelstand firms, that argument will feel compelling in the moment. The exposure, however, is already accumulating, and it sits between functions that are not structured to catch it. A vendor-managed system roadmap controlled by a vendor for whom workforce orchestration is a secondary product will not keep pace with the operational demands of agentic execution. The workarounds internal teams build to compensate—the spreadsheets, scripts, and side processes—are what partners and internal IT inherit when something escalates. Making the orchestration argument before the decision is locked in is easier than integrating around a tool that was never built for the job.
Why the orchestration layer is the new control point
The orchestration layer is where agents receive instructions, resolve conflicts between competing goals, check permissions, log actions, and maintain context across sessions. It is not the model that decides whether an agent should approve a purchase order, reschedule a production batch, or escalate a fraud flag—it is the orchestration system that enforces the guardrails, routes the request to the appropriate decision engine, and ensures that the action is logged in a way that satisfies audit requirements. In the agentic era, secure access is not just who can log in; it is what can run, what can call an API, what can invoke actions, and what can persist unattended. Centralising provisioning and revocation of AI connectors and tokens is not a theoretical challenge. Many organisations lack a centralised way to revoke access, making the challenge operational, not architectural.
The platform vendors understand this. They are not building agent capabilities as add-ons; they are re-architecting their core products to position themselves as the natural orchestration hub. The economic logic is clear: the vendor that owns the orchestration layer owns the workflow context, the permission model, and the data lineage that agents rely on to act. That vendor becomes the platform through which all other AI capabilities must integrate. For traditional enterprise software—ERP, CRM, productivity platforms, enterprise databases—the existing stack will remain in place for many years. The economic logic that separated software and services still applies to these environments. However, agentic-native systems are different. They collapse the boundary between configuration and execution, between software and service, in ways that traditional enterprise software never did.
The hidden cost of suite-native orchestration
The suite-native orchestration model promises integration convenience, but it delivers three forms of lock-in that are harder to reverse than model lock-in ever was. Workflow lock-in occurs when the orchestration logic becomes embedded in the vendor's proprietary workflow engine, making it difficult to replicate the same decision logic in a different system. Memory lock-in occurs when agent context, interaction history, and learned preferences are stored in the vendor's memory layer, creating a data gravity problem that makes migration prohibitively expensive. Permission lock-in occurs when the orchestration system becomes the authoritative source for who can do what, and migrating that permission fabric to a new system requires re-mapping every role, every policy, and every exception.
For DACH mid-market firms, the cost of reversing these decisions is not just technical—it is operational. The insurance claims team that built its fraud detection workflow inside a vendor's agent platform cannot easily lift that workflow into a different system without rebuilding the rule logic, re-training the team, and re-establishing the integration points with existing claims management, payment processing, and regulatory reporting systems. The manufacturing firm that deployed a production scheduling agent inside its ERP vendor's orchestration layer cannot switch to a different orchestration system without re-implementing the scheduling logic, re-mapping the machine data feeds, and re-validating the quality control handoffs. The financial services firm that embedded credit decisioning agents inside its CRM vendor's orchestration layer cannot migrate to a different platform without re-building the credit policy engine, re-connecting the data lineage to regulatory reporting systems, and re-certifying the entire workflow with compliance.
The practical implication is that the orchestration decision is a multi-year strategic decision with compounding switching costs, not a pilot decision. The vendor that owns the orchestration layer will significantly influence the upgrade cycle, the pricing model, and the integration roadmap for every agentic capability you deploy—though contractual terms, hybrid deployment models, and managed service partnerships can mitigate some of this control. If that vendor's strategic priority shifts—if they decide to exit a market, acquire a competitor, or pivot to a different customer segment—you inherit the consequences.
The case for orchestration independence
The alternative is to treat orchestration as a capability you own, not a feature you rent. Orchestration independence does not mean building your own orchestration engine from scratch; it means selecting an orchestration layer that is decoupled from the application layer, that exposes its routing logic as configurable policy rather than proprietary workflow, and that allows you to swap models, agents, and integrations without re-architecting the entire system. Industry leaders are already layering agents on their current damage assessment ML and GenAI solutions rather than discarding deterministic logic in favour of a 'smarter' AI model. The sweet spot for AI scaling is not replacing existing automation—it is orchestrating it.
Industry observers note that agentic AI presents a "tale of two cities": a significant productivity leap for technical teams, but still nascent for business end-users. Deploying non-deterministic intelligence to non-technical staff carries substantial risks, as agents might generate erroneous data or reports. Human supervision and robust guardrails are not optional; they are the foundation of any orchestration model that will survive regulatory scrutiny, operational stress, and executive accountability. The orchestration layer is where those guardrails are enforced. If the orchestration layer is controlled by a vendor whose primary business is selling CRM seats, service tickets, or ERP modules, the guardrail logic will always be secondary to the vendor's core product roadmap.
The practical path forward for DACH mid-market firms is to establish an orchestration ownership model before the platform vendors make the decision for you. That means defining the routing logic, permission model, and memory architecture as internal capabilities, not vendor features. It means selecting integration partners who can operate within your orchestration framework, not vendors who require you to operate within theirs. It means treating orchestration as a capability that outlasts any single model provider, any single agent vendor, and any single application suite.
The decision window is narrowing
The platform vendors are moving quickly. Salesforce, Microsoft, ServiceNow, SAP, Oracle, and a dozen vertical SaaS vendors are embedding agent capabilities into their core products, and they are positioning those capabilities as the natural orchestration layer for enterprise workflows. The decision window for DACH mid-market leaders is not whether to deploy agents—it is whether to own the orchestration layer before the vendors own it for you. The firms that make that decision early will retain the flexibility to swap models, integrate new capabilities, and migrate workflows without re-architecting their entire AI stack. The firms that defer the decision will inherit the orchestration model that their CRM, ERP, or service management vendor chooses for them.
The orchestration layer is the new control point. The vendor that owns it will own the workflow context, the permission model, and the data lineage that agents rely on to act. The firms that recognise that reality early will make the orchestration decision on their own terms. The firms that do not will make it by default.
A Fit Call helps you map your current automation landscape, identify orchestration dependencies hidden inside existing vendor contracts, and define an ownership model that preserves your flexibility before the platform vendors lock it in.