The Orchestration Layer Wars

In the early years of commercial software, the operating system was the platform that every other software product was built on. Whoever controlled the OS had structural leverage over the entire software stack: they set the APIs that applications had to conform to, they owned the distribution channel (the shelf, and later the store), and they could integrate competing functionality into the base product, making third-party products redundant. Microsoft’s dominance in the 1990s was fundamentally operating system dominance.

In the cloud era, the platform shifted to compute infrastructure. AWS, then Azure, then GCP became the layer that applications ran on, and whoever controlled that layer had leverage over the entire application ecosystem: they set the service interfaces, they owned the billing relationship, and they could offer competitive managed services that undercut the third-party market for database management, networking, security, and analytics.

In the agentic AI era, the equivalent battle is being fought over the orchestration layer — the software infrastructure that sits between LLM model APIs and enterprise applications, managing how agents are created, how they communicate, how they access tools and data, how they maintain state, and how their actions are logged, monitored, and controlled. This layer does not exist yet in mature form. Several companies are building their version of it with the explicit goal of becoming the platform on which enterprise agentic AI runs.

The competitors in this space fall into four categories, each with different structural advantages and different visions of what the orchestration layer should look like.

The hyperscale cloud providers — Microsoft, Google, Amazon — are building orchestration as a natural extension of their existing enterprise relationships. Microsoft’s Azure AI Foundry and Google’s Vertex AI Agent Builder are not primarily AI companies making novel technical bets. They are distribution companies using existing enterprise relationships, existing compliance certifications, and existing billing relationships to attach an orchestration layer to the cloud spend that enterprises are already making. Their advantage is integration: if you are already running your data in Azure, using Azure’s agent orchestration minimizes the integration work. Their risk is commoditization — if the orchestration layer becomes a thin abstraction with minimal lock-in, the model providers and the application layer vendors capture most of the value.

The model providers — Anthropic, OpenAI, Google DeepMind on the model side — are building orchestration capabilities that give enterprises reasons to concentrate on a single model provider’s API rather than treating models as interchangeable commodities. Anthropic’s Model Context Protocol and OpenAI’s tool use and assistant frameworks are attempts to make the specific integration patterns between agents and enterprise systems vendor-specific rather than standard. The goal is to create enough switching cost in the orchestration layer that enterprises that have built agent workflows on their platform stay on their platform even as model prices fall toward commodity.

This strategy is precarious for an interesting reason. The model providers’ core business is inference revenue — charging per token for model calls. If they build an orchestration layer that makes their platform stickier, they win more inference revenue. But an orchestration layer that works well might also make it easier for enterprises to route different tasks to different models (including cheaper or open-source alternatives) — which would undercut inference revenue. The tension between “platform that creates switching cost” and “platform that enables best-model-per-task flexibility” is not yet resolved in any model provider’s strategy.

The open-source ecosystem — LangChain, LlamaIndex, AutoGen, CrewAI, and a dozen others that have emerged since 2023 — represents a different theory of how the orchestration market should work. Their bet is that enterprises will prefer open, composable, vendor-neutral orchestration frameworks that give them control over the full stack rather than vendor-locked platforms. This is the same bet that Linux and MySQL made against Windows Server and Oracle, and that bet paid off for a specific category of workload (web infrastructure) even when it failed to displace incumbent vendors in others (enterprise databases, ERP systems).

The open-source frameworks have adoption: LangChain alone claims millions of developers and deployments in the tens of thousands. What they are still developing is enterprise-grade operational maturity — the monitoring, governance, support, and compliance tooling that large organizations require before trusting a framework with production workloads. The commercial companies that have been built on top of these open-source foundations (LangChain launched LangSmith, a commercial observability layer; LlamaIndex launched LlamaCloud) are essentially selling “open source plus enterprise operational maturity,” which is a proven model in software infrastructure.

Enterprise software vendors — Salesforce, ServiceNow, SAP, Workday — represent the fourth category. Their theory is that the orchestration layer should not be a general-purpose infrastructure play but an application-native capability. If you are running Salesforce for customer relationship management, the agents that automate your CRM workflows should run natively inside Salesforce, using Salesforce’s data model, Salesforce’s permissions, Salesforce’s audit logs. This is the application-native strategy: the orchestration is embedded in the application rather than being a layer below it.

