Enterprise reorganization and the contest for the workflow

The largest near-term economic event may be neither a model breakthrough nor an IPO, but a redistribution of value across software, services, labor, and the operating processes of the firm.

Enterprise AI is often evaluated as a feature: a copilot added to existing software, a chatbot connected to internal documents, or a coding assistant sold by the seat. The deeper transition occurs when the unit of adoption changes from the individual user to the workflow. At that point, the organization must decide who owns process design, permissions, data, evaluation, exception handling, and accountability. This is the contest for the workflow.

Why the system of record is no longer the only control point

Traditional enterprise software gained power by becoming the authoritative database for customers, employees, finance, service, or operations. Agents create a new layer above those systems. An agent can read from several systems, decide what to do, and write back across them. The control point can migrate from the application that stores the record to the orchestration layer that interprets the situation and initiates action.

This does not make systems of record obsolete. Their data integrity, permissions, audit trails, and domain logic remain essential. It does, however, pressure seat-based economics when fewer humans directly interact with the interface. Vendors may respond by pricing agents, transactions, data access, or outcomes. The result is not simply "software is replaced by AI." It is that software, labor, and services become recombined around a new execution layer.

Incumbent layer	Traditional source of value	AI-era pressure	Likely response
Enterprise SaaS	System of record, workflow UI, per-seat subscription	Agents reduce direct UI use and can route across applications	Agent pricing, transaction fees, proprietary data services, embedded orchestration
Consulting	Diagnosis, process design, implementation, change management	Models automate analysis and artifact production	Outcome contracts, proprietary accelerators, governance, transformation operations
Business-process outsourcing	Labor arbitrage, process scale, service levels	Digital labor compresses headcount-based revenue	Human-agent operations, exception specialization, transaction pricing
Internal shared services	Control, institutional knowledge, standardized support	Automation challenges staffing and location models	AI operations center, retained process ownership, smaller expert teams
Frontier lab	Model capability, compute, API, consumer distribution	Model access commoditizes and customers demand proof of value	Agents, deployment platforms, managed workflows, commerce and transactions

Table 6.1. AI redistributes the control point rather than eliminating every incumbent layer.

Four enterprise operating models

A production agent is a socio-technical system with identity, authority, tools, memory, policy, evaluation, escalation, and a human owner. But most enterprises will not build every control component. The key choice is which operating model supplies those functions and which control rights remain with the customer.

Single-vendor consolidation: One application, model family, cloud, and governance suite minimize integration burden but maximize provider concentration.

Hyperscaler-managed plurality: One cloud, identity system, contract, and policy plane routes among several models. Procurement is concentrated even when model use is diverse.

Independent managed control plane: A neutral vendor or integrator operates routing, evaluation, observability, and fallback across providers and clouds.

Self-managed sovereignty: The enterprise operates the architecture internally. This is plausible for governments, regulated institutions, and unusually capable firms - not the default for the Global 2000.

Stage	Mechanism	Economic consequence
1	Observe	The agent receives events, data, or requests from approved sources.
2	Interpret	Models classify the situation, retrieve context, and propose a plan.
3	Authorize	Policy and identity systems determine whether an action is allowed.
4	Act	The agent writes to systems, communicates, purchases, changes code, or triggers a process.
5	Evaluate	Automated and human checks assess correctness, safety, cost, and outcome.
6	Escalate and learn	Exceptions go to accountable humans; feedback updates policies, prompts, tools, or models.

Figure 6.1. The enterprise agent control loop. Durable advantage resides in the whole loop, not the model alone.

The durable enterprise moat

The phrase "proprietary data is the moat" is incomplete. Raw data can be low quality, legally constrained, stale, or disconnected from decisions. The more durable advantage is a governed feedback loop: rights-cleared data, authority to act in a workflow, human review, outcome labels, evaluation infrastructure, and distribution to the people or systems that use the result. A provider that owns this loop can improve reliability and economics faster than a provider with a static data repository.

