Opening Scene
The application is no longer the unit of work
For most of the enterprise software era, the application was the unit of work. Employees opened the customer relationship management system to manage a customer, the enterprise resource planning system to process an order and the human resources platform to complete an employment task. The interface was not merely where work appeared. It was where the process, data and controls were assumed to live.
That model is beginning to break down.
An increasing share of enterprise work now crosses several applications, calls multiple data sources and combines human judgement with rules, automation and AI-generated outputs. The user may see a task in a dashboard, a message in a collaboration tool or an approval request on a phone. But the work itself is increasingly coordinated elsewhere.
The next enterprise operating system will therefore not be another monolithic application. It will be an orchestration fabric: an invisible layer that determines what should happen next, which system or agent should act, what authority it has, which policy applies and when a person must intervene.
Applications will remain. Their strategic role will change.
The Insight
Applications no longer contain the whole process
Enterprise applications were designed around functional domains. Finance systems manage financial records. Customer platforms manage sales and service activity. Supply chain systems manage inventory, orders and fulfilment. Each can be highly capable within its boundary.
The difficulty is that business outcomes rarely respect those boundaries.
Resolving a customer complaint may require a service record, an order history, a logistics update, a refund approval and a communication. Onboarding an employee may involve recruitment, identity, payroll, equipment, training and line management. Launching a product may cross product data, compliance, content, pricing, ecommerce and customer support.
In an application-centric model, people coordinate these journeys. They move information between systems, interpret status, chase approvals and decide which team should act next. Integration may automate parts of the transfer, but the end-to-end process is often held together by email, spreadsheets, local knowledge and human persistence.
This creates a misleading picture of enterprise software. The visible applications appear to run the business, while a large amount of operational coordination happens between them.
Orchestration makes that hidden work explicit.
The Strategic Shift
The control plane is moving behind the interface
Orchestration is the coordination layer that moves information, decisions and actions across systems, services, people and agents. It maintains the state of a workflow, applies rules, routes tasks, triggers integrations, manages exceptions and records what happened.
This is not an entirely new technical category. Enterprises already use workflow engines, integration platforms, event brokers, robotic process automation and business process management tools. What is changing is the scope and strategic importance of the coordination layer.
In October 2025, Gartner published its first Magic Quadrant for business orchestration and automation technologies, describing platforms that combine process orchestration, connectivity and agentic capabilities for enterprise-wide automation. That does not prove that one platform will become an enterprise operating system. It does show that previously separate automation categories are converging around cross-system coordination.
Vendor development points in the same direction. Microsoft introduced multi-agent orchestration so specialised agents could delegate work and collaborate across systems, teams and workflows. Salesforce has since positioned Agent Fabric as a control plane for multi-vendor agents, deterministic orchestration and governance. These are company product strategies rather than independent evidence of business value, but they reveal where major platforms expect complexity to accumulate: not inside one assistant, but between many actors and systems.
The visible interface may become simpler precisely because the operating environment behind it becomes more sophisticated.
The Experience Shift
The interface becomes a control surface
The shift to orchestration does not make user experience less important. It changes what the interface is for.
Many enterprise interfaces currently expose the structure of the underlying software. Users navigate modules, enter duplicate information, reconcile inconsistent records and advance work through screens designed around system boundaries. When orchestration coordinates the process, the interface can focus on intent, status, judgement and exception.
Consider an illustrative customer onboarding process. A salesperson confirms the commercial agreement. The orchestration layer validates the customer record, checks required documentation, creates accounts in relevant systems, initiates credit and compliance checks, schedules implementation tasks and prepares customer communications. A person sees only the decisions that require judgement, the exceptions that cannot be resolved automatically and the overall progress of the outcome.
The customer relationship management system, finance platform and service application still matter. They remain authoritative systems of record and carry out specialist transactions. But they no longer own the whole journey. The orchestration layer owns the sequence, dependencies and hand-offs.
This produces a different kind of software experience. Employees interact less with the machinery of the process and more with its moments of choice. Dashboards, task queues, conversational interfaces and alerts become control surfaces for work that is being coordinated across a wider operational fabric.
The interface remains visible. The operating logic moves behind it.
The Commercial Implication
Competitive advantage moves into workflow logic
Most organisations can buy broadly similar enterprise applications. They can access comparable cloud infrastructure, models, integration connectors and productivity tools. Those technologies remain important, but access alone offers limited differentiation.
The more defensible advantage lies in how an organisation coordinates them.
A high-performing workflow encodes more than a sequence of technical steps. It reflects operating knowledge: which information is reliable, which decisions can be automated, which risks require escalation, which customer promise takes priority and how the organisation recovers when something fails.
That logic is difficult to purchase as a generic feature because it is specific to the organisation's customers, economics, policies and ways of working. Two companies may use the same finance, customer and collaboration platforms but produce very different results because one has designed faster, clearer and more resilient cross-system workflows.
This changes the unit of technology strategy. Leaders have traditionally reviewed application portfolios: which systems to retain, replace, consolidate or modernise. They will increasingly need to review workflow portfolios as well: which outcomes cross the most boundaries, where coordination creates delay or risk and which orchestration logic represents strategic intellectual property.
It also changes software economics. Lock-in may shift from the application that stores the data to the platform that contains workflow definitions, agent configurations, policy rules, connectors and audit history. Replacing an interface can be inconvenient. Reconstructing the operational logic that runs hundreds of connected processes can be far harder.
The enterprise must therefore treat orchestration architecture as a strategic design choice, not simply another automation purchase.
The Governance Challenge
Invisible infrastructure creates visible risk
The more work that moves behind the interface, the more dangerous opacity becomes.
A person manually moving between applications may be slow, but their actions are often bounded by visible permissions and explicit steps. An orchestration layer can act across multiple systems at machine speed. A badly scoped identity, incorrect routing rule or compromised connector can propagate failure far beyond one application.
AI agents intensify this issue because they introduce non-deterministic behaviour and delegated action. It is not enough to know that a workflow ran. The organisation needs to know which human, service or agent acted, under whose authority, with which information, within which limits and with what result.
The OpenID Foundation's work on identity management for agentic AI highlights the need to distinguish the agent from the user and to support explicit on-behalf-of delegation. In practical terms, an agent should not inherit a person's full access merely because it is assisting them. Its authority should be narrow, temporary and traceable.
Governance must also move into the runtime. Policies written in documents cannot control high-volume automated action unless they are translated into executable constraints, approval thresholds and escalation rules. Observability must extend beyond application availability to reconstruct the end-to-end workflow: what happened, why it happened, what changed and where the process diverged from policy.
Regulation reinforces this requirement. The European Commission's implementation material for the AI Act includes logging, transparency, human oversight, accuracy, robustness and cybersecurity among the areas requiring technical standards or guidance. The implication is not that every automated process needs a larger interface. It is that invisible execution needs stronger evidence and control.
An orchestration layer without identity, policy enforcement, observability and recovery is not an operating system. It is a systemic failure multiplier.
The Organisational Shift
The operating model must follow the workflow
The organisational challenge may be larger than the technical one.
Applications usually have clear owners. A finance platform belongs to finance and technology teams. A customer system has a product owner, administrators and a vendor relationship. Cross-functional workflows are harder. They pass through several departments, each controlling one part of the process but not necessarily the outcome.
When orchestration becomes the control plane, application ownership is no longer enough. Organisations need end-to-end workflow ownership.
The business must own the outcome, decision rights and acceptable exceptions. Technology must own the reliability, integration and recoverability of the orchestration environment. Risk, security and legal teams must define controls that can be executed and evidenced. Operations must monitor workflow performance rather than only system uptime.
This creates new management questions. Who can change a workflow that affects several functions? How are changes tested when a single rule can alter thousands of transactions? Which team owns the service-level objective for an end-to-end process? Who can suspend an agent or roll back an automated action? How is capacity released by automation redirected rather than merely reported?
Without answers, orchestration will reproduce the same fragmentation it was intended to solve. Departments will build local automations, agents and connectors, creating another layer of hidden dependencies. The result will not be an enterprise operating system. It will be distributed automation debt.
The Leadership Agenda
Build the operating fabric before pursuing autonomy
The leadership agenda should begin with coordination, not autonomy.
First, identify workflows where value is lost between applications. Look for repeated hand-offs, duplicate entry, slow approvals, unresolved exceptions and outcomes that no single system owner can measure. These are stronger candidates than tasks selected only because an AI tool can perform them.
Second, separate the architectural roles. Systems of record should preserve authoritative data and execute transactions. Interfaces should support people's intent, judgement and supervision. The orchestration layer should manage state, routing, policy, evidence and recovery. Blurring these roles creates brittle dependencies and makes future change harder.
Third, design the control model before increasing machine authority. Every workflow should define identity, delegated permissions, approval thresholds, logging, exception routes, rollback and emergency suspension. Autonomy should expand only when the organisation has evidence that the workflow behaves reliably within those boundaries.
Fourth, measure the outcome across the process. A faster task is not enough if the customer still waits, rework moves downstream or risk increases. Useful measures include end-to-end cycle time, exception rate, first-time-right completion, human intervention, policy breaches, cost to serve and customer outcome.
Finally, treat workflow logic as an enterprise asset. Use standards where they preserve portability. Maintain version control, testing and documentation. Avoid concentrating every process in one opaque platform without a clear exit strategy. The aim is not to replace application lock-in with orchestration lock-in.
The next operating system will emerge gradually, workflow by workflow. Its success will depend less on how invisible it is than on how deliberately it is designed.
The Takeaway
The strategic asset is the coordination layer
Enterprise applications are not disappearing. Finance will still require financial systems. Customer operations will still need trusted records. Specialist work will still need specialist interfaces.
What changes is where the enterprise places control.
When applications become specialised transaction and record-keeping components inside wider workflows, the coordination layer starts to determine speed, quality, resilience and accountability. It decides how data becomes action, where judgement enters and whether automation remains within the organisation's authority.
That makes orchestration more than middleware and more than an AI feature. It becomes part of the operating model itself.
The practical question for leaders is therefore not which new application will become the enterprise operating system. It is whether the organisation can design, govern and improve the invisible infrastructure through which work increasingly gets done.