The application-native strategy has genuine advantages for specific, well-defined use cases: the integration is cleaner, the governance model is simpler, and the vendor can invest in making agents that are deeply knowledgeable about their specific application’s data model and workflow patterns. Its limitation is that no enterprise’s agentic workflows will fit entirely within a single application vendor’s ecosystem. The agent that needs to access both Salesforce data and SAP financial data to complete a customer contract task cannot run natively in either system without a cross-application orchestration layer.

The structural parallel to previous platform battles predicts that the orchestration layer will ultimately be controlled by a small number of players, that the battle will be decided partly by technical merit and primarily by distribution leverage and enterprise relationship depth, and that the winning platforms will monetize through a combination of platform fees, value-added services, and the data advantages that come from operating at the center of enterprise AI workflows.

What makes the current battle different from previous platform wars is the rate of change. The OS battles played out over a decade. The cloud battles played out over fifteen years. The orchestration layer wars are playing out against a backdrop of model capability that is changing annually, open-source alternatives that are catching up to commercial capabilities faster than in previous technology cycles, and enterprise buyers that have been burned enough by previous platform lock-in to approach the category with more skepticism than they brought to cloud adoption.

The enterprises navigating this battle face a specific strategic question: how much to invest in platform integration (which produces operational efficiency) versus how much to maintain platform flexibility (which reduces lock-in risk). The answer depends on how confident you are that your preferred platform will still be the right choice in three years — and in the current environment, that confidence is hard to justify.

The practical advice from enterprises that have navigated previous platform transitions well is to abstract where abstracting is cheap and commit where committing produces enough efficiency to justify the lock-in cost. Write your agent logic to a clean interface that could, in principle, be ported to a different underlying framework. Build your data connectors in ways that do not assume a specific model provider’s API. Commit to the integrations where the switching cost is unavoidable — your CRM is your CRM, your ERP is your ERP — but resist the temptation to let the choice of agent framework be driven by convenience rather than capability and longevity assessment.

The orchestration layer is not a neutral infrastructure choice. It is a bet on who wins the platform wars. Making that bet consciously, rather than by default, is the difference between building on a foundation and being built into one.

The open-source frameworks present a specific strategic complexity that deserves direct treatment. Adopting an open-source orchestration framework like LangChain or AutoGen appears to give the enterprise platform independence — no vendor lock-in, no per-seat licensing, full control of the codebase. In practice, dependence on open-source infrastructure with active commercial entities behind it creates different but real dependencies. When LangChain changes its API in a major release (and it has done so multiple times, with deprecations that required significant migration work), enterprises that have built deeply on it face migration costs similar to those of a vendor platform change, without the contractual protections that a commercial relationship would provide.

The more sophisticated posture toward open-source orchestration is to use it as an implementation detail that is fully encapsulated behind an enterprise-owned abstraction layer — meaning the enterprise’s agent logic talks to the enterprise’s interface, which internally uses the open-source framework. This adds engineering overhead. It dramatically reduces exposure to open-source framework API churn. For large enterprises building significant orchestration infrastructure, the trade-off is usually correct.

A category of orchestration competitor that does not fit the four-category framework but is worth naming: the vertical specialists. Companies that have built orchestration capabilities specifically for legal workflows, or healthcare documentation, or financial trading automation — deep integration with the specific data models, compliance requirements, and operational patterns of a single industry. These vertical specialists cannot win the general orchestration market. They can win their vertical, and the winner of a vertical often captures disproportionate economics because enterprise switching costs in specialized, compliance-heavy industries are high.

The hyperscalers and open-source platforms are building for the horizontal market. The vertical specialists are building for depth. Both strategies are viable; they are targeting different purchase decisions. The enterprise choosing an orchestration platform should assess whether its use case is primarily general or primarily vertical — and if primarily vertical, ask whether a vertical specialist has already done the domain-specific work that the horizontal platform will require the enterprise itself to build.

The orchestration wars will not produce a single winner. The outcome, as in most enterprise infrastructure markets, will be a dominant horizontal platform (probably Microsoft or Google, given their enterprise relationship depth), a strong open-source alternative (probably whichever framework develops the best enterprise-grade operational tooling), and a set of vertical specialists that own their respective niches. Knowing which type of player you need to bet on requires understanding your own use case first.