A stock-financed application acquisition can be an attempt to acquire a governed feedback loop rather than only another model. The pending boundary case and its data requirements are treated once in Chapter 5; no enterprise moat is inferred before post-close evidence.

Why many pilots fail to become economic systems

Pilot success is often measured by user satisfaction, benchmark quality, or time saved on a sample task. Production value depends on a broader denominator. The enterprise must pay for integration, permissions, data cleanup, evaluation, monitoring, security, change management, human review, and model usage. It must also account for work created by the system: exceptions, duplicated outputs, rework, new compliance reviews, and higher demand generated by lower unit cost.

The correct return-on-investment calculation compares the fully loaded cost and outcome quality of the redesigned process with the previous process. It should distinguish gross time saved from cash savings, capacity released from headcount eliminated, faster cycle time from additional demand, and local productivity from enterprise-wide financial performance. The ILO's review of empirical studies finds real but uneven productivity effects, limited evidence of large aggregate displacement so far, and substantial dependence on work design and institutional context (ILO 2026a).

ROI field	Common weak measure	Better measure
Productivity	Self-reported hours saved	Completed output per paid hour at equal or better quality
Quality	Model benchmark or user rating	Error rate, rework, customer impact, compliance, and downstream loss
Cost	Inference spend	Fully loaded integration, supervision, security, change, and liability cost
Adoption	Licenses issued or pilot users	Share of eligible workflow volume processed in production
Financial impact	Estimated annual benefit	Realized cash flow, avoided cost, revenue, working capital, or risk loss
Resilience	Normal-operation uptime	Recovery time, fallback success, vendor-exit test, and incident performance

Table 6.2. Enterprise AI ROI should be measured at the process level, not inferred from model usage.

The middle-tier compression thesis

The most exposed firms may be neither frontier labs nor deeply embedded systems of record, but thin layers of interface, prompting, or manual service between a broadly available model and a customer workflow. Labs can move into applications, incumbents can combine models with proprietary data and distribution, and customers can assemble open-weight alternatives. The middle tier survives through defensible workflows, regulated trust, unique distribution, proprietary outcome data, or operating excellence.

This compression extends beyond software. Advisory and outsourcing providers priced by hours or headcount must shift toward outcome accountability, specialized judgment, risk transfer, or proprietary operating platforms as AI reduces routine labor. The growth category is ongoing, technology-mediated execution of defined work - not simply more consultants using AI.

The operational capability constraint

Multi-model routing sounds modular at the architecture level but creates real operating burden: prompt and tool drift, provider-specific context and safety behavior, evaluation maintenance, identity, logging, data-zone rules, cost allocation, incident response, and version change. Many enterprise IT departments will rationally buy these capabilities from a hyperscaler or managed provider instead of operating them as a custom platform.

This yields an important measurement distinction. Procurement concentration can coexist with model diversity. An enterprise may use many underlying models while remaining dependent on one cloud, identity layer, router, contract, and billing relationship. Concentration must therefore be measured separately at the cloud/control-plane, model, application, data, and compute layers.

A board-level architecture for control rights and bargaining power

Own the control rights, not necessarily the software: Retain authority over identity, policy, approved models, evaluation, audit, cost limits, recovery, and exit even when a managed provider operates the plane.

Separate model, control plane, and workflow: Avoid making one provider's agent representation, memory, or tool schema the only executable form of a critical process.

Retain outcome data: Contract for logs, corrections, evaluations, and process-performance data.

Design human accountability: Name decision owners and the conditions that trigger human review.

Test exit before scale: Prove fallback, model switching, or manual operation within a defined recovery time.

Price the whole process: Negotiate against verified outcomes, not seats or token discounts.

Most production systems will combine purchased models, a managed control plane, internal policy and evaluation, third-party software, and human operations. The strategic decision is which rights and evidence the enterprise must retain - not whether it writes every routing component itself.