Orchestration layers are becoming the most contested position in the software stack

A sales manager asks a question in a chat window: which of our open deals are stalled because the customer is waiting on a legal review, and what should I do about it today. Answering that requires reading opportunity records in a CRM, checking a contract repository, scanning a shared inbox and two channels in a messaging tool, comparing the result against a revenue forecast in a warehouse, then writing back into the CRM and sending three messages. Five years ago this was a report request that took an analyst half a day. In mid-2026 it is a single request that a competent platform resolves in under a minute, and the platforms that resolve it are not the ones with the longest feature lists. They are the ones that hold identity, permissions, connection credentials and an audit trail for every system involved.

The orchestration shift stated plainly

That is the shift. Software value is migrating from the application that stores a record to the layer that coordinates action across many records held elsewhere. The change is visible in product roadmaps, in pricing, in acquisition prices, and in the specific technical work that vendors have been shipping since late 2024: protocol adoption, identity for non-human actors, policy engines, gateways, registries and audit logging. None of that appears in a feature comparison grid. All of it decides who captures the next decade of software spending.

The numbers behind the pressure are unremarkable individually and damning together. BetterCloud’s tracking put the average enterprise at roughly 106 SaaS applications, with large organizations running 131 or more. Independent estimates for mid-market companies land near 130 applications. Each one has its own permission model, its own API, its own idea of what a customer is, and its own renewal cycle. Human beings absorbed that fragmentation by learning where things live and copying data between tabs. Software agents cannot absorb it. They need a single addressable surface with declared capabilities, declared permissions and predictable failure behaviour, and building that surface is a different engineering problem from building another feature.

Two things happened at once. Language models became good enough to plan multi-step work rather than answer single questions, and a set of open protocols arrived that let those models reach systems they were not built into. The Model Context Protocol, introduced by Anthropic in November 2024 and handed to the Agentic AI Foundation under the Linux Foundation in December 2025, standardized how a model reaches a tool. The Agent2Agent protocol, released by Google in April 2025 and moved to Linux Foundation governance two months later, standardized how one agent hands work to another. By April 2026, A2A reached a v1.0 specification with cryptographically signed agent cards and more than 150 supporting organizations. MCP’s Python and TypeScript SDKs were seeing roughly 97 million downloads a month.

Protocols alone do not create a market position. What they create is a commodity: any client can now talk to any server. The scarce thing becomes everything the protocol deliberately left out. MCP standardizes connectivity and says almost nothing about governance. A peer-reviewed analysis of MCP tool orchestration published this year put it bluntly — the specification addresses connectivity, not governance. That gap is exactly where platform value has relocated.

Consider what a company actually needs before it lets an agent write to production systems. It needs to know which agent acted, on whose behalf, under what authorization, against which data, with what result, and it needs that record to survive an auditor’s questions eighteen months later. It needs a way to revoke an agent’s access in one place rather than in forty applications. It needs to stop an agent that starts behaving oddly without taking down the workflow it sits inside. It needs cost controls, because token consumption in production runs several times higher than in pilots. None of these requirements are features in the traditional sense. They are properties of a coordination layer, and they cannot be bolted on by the application at the end of the chain.

The competitive consequence is uncomfortable for most software companies. If your product is a system of record with a good interface, an orchestration layer can make you addressable and then make you interchangeable. Users will stop visiting your interface. Your data will be read and written by something else. Your renewal conversation will happen inside a procurement discussion about the orchestration platform, not about you. If your product is the orchestration layer, the opposite happens: every application that connects to you increases your gravitational pull, and every customer who wires their permissions through you raises the cost of leaving.

This analysis works through what an orchestration layer actually is, how the protocols function, who is competing for the position and with what strategy, where the security and regulatory constraints bite, what the shift means sector by sector, and what a company that is neither Microsoft nor a startup should reasonably do about it in the next twelve months.

Orchestration layer defined against integration and iPaaS

Precision matters here because three different things are being called the same word. Integration moves data between systems. Automation runs a predetermined sequence when a condition is met. Orchestration decides, at runtime, which systems to involve, in what order, with what authority, and what to do when a step fails. The first two are deterministic. The third involves judgment, which is why it only became commercially interesting once models became competent planners.

An integration is a pipe. When a deal closes in the CRM, create an invoice in the billing system. The mapping is fixed, the trigger is fixed, and the failure mode is a retry queue. Integration platform as a service — iPaaS — industrialized this. Zapier’s catalogue of roughly 7,000 to 8,000 connectors and its reported throughput of over two billion tasks a month represent the mature form: enormous breadth, shallow depth per connection, and a human deciding in advance what should happen.

Orchestration inverts the design. The goal arrives as a statement of intent rather than a trigger. Deciding which systems to touch happens during execution. The sequence changes based on what the earlier steps returned. An orchestration layer therefore needs capabilities an iPaaS never needed: a catalogue of tools described well enough for a model to choose between them, an authorization model that scopes each call to the acting principal, a memory of what happened across steps, a policy engine that can refuse an action, and an observability trail that reconstructs the reasoning after the fact.

Four components recur across every serious implementation, whatever the vendor calls them:

• A connection fabric. Something that speaks to target systems, holds credentials, refreshes tokens, and exposes each system’s capabilities as callable tools with machine-readable descriptions. MCP servers are the current standard form.
• A policy and identity plane. Something that answers: is this actor allowed to perform this action against this data right now. Microsoft calls its version Entra Agent ID plus Conditional Access; Google exposes per-agent principals and an agent gateway; identity vendors extend OAuth to cover the case.
• A runtime. Something that executes long-running, multi-step work, survives restarts, handles partial failure, and does not hold a session open for twenty minutes waiting on a human approval.
• An evidence layer. Logging, tracing and evaluation detailed enough to answer both an engineering question and a regulatory one from the same record.

The distinction between orchestration and the older categories is not academic, because it changes who the buyer is. iPaaS was bought by an integration team or a business unit. An orchestration layer is bought by whoever owns identity and risk, which in most companies means the CIO and the security organization jointly. That procurement path favours incumbents with existing identity relationships, and it is the single strongest structural advantage Microsoft holds.

Where the categories blur is in vendors moving across the line. Workflow automation tools have added agent nodes, model calls and memory; agent platforms have added deterministic branching because pure model-driven control flow proved unreliable for anything with money attached. The converged shape that most production systems now use is deterministic scaffolding with model-driven decisions at specific points, not a model improvising an entire business process. Teams that learned this the expensive way describe it as putting the agent inside the workflow rather than replacing the workflow with an agent.

One more definitional point. An orchestration layer is not necessarily a chat interface. Chat is one surface. Others matter more in practice: a scheduled run that reconciles two systems nightly, an event-triggered agent that responds to a webhook, an approval that arrives in a messaging tool, an embedded action inside an existing application. Treating orchestration as a synonym for chatbot is the most common reason pilots produce a demo nobody uses.

The point where point-to-point integration stopped scaling

The arithmetic of custom integration was always bad and everybody tolerated it. Connecting n systems to m consumers requires n multiplied by m pieces of work, each with its own authentication, error handling, rate limits, schema drift and on-call burden. With three systems and one consumer, that is manageable. With 106 applications and a growing set of models, assistants and agents that all want access, it stops being a project backlog and becomes a permanent tax.

What broke the tolerance was the change in who consumes integrations. A human-facing integration can be sloppy because a human notices when the data looks wrong. An agent-facing integration cannot, because the agent will act on whatever it receives. A field that silently changed meaning six months ago is a minor annoyance in a dashboard and a wrong invoice when an agent uses it. Agent consumption raised the required quality of every integration in the estate at the same moment it multiplied the number of integrations demanded.

The economics also shifted because the marginal cost of asking moved close to zero. When a report cost an analyst two hours, organizations rationed questions. When a question costs a few cents of inference, the volume of cross-system queries rises by an order of magnitude, and integrations built for a dozen daily calls start receiving thousands. Teams discover their rate limits, their token budgets and their data quality problems in the same week.

There is a measurement worth keeping in mind about the cost of coordination itself. One enterprise deployment analysis put baseline MCP overhead at roughly 600 milliseconds to three seconds per call — enough that the pattern works as an intelligence layer alongside critical paths but not inside a checkout flow or a trading loop. That number will vary widely by implementation and transport, and it should be treated as an order of magnitude rather than a specification. The design conclusion holds regardless: orchestration belongs adjacent to latency-critical systems, not inside them.

The older answer to fragmentation was consolidation. Buy fewer, bigger suites and accept mediocrity in individual functions to reduce the number of seams. That answer has partly failed and partly succeeded, and the split is informative. Companies did consolidate horizontal tools — the fourth project tracker got cancelled. They did not consolidate anything close to revenue, where best-of-breed still wins, and they added vertical, industry-specific tools at a faster rate than they removed horizontal ones. BetterCloud’s read of the 2026 market describes exactly this: reduced total sprawl alongside continued adoption of specialized vertical products.

So the estate stayed heterogeneous, and the seams stayed. What changed is that the seams became addressable through a common protocol rather than through bespoke code. That is a genuinely different situation from 2019, and it explains why the connector business changed character. Building a connector used to mean writing bespoke code per consumer. Building an MCP server means writing one description of a system’s capabilities that every compliant client can use. The count of published servers reflects the incentive: a May 24, 2026 pull from the official registry API returned 9,652 latest server records across 28,959 server and version records, and the GitHub search API showed 15,926 repositories tagged with the mcp-server topic on the same day. Anthropic’s own December 2025 ecosystem update cited more than 10,000 active public servers.

Adoption inside enterprises is harder to pin down, and the published figures disagree enough to be worth naming. Stacklok’s 2026 software report found 41% of surveyed software organizations running MCP servers in limited or broad production. Other widely circulated write-ups claim 78% of enterprise AI teams have MCP-backed agents in production. Those two numbers cannot both describe the same population, and the higher figure has repeatedly been published without a traceable methodology. Treat 41% of software organizations in some production use as the defensible floor and the higher claims as unverified. For anyone building a business case, the distinction matters: the first number describes early majority adoption among technical companies, the second implies near-universality that the rest of the evidence does not support.

The residual problem is that a protocol solves the connectivity tax without solving the trust tax. Every new server is another thing to vet, version, monitor and eventually deprecate. Registry governance, namespace trust, signed metadata and approval workflows are the active work items precisely because the connector explosion recreated the sprawl problem one layer up. A company that replaced 200 bespoke integrations with 200 unvetted MCP servers has changed its problem, not solved it.

MCP as the default wire protocol for tool access

The protocol is simple enough to describe accurately in a paragraph, which is part of why it won. An MCP server exposes three kinds of things to a client: tools, which the model can invoke to do something; resources, which the model can read; and prompts, which are reusable templates. A client — a chat application, an IDE, an agent runtime — connects to one or more servers, retrieves the list of available tools with their descriptions and input schemas, and passes those descriptions to the model. The model chooses a tool and supplies arguments. The client executes the call and returns the result. That is the whole mechanism.

The design choice that made adoption fast is the same one that created the security problem discussed later: tool descriptions are natural-language text written by whoever published the server, and the model treats them as instructions. This is what allows a server author to explain to a model when and how to use a tool without any coordination with the client. It is also what allows a malicious author to hide instructions in a description that the user never sees.

The transport story has consolidated. Early implementations used stdio for local servers and server-sent events for remote ones. Streamable HTTP has been displacing the older remote SSE approach, which matters for anyone maintaining servers written in 2025 — the migration is real work and it is not optional indefinitely.

Authorization is where the specification has moved most, across three revisions, and the trajectory tells you what enterprises complained about. The March 2025 specification established OAuth 2.1 as the foundation. The June 2025 update formalized MCP servers as OAuth resource servers and mandated resource indicators under RFC 8707, which stops a token issued for one server being replayed against another — a real attack given how many servers a single client connects to. The November 2025 revision replaced the earlier automatic client-registration flow with client ID metadata documents, removing the requirement that every authorization server maintain a registration database for every client it might see.

Despite that progress, the practical state of deployments lags the specification badly. Reviews of production MCP usage in 2026 note that static client secrets remain common and that single-sign-on integrated flows — where an IT administrator manages agent access through the corporate identity provider rather than through per-user consent screens — are still not the default experience. The official MCP roadmap published in March 2026 listed enterprise readiness among four top priorities, naming audit trails, SSO-integrated authentication, gateway controls and configuration portability as the concrete gaps. At the MCP Dev Summit in New York in April 2026, which the Agentic AI Foundation reported drew 1,200 attendees, authorization enforcement dominated the enterprise track. When 1,200 people gather and spend the enterprise sessions on authorization, the protocol has a governance problem it is publicly working through rather than a connectivity problem.

Governance of the standard itself changed the calculation for large buyers. A protocol controlled by one model vendor is a strategic risk; a protocol under a neutral foundation with working groups for transports, authentication and registry, and a formal process for proposing specification changes, is closer to infrastructure. That transfer in December 2025 is a large part of why competitors adopted it rather than forking it. Every major provider now supports it, which produces the network effect the protocol needed: each new server makes every client more capable, and each new client makes publishing a server more worthwhile.

What MCP deliberately does not do is worth listing, because vendors sell into exactly these gaps. It does not define who is allowed to call a tool beyond token validation. It does not define how to discover trustworthy servers. It does not version tool semantics in a way that protects a client from a server changing behaviour under it. It does not specify audit record format. It does not handle cost accounting. It does not orchestrate anything — orchestration frameworks sit above it and handle planning, chaining, memory and retrieval. The protocol is a socket, not a system, and the commercial contest is entirely about what plugs into the socket on the enterprise side.

A2A, agent cards and coordination across organizational boundaries

MCP answers how a model reaches a tool. It does not answer how one autonomous system delegates work to another autonomous system it does not control. That second problem arrives quickly in practice — a procurement agent inside one company needs a quote from a supplier’s pricing agent; a customer service agent needs a shipping estimate from a logistics provider’s agent; a marketing agent needs a media plan from an agency’s agent. Wrapping each of those as a tool call works until the responding side needs to run for twenty minutes, ask a clarifying question, or stream partial results.

The Agent2Agent protocol addresses that. Google published it in April 2025 and transferred the specification, its SDKs and related tooling to the Linux Foundation in June 2025 under vendor-neutral governance. Version 1.0 landed on April 9, 2026, at which point the project reported more than 150 supporting organizations including AWS, Microsoft, Salesforce and SAP, over 22,000 GitHub stars, SDKs in five languages, and production deployments across supply chain, financial services, insurance and IT operations.

The mechanics are deliberately HTTP-shaped. An agent publishes an agent card — a JSON document served at a well-known path that declares its skills, expected inputs and outputs, authentication requirements and service levels. Another agent retrieves the card, decides whether the counterparty can do what it needs, and submits a task: a goal, a thread of messages, and typed artifacts that the responding agent produces. The verb set is small — send a message, send a streaming message, get a task, list tasks, cancel a task, subscribe to a task, retrieve an agent card. Transport bindings cover JSON-RPC 2.0 over HTTPS as the primary path, with gRPC and plain HTTP/JSON alternatives.

Two additions in v1.0 matter more than the rest. Signed agent cards, using JSON Web Signature, let a client verify a card’s authenticity before trusting its declared capabilities or endpoints. That is the difference between a directory you have to pre-negotiate with every counterparty and a directory where identity travels with the declaration. Authentication requirements are declared inside the card under a security schemes field, covering OAuth 2.0 with explicit scopes, OpenID Connect, mutual TLS, API keys and HTTP bearer tokens, with credentials passed in headers separately from the message payload. The practical effect is that an agent can discover what a counterparty requires before submitting anything, rather than failing and retrying blindly.

The relationship between the two protocols is complementary rather than competitive, and understanding it prevents architecture mistakes. MCP is vertical: a client reaching down into tools and data. A2A is horizontal: peers exchanging tasks across a trust boundary. A single workflow uses both — an agent uses MCP to read its own company’s CRM and A2A to ask a partner’s agent for a delivery date. Analyses of the 2026 enterprise picture describe the pair as a two-layer backbone, and that framing survives contact with real deployments.

Where A2A remains thin is the same place MCP remains thin: what happens when things go wrong across a boundary. If a partner’s agent returns a confidently wrong answer, whose liability is it? If a task hangs, what is the escalation path? If a chain of four agents each introduce a small error, the compounding is not linear, and work on failure propagation in multi-agent architectures suggests the reliability of a chain degrades faster than intuition expects. Contract language has not caught up. Most commercial agreements signed in 2024 and 2025 say nothing about whether an automated system may act on the counterparty’s behalf, what logging each side must retain, or how disputes about an automated decision get resolved.

The near-term direction is convergence on discovery and registry. MCP’s roadmap includes a foundation-hosted registry with signed metadata, capability declarations and version tracking; A2A already has signed cards. Both are attempts to answer the same question — how do I know this thing is safe and current — and the answer will determine whether cross-company agent coordination stays inside pre-negotiated partnerships or becomes something closer to open commerce.

One orchestrated request traced end to end

Abstraction obscures where the difficulty lives, so it is worth walking a single request through a realistic stack. Take a request that a mid-sized B2B company might actually make: renew the maintenance contract for account 4471, apply the standard 4% uplift, get finance approval if the total exceeds €50,000, and tell the account manager.

Step one, resolution of intent. The orchestration layer receives text and must decide what work this implies. Nothing here is a database lookup yet. The layer needs to know that “maintenance contract” maps to a contract object in one system, that “standard uplift” is a documented pricing rule held somewhere in a policy document, and that account 4471 is a CRM identifier rather than an invoice number. This is where a context layer earns its cost. Microsoft’s Work IQ, generally available on June 16, 2026, exists to answer precisely this class of question — which entities in the tenant relate to each other and how — because a model that has to guess these mappings guesses wrong at a rate no finance team will accept.

Step two, authorization. Before any read, the layer resolves who is asking and what the acting principal may do. If the requester is an account manager, the agent must not be able to read contracts outside that manager’s book of business, even if the agent’s own service credentials could. This is the delegated action problem, and it is the single most common architectural failure: the agent runs with a broad service account, the audit trail records the service account, and nobody can later reconstruct on whose behalf the action occurred.

Step three, retrieval. The layer calls the CRM’s MCP server for the account and contract records, a document system for the current contract PDF and the pricing policy, and a billing system for payment history. Each call is a separate authorization decision. Each returns text or structured data that will enter the model’s context, which means each is an injection surface.

Step four, computation and drafting. The uplift is arithmetic and should not be done by a model — a deterministic function calculates it and returns a number the model then uses. Teams that let models perform financial arithmetic learn this lesson through variance reports. The model drafts the renewal terms and the message.

Step five, the policy gate. The total exceeds the threshold, so the workflow pauses and requests human approval. The technically interesting part is that the pause must survive: the runtime cannot hold an open session for the hours it takes a finance manager to respond. Durable execution — checkpointing state, resuming later, handling the case where the approver never answers — is unglamorous infrastructure that separates production systems from demos.

Step six, the write. After approval, the agent writes to the contract system and the CRM, and sends the notification. Writes are where blast radius lives. A read-only agent that hallucinates produces a wrong answer; a write-capable agent that hallucinates produces a wrong contract. Mature deployments treat write scopes as a separate, narrower grant than read scopes, gated per tool rather than per server.

Step seven, evidence. The run produces a record: which tools were called with which arguments, what each returned, what the model decided at each branch, who approved, what was written, and what it cost. That record serves three different audiences — an engineer debugging tomorrow, a finance analyst asking why the token bill tripled, and a regulator asking in 2028 whether an automated decision affecting a customer was properly authorized.

Count the components that had to exist for this to work: a context layer, an identity plane with delegation, a connection fabric, a deterministic function library, a durable runtime, an approval mechanism reaching a human in the tool they already use, scoped write permissions, and an evidence store. The model is one component among eight, and it is the one most easily swapped. That ratio explains why competitive advantage moved away from model quality and towards everything surrounding it, and why the companies best positioned are the ones that already owned identity, permissions and audit before any of this started.

Identity as the binding constraint

Every serious conversation about orchestration ends up at identity, and it ends up there because the existing identity model was built for a different kind of actor. Human identity assumes a person authenticates once, holds a session, and acts within roles assigned to their job. An agent authenticates continuously, acts across dozens of systems in a single task, may act on behalf of different people minute to minute, and can be created by anyone with access to a builder interface.

The specific failures are predictable. A shared service account gives every agent the union of permissions any agent might need. Consent screens designed for a person clicking through an OAuth flow do not work when the actor is a scheduled process. Offboarding a departing employee revokes their access but leaves running agents that were authorized under their credentials. Nobody can produce an inventory of which agents exist, because half were built by business users inside a low-code tool that never told IT.

Okta’s Cross App Access, announced in June 2025, is the clearest attempt at a standards-based answer. It extends OAuth so that app-to-app and agent-to-app connections resolve through the identity provider rather than through per-application consent, which puts visibility, scoping and revocation in one place. The protocol has since been formally incorporated as an official MCP authorization extension, which matters more than the vendor announcement — it means the agent connectivity standard and the enterprise identity standard now have a defined join. Okta reported more than 25 new integrations, availability of supported applications through its integration network from August 2026, and Auth0 early access for developers at the end of July 2026. A live customer beta ran with Anthropic as the agent side and organizations including HubSpot, Ramp and Webflow as participating providers, testing centralized authorization, policy enforcement and automated offboarding of agent permissions.

Microsoft’s version is built into its identity product rather than layered on top. Entra Agent ID gives each agent its own directory identity, with lifecycle and access management handled like any other organizational principal. That design choice has real consequences: an agent becomes something you can put in a group, apply conditional access to, review in an access review, and disable in one click. Microsoft has also begun charging for it — two service plans, Entra Conditional Access for Agents and Entra ID Protection for Agents, sit under the Microsoft 365 Agent and E7 licences, with organizations needing those licences from July 2026 to keep using agent security capabilities without interruption.

Google’s enterprise agent platform exposes per-agent principals alongside an agent gateway handling policy and allowlisting. AWS ties agent identity into its existing access management. The convergence across vendors on the same primitive — one identity per agent, not one identity per human plus a service account — is the strongest signal available that this is the settled architecture rather than a product fashion.

The delegation question remains genuinely unsolved in the general case. When an agent acts for a user, the audit record needs to name both, and downstream systems need to enforce the user’s permissions rather than the agent’s. Token exchange patterns handle the simple case. They handle poorly the case where a chain of three agents crosses two organizations, and the last one writes to a system that has never heard of the original human. Practitioners working through operational resilience requirements in financial services name this precisely as delegated action risk: the agent acts for a user, but the trail shows only a generic service account.

There is a governance angle that gets less attention than it deserves. Once agents have identities, they appear in headcount-adjacent systems, and organizations discover they need policies for who may create one, what approval a new agent requires, who owns it, what happens when its owner leaves, and how it gets retired. Companies that treated this as an IT ticket process ended up with hundreds of orphaned agents holding live credentials. Companies that treated it like onboarding a contractor — named owner, defined scope, expiry date, periodic review — ended up with a manageable population. The organizational discipline is more predictive of outcome than the technology choice.

The uncomfortable implication for buyers is that identity is the least portable part of the stack. Models are interchangeable. Connectors are increasingly standardized. Runtimes can be swapped with effort. Rewiring every agent identity, every conditional access policy and every audit integration from one identity provider to another is a multi-quarter project that nobody undertakes voluntarily. Whoever holds identity holds the account.

Permission sprawl and least privilege for non-human actors

Least privilege is easy to state and hard to implement when the actor’s task is defined in natural language. A human analyst asking for quarterly numbers needs read access to a warehouse. An agent asked to “sort out the Henderson account” might legitimately need to read a CRM, write a note, send an email, adjust a subscription and issue a credit — or it might need only the first of those, depending on what it finds. Provisioning for the maximum makes the agent dangerous. Provisioning for the minimum makes it useless. Provisioning at runtime requires a policy engine that can evaluate each intended action in context, and most organizations do not have one.

The practical patterns that have emerged are less elegant than the theory and work better than nothing:

• Role-scoped tool bundles. Rather than granting an agent access to a server, grant access to a named subset of that server’s tools, packaged per role or use case. A sales bundle exposes CRM reads and note writes but not discount approval or data export.
• Split read and write grants. Read access is broad and cheap; write access is narrow, enumerated and separately approved. Most useful work is read-heavy, and read-heavy integrations are also where MCP is most reliable.
• Confirmation policies per tool. Some tools run automatically, some always require confirmation, some are permanently allowed for a specific agent. Notion’s implementation of MCP connections for custom agents exposes exactly this granularity, letting a workspace member toggle individual tools and choose whether each requires confirmation before running.
• Credential inheritance made explicit. A frequent surprise is that a connection uses the credentials of whoever authenticated it, which means an agent inherits that person’s access rather than a defined role. Notion documents this behaviour openly — each MCP connection is unique to one agent and uses the authenticating person’s credentials. Systems that hide this behaviour cause the worst incidents.
• Time-bounded grants. An agent built for a quarterly migration should not hold access in year three. Expiry dates on grants force review.

The scale problem is what makes this hard to hand-manage. IDC’s projection, cited in Microsoft’s own security writing, has active AI agents in enterprises growing from 28.6 million in 2025 to more than 2.2 billion by 2030. Whether that specific figure holds is less relevant than the direction: the population of non-human actors will exceed the population of human ones by orders of magnitude, and permission review processes designed for annual human access certification cannot absorb that.

Permission sprawl also has a budget dimension that catches organizations out. Every agent identity that needs conditional access, threat protection and data-loss prevention coverage carries a licence cost. Microsoft’s pricing makes this explicit — Agent 365 reached general availability on May 1, 2026 at $15 per user per month, and the Microsoft 365 E7 suite announced on March 9, 2026 bundles E5, the Entra Suite, Microsoft 365 Copilot and Agent 365 at $99 per user per month. Governance for agents is a line item, not an assumption, and it is priced per human user rather than per agent, which changes the arithmetic for companies planning many agents per employee.

The security-side conclusion drawn independently by multiple research groups is that no single control is sufficient. Tool allowlisting, identity binding, runtime monitoring and human checkpoints together limit blast radius; any one alone does not. That is defence in depth restated for a new actor class, and it is the correct conclusion, but it also means the cost of doing orchestration properly is higher than the cost of the orchestration product itself.

Microsoft’s bid to own the control plane

Microsoft’s strategy is the most legible of any vendor because it is not really about agents. It is about making the tenant the unit of orchestration and then charging for governing it. Every component announced since late 2025 slots into an existing enterprise dependency.

The sequence is worth laying out with dates, because the gap between announcement and production is where most analysis goes wrong. Agent 365 was introduced at Ignite in November 2025 and spent roughly six months as an early-access service inside Microsoft’s Frontier programme. It reached general availability on May 1, 2026 — before Build, not at it — with a published price list, an administration experience inside the Microsoft 365 admin centre, and reach beyond Microsoft’s own platforms. Build 2026 extended the Agent 365 SDK to general availability, giving developers programmatic access to the registry and governance infrastructure. Work IQ, the context layer, reached general availability on June 16, 2026. Native support for Microsoft Execution Containers — a cross-platform, policy-driven runtime — entered preview in July.

The product structure repeats three verbs: observe, govern, secure. Observe is an agent registry with a topology map and the ability to surface unmanaged local agents that nobody registered — a discovery function that in most tenants produces an uncomfortable first report. Govern is Entra Agent ID plus conditional access, lifecycle management and access reviews applied to agents as directory principals. Secure is Defender for threat detection across the agent attack chain, Purview for data classification and compliance, and Intune-style management patterns.

The deliberate design decision is that Agent 365 governs agents built anywhere. Microsoft’s own materials list an ecosystem spanning Copilot Studio and Foundry agents, third-party agents from Adobe, Databricks, Cognition, Glean, Manus, n8n, SAP, ServiceNow and Workday, and open-source agents published on GitHub for Anthropic, CrewAI, Cursor, LangChain, OpenAI, Perplexity and Vercel. That breadth is the strategic move. Microsoft is not arguing that you should build your agents on Microsoft. It is arguing that whatever you build, you will manage it in the place where your identity, endpoints and data-loss prevention already live.

Work IQ deserves separate attention because it is the piece competitors find hardest to copy. An agent that can call tools still has to know what things mean inside a specific organization — which project a document belongs to, who owns a customer relationship, what the escalation chain is, how last quarter’s terminology maps to this quarter’s. That knowledge is latent in email, chat, calendar, files and org structure, and Microsoft holds all of it for a large share of the market. A context layer built over that corpus is not a feature another vendor can ship; it is a consequence of decades of data accumulation.

The commercial packaging tells you what Microsoft believes it can charge for. Agent 365 at $15 per user per month is priced against IT governance budgets rather than AI experimentation budgets. Microsoft 365 E7 at $99 per user per month bundles E5, the Entra Suite, Copilot and Agent 365, positioning agent governance as a suite upgrade rather than a discretionary purchase. Copilot’s continued advance — reported at around 60% adoption among Fortune 500 companies, and by July 2026 running GPT-5.6 as its preferred model — supplies the distribution that makes the bundle plausible.

Two honest limitations. First, general availability of a control plane is not the same as maturity of the controls inside it; independent reviews of the May 2026 release described it as a strong observability and identity layer with parts of the security story still arriving. Second, Microsoft’s advantage is weakest exactly where the data does not live in Microsoft. A company whose customer data sits in Salesforce, whose engineering work sits in Atlassian and whose analytics sit in Snowflake gets a governance plane from Microsoft but not a context layer, and the value of the former without the latter is real but smaller.

The competitive read is straightforward. Microsoft is not trying to win a capability benchmark; it is trying to win the procurement conversation, and it has a structural advantage no competitor can replicate: every enterprise already running Teams, Outlook, Azure and Entra has a Microsoft identity layer and a Microsoft purchasing relationship. Agent governance sold into that relationship does not need to be the best product to become the default one.

Salesforce and ServiceNow arguing from the system of action

The counter-argument to Microsoft’s identity-first position is that orchestration without business context is a police officer directing traffic on an empty road. Salesforce and ServiceNow both make it, from opposite ends of the enterprise.

Salesforce’s case rests on the data model. Agentforce agents operate directly on Salesforce records, which means no synchronization layer, no staleness, and inherited sharing rules, field-level security and audit behaviour. When a sales agent updates an opportunity, the permission logic that governed human access governs the agent identically, because it is the same permission logic. For customer-facing automation on data that already lives in the CRM, that is a real advantage over an external orchestrator that must be granted access and then trusted to respect boundaries it does not natively understand.

The company has extended the argument outward through Data Cloud for unification, MuleSoft for reach into systems Salesforce does not own, and an API-first posture that treats the CRM as a system of action rather than a place people visit. Pricing has moved fast and revealingly: an early model at roughly $2 per conversation gave way to Flex Credits at around $0.10 per action, which is a shift from charging for dialogue to charging for work performed. Salesforce has reported Agentforce customer counts in the thousands.

ServiceNow argues from process depth instead of customer data. Its position is that the hard part of enterprise automation is not the conversation but the workflow — approvals, assignment rules, service-level commitments, escalation paths, dependencies between tickets and changes — and that it already holds those for IT, HR, customer service, security operations, field service and governance functions. The 2026 product line reflects that: over 300 AI skills across more than 30 modules, an AI Agent Orchestrator that coordinates specialist agents across departments, AI Agent Studio for no-code customization, and an AI Control Tower positioned as a cross-vendor governance plane. ServiceNow was ranked first for building and managing AI agents in Gartner’s 2025 Critical Capabilities assessment, according to secondary reporting on that research.

The strategic subtlety is that ServiceNow’s control tower and Microsoft’s Agent 365 are competing for the same job from different starting points. Microsoft comes from identity and endpoint management; ServiceNow comes from workflow and change control. Both want to be the single pane where an enterprise sees every agent it runs. Both will be deployed in many of the same accounts, and the resulting overlap is a live procurement argument rather than a settled one.

Pricing philosophy differs in ways buyers should model carefully. Salesforce’s consumption pricing makes cost proportional to activity, which is attractive during pilots and alarming at scale without controls. ServiceNow’s tokenized approach bundled into platform licensing produces higher committed spend and more predictable running cost. Neither is better in the abstract; the choice depends on whether your finance function prefers variance or commitment.

The honest limitation applies to both. A platform whose orchestration advantage comes from owning the data model is strongest exactly inside its own boundary and weakest outside it. Agentforce is formidable on Salesforce data and ordinary on data in Workday. ServiceNow is formidable on processes modelled in ServiceNow and ordinary on a marketing workflow that lives in a separate stack. The practical pattern that emerged across large estates in 2026 reflects this: choose a primary build platform where most of the relevant data lives, then use a cross-platform control plane above it, accepting that governance and execution may come from different vendors.

Google and AWS playing the data-gravity hand

Google’s enterprise agent position is built on the assumption that whoever holds the analytical data holds the interesting agents. The pitch is a single managed platform covering the full lifecycle: an agent studio with low-code tool authoring over Gemini reasoning models for building, an agent runtime with fast cold starts and multi-region failover for scaling, per-agent identity and a policy-enforcing gateway for governance, and task-completion pricing with per-step model selection for cost control.

The component that competitors talk about most is the memory layer. Persistent agent memory addresses the failure that blocked multi-turn enterprise use cases — an agent that forgets everything between sessions cannot run an ongoing analytical conversation, a support relationship or a marketing programme. Whether Google’s implementation is better than alternatives is arguable; that memory is a first-class platform primitive rather than an application concern is now consensus.

The natural fit is a company whose data gravity sits in BigQuery and whose collaboration runs on Workspace. For that buyer, Google offers something structurally similar to what Microsoft offers its own installed base: a context layer nobody else can assemble, plus governance attached to an identity system already in use. Consulting partners including Accenture, BCG and Capgemini feature prominently in the go-to-market, which signals that Google expects these to be integration-heavy engagements rather than self-serve adoption.

AWS approaches from beneath. Bedrock AgentCore treats agents as infrastructure — runtime, memory, identity, gateway, observability — sold to engineering organizations that intend to build rather than configure. The bet is that a large share of production agents will be written by developers as software, not assembled in a business-user canvas, and that those developers want the same operational primitives they already use for services. AWS has also moved early on the payments side, previewing Bedrock AgentCore Payments in May 2026 with support for stablecoin negotiation, wallet authentication and spending limits with observability.

The practical result across large enterprises is not a single winner but a stable division of labour. Estates commonly run one vendor’s foundry for IT-led workflows, another’s CRM-native agents for customer-facing work, and a cloud provider’s agent infrastructure for engineering-authored systems, then attempt to unify governance above all three. Whether that unification actually happens is the open question. Buying three orchestration platforms and one governance plane is a coherent architecture; buying three orchestration platforms and hoping is the more common state.

The evaluation questions that separate a serious platform from a demo have become fairly standardized, and they are worth asking verbatim in a vendor meeting. Does the platform give each agent its own identity rather than a shared service principal? Can MCP servers be allowlisted at the organization level rather than per user? Are sensitive drafts excluded from shared model logs by default? Is there a kill switch at the control-plane layer, not merely per agent? How does the vendor document compliance with high-risk requirements under the EU AI Act? Vendors that answer these crisply have built for production; vendors that redirect to capability demonstrations have not.

Model vendors turning into orchestration surfaces

The model providers occupy an unusual position: they supply the reasoning that makes orchestration possible, and they are simultaneously trying to become the surface where orchestrated work happens. The tension between those roles has produced visible strategic wobbling.

OpenAI’s trajectory illustrates it. The Apps SDK, introduced in October 2025 and extended to Business, Enterprise and Edu customers in preview in November 2025, brought third-party applications into ChatGPT so users could summon them by name or have them suggested contextually. AgentKit followed as a builder-oriented set: a visual agent builder, ChatKit for embedding chat into products, an evaluation suite, and a connector registry for administrators managing data connections across an organization. On April 15, 2026 the Agents SDK gained a model-native tool-use wrapper with sandboxed execution for long-horizon work across files and tools. On April 22, 2026, shared Codex-powered workspace agents arrived for teams inside ChatGPT.

Then came a correction. On June 3, 2026 OpenAI announced it was winding down Agent Builder and its evaluation product, with both leaving the platform after November 30, 2026, directing code-oriented workflows to the Agents SDK and natural-language workflows to workspace agents in ChatGPT. That is a fast reversal on a product launched with prominence, and it says something useful about the category: a visual agent builder that sits between a chat surface and a code SDK is a hard product to sustain, because serious users graduate to code and casual users never leave chat. Any buyer who standardized on a vendor’s visual builder in 2025 should treat that as a live portability risk rather than a settled choice.

The scale behind the surface is real. OpenAI has reported roughly 800 million weekly users, four million developers and eight billion tokens processed per minute through its API. Codex passed five million weekly active users, and — the more interesting detail — knowledge workers now account for roughly a fifth of Codex users and are growing several times faster than developers. A coding agent becoming a general work agent is precisely the orchestration surface thesis playing out inside one product.

Anthropic occupies the complementary position. It created MCP and then gave it away to a neutral foundation, which is a strategy of commoditizing the connectivity layer rather than owning it. Claude functions as a client into the resulting ecosystem, and Anthropic’s participation as the agent side in Okta’s cross-app access beta — with HubSpot, Ramp and Webflow as providers — shows the direction: make the model the thing that reaches everything, and let enterprise identity govern the reach rather than trying to own governance directly.

The strategic risk for every model vendor is the same and it is structural. If reasoning becomes commodity — several providers at similar quality, switchable behind a routing layer — then the model is the interchangeable component in the eight-part stack described earlier. That pattern is well understood, and it explains the aggressive move up the stack into workspaces, apps, connectors and enterprise administration consoles. It also explains why an enterprise buyer should insist on model portability in contracts even when they have no intention of switching. The option has value independent of exercise.

There is a second-order effect on discoverability that marketing and content teams have noticed. When ChatGPT, Copilot or Gemini becomes the place where a professional starts a task, being retrievable inside those surfaces matters as much as ranking in a search results page. That is the same underlying shift, viewed from the demand side: the orchestration layer decides which sources, tools and vendors get invoked, and inclusion in that decision is a distribution question, not a features question.

Independent orchestrators and the SAP bet on n8n

The most informative price paid in this market was not for a model company. In May 2026, SAP took a strategic stake in n8n, the Berlin workflow automation company, at a $5.2 billion valuation — more than double the $2.5 billion set in its October 2025 Series C, which itself followed a $350 million valuation the year before. Total funding across rounds sits at roughly $254 million. Revenue growth explains part of the jump: annual recurring revenue passed $40 million with usage reported up tenfold year over year, on a base of more than 200,000 active users and enterprise customers including Volkswagen, Delivery Hero, Decathlon, KPMG and Vodafone.

Why would SAP, which has its own integration and automation products, pay that price for an independent orchestrator? Because the thing n8n has is not connectors. It is a position in the middle of heterogeneous estates, with more than 1,000 integrations, support for no-code, low-code and code in the same workflow, multi-agent coordination inside an auditable execution model, and — the part European buyers keep raising — self-hosting for data residency, GDPR and sector-specific requirements. SAP customers run SAP alongside dozens of systems SAP does not sell. An orchestrator that speaks to all of them, can be hosted in the customer’s own environment, and does not require standardizing on one vendor’s stack is a distribution asset.

The independent segment has stratified clearly. Zapier holds breadth and simplicity, with 7,000 to 8,000 connectors, reported throughput above two billion tasks a month, and a position Gartner’s integration research characterizes as citizen integration — automation built by business users. Make occupies the middle with a visual scenario builder supporting branching, iteration and aggregation at materially lower cost than equivalent Zapier volumes. n8n holds the developer-led end, competing less with Zapier than with workflow engines like Temporal and Airflow for technical orchestration. Workato and Tray remain embedded in enterprise procurement cycles. Composio, MintMCP and similar newer entrants sell the connector-plus-governance layer directly, offering hosted MCP gateways with role-based tool bundles, single sign-on, provisioning-driven access control and audit.

Total spending on workflow automation reached an estimated $13.6 billion globally by the end of 2025 — a large market, but small relative to the enterprise software spend that orchestration touches, which is why every large vendor is willing to lose money establishing position in it.

Platform positioning in the orchestration contest, mid-2026

The table compresses positions that overlap in practice; most large estates end up combining two or three of these rows rather than choosing one. The pattern to notice is that no contender is strong in both native context and cross-estate neutrality, which is why governance and execution increasingly come from different vendors.

The risk for independents is distribution, and it is not hypothetical. Power Automate ships inside Microsoft 365, meaning millions of users already have an automation tool they did not buy separately. Every hyperscaler has an orchestration product. The independents’ counter is flexibility, developer adoption, open architecture and hosting choice — genuine advantages that matter most to technically capable buyers and matter least to procurement departments consolidating vendors. Anyone building a business on an independent orchestrator should treat licence terms and self-hosting rights as strategic rather than administrative details, particularly with fair-code and source-available licences where the terms constrain what a competitor may do but also constrain what a customer may do.

Payments enter the orchestration stack

Payments is where orchestration stops being an internal productivity story and becomes an external commerce one, and it is the fastest-moving protocol area of the last twelve months. The core problem is simple to state and hard to solve: if an agent buys something, how does a merchant or a bank know the human actually authorized it, and who bears the loss when the answer is no.

Four protocol families now address different layers, and confusing them leads to bad architecture decisions.

Authorization and trust. Google announced the Agent Payments Protocol in September 2025 with more than 60 launch partners, including Mastercard, PayPal, American Express, Adyen, Coinbase, Etsy, Intuit, Revolut, Salesforce, ServiceNow, UnionPay International and Worldpay. Its central abstraction is the mandate — a cryptographically signed statement from the consumer, carried as W3C verifiable credentials, in three forms covering intent, cart and payment. The mandate travels with the transaction, so a merchant or network can verify that the agent had real authorization rather than mere possession of credentials. Google subsequently transferred AP2 to the FIDO Alliance for community governance and shipped v0.2, which added support for transactions where the human is not present at the moment of purchase — a pre-authorized ticket purchase, for example.

Checkout execution. The Agentic Commerce Protocol, created by Stripe with OpenAI and Meta, standardizes how an agent interacts with a merchant’s catalogue and completes checkout inside an AI surface, using a shared payment token so the agent never sees raw card credentials. Its first prominent deployment was Instant Checkout in ChatGPT, launched in February 2026 with US Etsy sellers. OpenAI then scaled back in-chat purchasing in early March 2026 and shifted toward an app-based model. The protocol survived the product pivot, with continued support from Stripe, Salesforce, Shopify and PayPal, which is building its own implementation.

Commerce journey. The Universal Commerce Protocol was announced on January 11, 2026 at the National Retail Federation show, co-developed by Google, Shopify, Etsy, Wayfair, Target and Walmart with more than 20 endorsing partners. It covers discovery, cart, checkout, orders and post-purchase — the full journey rather than the checkout moment — and explicitly cites AP2 as its recommended payments layer.

Machine-to-machine settlement. Coinbase’s x402 uses the HTTP 402 status code to make stablecoin payment part of an ordinary web request, aimed at API, data, compute and content access priced per call. V2 shipped in December 2025, Stripe integrated it on Base in February 2026, Cloudflare supports it, and the Linux Foundation launched an x402 Foundation as neutral governance in April 2026. Stripe and Tempo launched the Machine Payments Protocol on March 18, 2026 with a sessions model letting an agent pre-authorize a spending limit and then stream micropayments in stablecoins or fiat.

The economic driver for the stablecoin path is unglamorous arithmetic. Card interchange at typical retail spreads runs roughly $0.50 to $0.80 per transaction according to Federal Reserve interchange research, which makes sub-dollar agent purchases uneconomic. Settlement on chains like Base or Solana costs cents or fractions of a cent. For agents that transact in small amounts, across borders, at machine speed, the fee structure decides the design.

Infrastructure has followed. Stripe built an agent wallet on its issuing product that routes spend requests to consumers for approval through the web and its Link mobile applications, with full issuing APIs for businesses building custom agentic wallets. Visa announced agent-initiated payment acceptance using tokenized credentials with real-time authorization, fraud monitoring and user-set limits on spending, merchant categories and approvals. Adyen shipped a modular API suite in June 2026 covering product feeds, cart creation and payments across conversational surfaces.

The demand evidence is early and should be read carefully. Salesforce data from December 2025 indicated that retailers with agent integration saw roughly seven times better sales growth during Cyber Week 2025 than those without, and Adobe Analytics reported that AI-referred visitors completed purchases at a rate around 38% higher than traditional search visitors. Both figures come from parties with an interest in the conclusion, and both measure an early-adopter population that differs systematically from the market as a whole. The direction is credible; the magnitudes should not be put in a board deck without that caveat.

Documents, retrieval and the context layer

Ask any team that has run an orchestration project for six months what surprised them most and the answer is rarely the model. It is that the documents were worse than anyone admitted. Contracts in three formats with four naming conventions. Policies that contradict each other because the 2023 version was never withdrawn. A wiki where the most-read page was last edited by someone who left in 2022. Human beings routed around this by knowing which sources to trust. An agent has no such judgment and will cite the withdrawn policy with complete confidence.

Retrieval is therefore not a technical afterthought in an orchestration stack; it is a governance function. The specific decisions that determine whether an agent gives correct answers are mundane: which repositories are authoritative, how versioning is expressed, whether superseded documents are removed from the index or merely marked, how access control on the source flows through to the index, and who is accountable for the answer when the source was wrong.

The permission question causes the most damage in practice. A naive retrieval implementation indexes everything the service account can read and then answers questions for users who should not see all of it. That is a data breach with a search box in front of it, and it has happened repeatedly in organizations that treated retrieval as a search project rather than an access-control project. Permission-aware retrieval — where the index enforces the requesting user’s entitlements at query time rather than at ingestion time — is the minimum acceptable design, and it is substantially harder to build than the alternative.

Context layers are the vendor answer to this. Microsoft’s Work IQ is the clearest example: an organizational intelligence layer that lets agents reach across a tenant while Agent 365 governs what any given agent may see and derive. Its documentation is explicit that privacy controls should prevent agents from reaching personal information beyond functional requirements. Google’s equivalent grounds agents in analytical data with governed semantics. Data catalogue vendors have moved into the same territory from the metadata side, serving definitions, classifications and lineage to any compliant agent through an MCP server so that the agent reads governed context from a layer the company owns rather than inferring meaning from raw text.

That last pattern deserves emphasis because it inverts a common assumption. The instinct is to give the agent more raw data. The better outcome usually comes from giving it less raw data and more governed context — canonical definitions, current status, ownership, classification. An agent told that a field is deprecated will avoid it; an agent shown the field will use it.

Document generation runs in the other direction and creates its own problems. Once agents draft contracts, proposals, reports and summaries at volume, the repository fills with machine-produced text that later retrieval will treat as source material. Without provenance marking, the next generation of agents learns from the previous generation’s output, and errors compound quietly. Organizations that got this right marked machine-generated documents at creation and excluded unreviewed drafts from authoritative indexes. Organizations that did not are now discovering circular citations in their own knowledge bases.

There is a records-management dimension that legal teams raise and technical teams underestimate. If an agent produces a document that a regulator may later demand, retention rules apply to it, and if the agent’s reasoning trace is part of how the document was produced, an argument exists that the trace is discoverable too. Companies in regulated sectors have started treating agent execution logs as records subject to retention schedules rather than as ephemeral telemetry. That decision has storage cost implications nobody budgeted for in a pilot.

The practical checklist for the document layer is short and rarely completed:

• Name the authoritative source for each class of question and exclude the rest from retrieval.
• Withdraw superseded documents from the index rather than relying on the model to notice a date.
• Enforce entitlements at query time, per requesting principal.
• Mark machine-generated content at creation, and keep unreviewed output out of authoritative indexes.
• Assign a named owner to each authoritative corpus who is accountable for its accuracy.
• Decide, with legal input, which agent traces are records and how long they are kept.

Communication tools as the human interface of orchestration

Orchestration produces a stream of things humans must decide, approve, correct or notice. Where that stream surfaces determines whether the system gets used. Practitioners converged on an unglamorous answer: put it in the tool people already have open, which for most knowledge workers means a messaging platform or an inbox.

The design reason is behavioural rather than technical. An approval that requires logging into a separate console adds latency measured in hours because people check consoles when they remember to. An approval that arrives as a message with two buttons gets answered in minutes. Since durable orchestration workflows spend most of their wall-clock time waiting on human decisions, the placement of the decision point is often the largest single determinant of end-to-end cycle time.

This is why messaging platforms became orchestration surfaces rather than just notification targets. Agents deployed into a channel can read the thread for context, answer in place, take action across connected systems, and leave the reasoning visible to everyone in the channel — which turns out to matter for trust. A colleague who watched an agent explain its reasoning in a shared channel for two weeks develops calibrated confidence in it. A colleague who receives only outputs from an opaque process either over-trusts or ignores it.

The governance pattern that works assigns each long-running assistant its own identity with scoped credentials and approved tool bundles, rather than running it under the creator’s permissions or a shared service account. Vendors selling gateway products for this describe the sequence in the same order: single sign-on and provisioning-driven role control first, tool-level policy and audit second, agents enabled above that foundation third. Teams that reversed the order — agents first, governance later — spent the following quarter retrofitting.

Notion’s implementation of custom agents shows the granularity now considered normal. Native integrations are authorized at workspace-owner level with read, write and trigger capability; MCP connections can be added by any workspace member with read and write but no triggers; tools within a connection can be individually enabled, set to require confirmation, run automatically, or be permanently allowed; and each connection uses the credentials of whoever authenticated it and is not shared between agents. Every one of those choices is a security decision that a workspace member is making, often without realizing it.

Which raises the failure mode specific to this layer: shadow orchestration. When any employee can connect an agent to company systems from inside a productivity tool, the population of agents holding live credentials grows faster than any inventory of it. This is the same pattern as shadow IT with a shorter fuse, because a spreadsheet nobody knew about does not send emails. The discovery function in agent management platforms — surfacing unmanaged agents that were never registered — exists because this happened at scale, and the first scan in a typical tenant finds more than the security team expected.

The other consideration is volume. An orchestration layer that notifies humans about everything trains them to ignore notifications, which defeats the purpose of the human checkpoint. Calibrating which decisions genuinely need a person is the work, and it should be driven by consequence rather than uncertainty: a reversible action with small financial exposure can proceed and be audited afterwards, while an irreversible action or one crossing a monetary threshold stops for approval regardless of the agent’s confidence.

Analytics, semantic layers and governed numbers

Numbers are the place where orchestration failures become visible fastest, because two people comparing figures will find a discrepancy within a week. If an agent answers a revenue question by writing SQL against raw tables, it will produce a number that differs from the finance report, and the difference will not be a bug — it will be a definitional disagreement about what counts as revenue, which contracts are recognized, and whether cancelled orders are excluded.

The answer that survived contact with production is the semantic layer: a governed set of metric definitions, dimensions, joins and access rules that sit between raw storage and any consumer. Consumers include dashboards, notebooks and now agents. An agent that queries the semantic layer inherits the organization’s definition of revenue rather than inventing one. An agent that queries raw tables inherits nothing.

Vendors have made this explicit in their agent positioning. Analytics platforms describe agents powered by a universal semantic layer that carries governance down to row-level access, so that decades of accumulated access rules apply to the agent identically to a human analyst. That claim is worth testing rather than accepting, but the architectural principle is sound: an agent should reach data through the same governed interface that governs everyone else, not through a privileged side channel created because the governed interface was inconvenient.

Three practical consequences follow for anyone building this.

First, metric coverage becomes a gating factor for agent usefulness. If only 40 of your 200 commonly asked business questions have governed definitions, the agent will answer 40 correctly and improvise the rest. The remedy is unexciting: define the metrics. Teams that expected the model to compensate for missing definitions were disappointed.

Second, ambiguity handling matters more than accuracy on well-specified questions. Asked for “sales last quarter,” a good implementation asks whether that means bookings or recognized revenue, and which fiscal calendar. A bad one picks one silently. The behaviour is configurable in most platforms and is usually left at the wrong default.

Third, the read path and the write path need different treatment. Reading a governed metric is low risk. Writing a forecast adjustment, changing a segment definition or updating a target is a change to shared truth that other people depend on, and it belongs behind approval regardless of how confident the agent is.

There is a measurement discipline question underneath all of this that most organizations avoid. If an agent handles a workflow, what is the baseline it improved on, and how is the improvement being measured? The honest answer in many deployments is that nobody recorded the baseline before automating, which makes the return unmeasurable afterwards. Surveys through 2026 repeatedly find large majorities of organizations unable to demonstrate return on AI spending, and the most common reason is not that the return is absent but that the pre-automation measurement never existed. Recording cycle time, error rate, cost per task and volume for four weeks before deployment costs almost nothing and is the difference between a defensible programme and a faith-based one.

Coordination failures that never appear in demos

Demos succeed because they run one path with clean data and a cooperative user. Production fails on the paths nobody demonstrated. The failure catalogue is now well enough documented to be predictable, which means it is also preventable, and the gap between organizations that anticipated these and organizations that discovered them is most of the difference in outcomes.

Partial completion. A workflow updates three of five systems and then fails. The CRM says renewed, the billing system does not, and no human knows. Deterministic integrations handled this with transactions or compensating actions. Agent workflows frequently handle it with nothing, because the failure occurred inside a plan the agent invented at runtime. The mitigation is to make write sequences explicit and idempotent, with defined compensation for each step, rather than letting the model decide the order.

Silent scope drift. An agent asked to clean up duplicate contacts decides that two records with similar names are duplicates and merges them. They were a parent company and a subsidiary. Nothing errored. The mitigation is to constrain destructive operations behind confirmation regardless of confidence, and to require reversibility for anything an agent may do unattended.

Confidence without grounding. The model produces a fluent answer built on a stale document or a misread field. Detection requires citation of sources and spot-checking against the source, not review of the answer’s plausibility. Reviewers who check whether an answer sounds right approve wrong answers at a high rate.

Error compounding across chains. Four agents each 95% reliable do not produce a 95% reliable chain. Work on failure propagation in multi-agent systems describes how an early error becomes an unquestioned premise for everything downstream, because subsequent agents treat upstream output as fact. The mitigation is to keep chains short, validate between hops with deterministic checks, and prefer one agent with several tools over several agents passing messages when the task allows it.

Loop and retry cost explosions. An agent that cannot complete a step retries, expands context, and retries again. Costs measured per task in a pilot can run several times higher at production volume, and organizations that budgeted for pilot-scale inference discovered production workloads generating multiples of the projection. Hard limits on iterations, context size and spend per task are not tuning; they are containment.

Latency mismatch. Coordination overhead of roughly half a second to a few seconds per tool call is acceptable in a workflow that runs for minutes and unacceptable in a path a customer is waiting on. Placing an orchestration layer inside a synchronous customer interaction is the most common architectural mistake of 2026.

Data quality surfacing as behaviour. An agent that reads a field which three teams populate differently will behave inconsistently in ways that look like model unreliability. Debugging this by adjusting prompts wastes weeks; the fix is upstream.

Permission-induced silent failure. An agent lacks access to one system, cannot say so clearly, and produces an answer based on the systems it could reach. The output looks complete. The mitigation is to make tool-level authorization failures loud and to have the agent state explicitly what it could not access.

Gartner’s forecast that more than 40% of agentic AI projects will be cancelled by the end of 2027 — attributed to escalating costs, unclear business value and inadequate risk controls — reads differently against this list. The cancellations are not model failures. They are the predictable result of deploying coordination systems without the operational discipline that coordination requires, compounded by a naming problem the same research flags: work labelled agentic that never needed an agent, where a deterministic workflow would have been cheaper, faster and more reliable. Gartner’s own advice is to use agents where decisions are genuinely needed, automation for routine sequences and assistants for simple retrieval — a triage that most programmes skipped.

The projects that survive share identifiable traits: graduated autonomy that expands as evidence accumulates, human verification gates placed according to consequence rather than uniformly, cost checkpoints reviewed with finance at each phase, and a named owner accountable for each agent. None of those are technical.

Prompt injection and tool poisoning as structural risks

The security position deserves plain statement because vendor material tends to soften it. In an orchestration layer, any text an agent reads can behave as an instruction, and there is currently no complete defence against that. Not a mitigation gap that a patch closes — a property of how these systems work.

The mechanism was documented early. Simon Willison described in April 2025 how MCP tool descriptions visible to the model but not shown in user interfaces could carry hidden adversarial instructions, and Invariant Labs disclosed working techniques in the same month. Since then the attack surface has been catalogued into distinct classes worth naming separately, because the defences differ:

• Tool poisoning. Malicious instructions hidden in tool metadata that the model reads and the user cannot see.
• Indirect prompt injection. Instructions embedded in content the agent retrieves — a support ticket, a GitHub issue, a shared document, a web page — that hijack the task mid-execution.
• Output injection. A server returns text containing new instructions that redirect the conversation.
• Cross-tool poisoning. One compromised server’s description manipulates how the agent uses a different, legitimate tool.
• Rug-pull updates. A previously clean server ships an update adding poisoned content, and the host reloads tool descriptions without re-prompting the user for consent.

The empirical picture is not reassuring. A systematic security analysis surveyed more than 1,800 deployed MCP servers and found over 30% with at least one exploitable vulnerability. The MCPTox benchmark constructed 312 attack scenarios across 14 vulnerability classes and reported that even the strongest commercial agents failed roughly half of the prompt-injection-via-tool-output scenarios — meaning the model followed the malicious instruction more often than it ignored it. A separate empirical study across seven widely used MCP clients concluded that client-side security is currently inadequate, with wide variation between implementations: some enforce strong guardrails while others proved highly susceptible to cross-tool poisoning, hidden parameter exploitation and unauthorized tool invocation, enabling credential theft, surveillance and phishing.

Exposure has been quantified from the network side too. An internet scan in July 2025 identified at least 1,862 publicly reachable MCP instances responding to unauthenticated requests, which follows from the specification marking authorization optional. A May 2026 disclosure by OX Security, summarized in subsequent security analysis, described a systemic design issue affecting up to 200,000 vulnerable MCP instances across development environments, internal tools and cloud services. As of May 2026, a Cloud Security Alliance research note counted at least seven confirmed high or critical severity CVEs across MCP-integrated platforms including MCP Inspector, LiteLLM, Cursor, LibreChat and Windsurf, with more under tracking.

Supply chain risk compounds all of this. The Postmark incident in September 2025 is the case to remember: the maintainer of the official Postmark MCP server added logic that silently copied every sent email to an attacker-controlled address, and incident response found the backdoor live across multiple versions. The lesson generalizes beyond MCP — a valid package signature proves provenance, not behaviour. Running an npm-installed server with credentials to production systems means trusting every dependency in that tree, and the wave of npm compromises through 2025 made that trust harder to justify.

The structural point in the best security writing on this is that all of these incidents share one root cause: there is no control operating at the semantic layer between what an agent intends and what the system executes. Network monitoring, endpoint protection and perimeter controls observed several documented attacks and recorded no violation, because none of them were designed to evaluate whether an action was consistent with what the actor was authorized to accomplish. The agent had valid credentials and made valid API calls. Everything was permitted and the outcome was still theft.

Frameworks have caught up faster than tooling. OWASP published a Top 10 for Agentic Applications in December 2025, sitting alongside its established list for language model applications, with tool misuse and agentic supply chain vulnerabilities as separate categories. Microsoft’s security organization has published pattern analysis mapping observed 2026 attacks against enterprise agents to those categories, using the concrete example of a finance operations agent handling vendor invoices — a scenario chosen because it combines privileged write access, untrusted inbound content and an external communication channel, which is the combination that produces the worst outcomes. NIST launched an AI Agent Standards Initiative in February 2026, with an interoperability profile expected around the fourth quarter of 2026.

What actually reduces risk today is a set of controls that no single vendor sells complete:

• Treat every MCP server as an untrusted third party and apply zero-trust assumptions accordingly, including servers published by companies you buy software from.
• Allowlist servers and individual tools at organization level, so that adding a server is an administrative decision rather than an individual one.
• Bind identity per agent and scope credentials narrowly, so a compromised agent’s reach is bounded by design rather than by hope.
• Pin versions and review updates, because rug-pull attacks depend on silent reload of changed descriptions.
• Separate read from write and place human confirmation on writes with real consequence.
• Scan servers before adoption using available tooling — several open scanners exist — while recognizing that scanning finds known patterns, not novel instructions.
• Log at the request boundary, capturing which agent, on whose behalf, against which data, with what policy outcome, because application logs typically capture none of these.
• Run incident exercises specific to agent compromise, since the containment steps differ from a normal breach: revoking an agent identity, halting a workflow mid-execution and reconstructing what it already did.

The honest bottom position for a decision maker: an orchestration layer with write access to production systems is a high-value target with an attack class that current models do not reliably resist. That does not argue against deploying one. It argues for deploying one with bounded blast radius, loud logging and a rehearsed response, and for accepting that the first serious incident in this category at most companies will be discovered by accident rather than by a control.

Observability, evaluation and audit evidence

Three audiences need records of what an agent did, and organizations that built for one discovered they could not answer the other two. An engineer needs traces detailed enough to reproduce a failure. A finance analyst needs cost attribution per workflow, per team, per model. A regulator or auditor needs evidence that a specific automated decision was authorized, that the data used was permitted, and that a human was accountable.

The technical requirement is a trace per run capturing the request, the resolved principal and delegation chain, every tool invocation with arguments and results, model calls with versions and token counts, policy decisions including refusals, human approvals with identity and timestamp, final writes, and total cost. That list is longer than what most agent frameworks emit by default, and retrofitting it after a compliance question arrives is expensive.

The point that specialists in regulated sectors keep making is that records which survive an inspection are produced at the AI request boundary, not by the application that sent the request. Application logs record that a call happened. They do not record which vendor model served it, which human the agent acted for, what data category was exposed, which policy governed the decision, what the outcome was, or the timestamp in a form that ties to everything else. Building that record centrally, at the point where every agent request passes through, is architecturally cheaper than assembling it from a dozen application logs afterwards.

Evaluation is the second half and is treated less seriously. A deterministic integration either works or throws an error. An agent workflow can complete successfully and be wrong, which means correctness has to be measured statistically against a maintained set of cases with known good outcomes. Teams that built evaluation sets early can answer whether a model version change improved or degraded their workflow. Teams that did not are guessing, and they are guessing on a system that changes underneath them whenever a provider updates a model.

The version-change problem is underappreciated in procurement. An orchestration layer built on a hosted model inherits behaviour changes it did not request. Regression suites specific to the organization’s own workflows are the only protection, and they need to run automatically against candidate versions rather than being executed manually after users complain. Vendors that offer pinned model versions with defined deprecation windows are offering something operationally worth paying for, even at a premium.

Cost observability closes the loop, and it maps onto FinOps practice reasonably well. Tokens are a metered resource; the useful denominator is cost per completed unit of work rather than cost per token. Tracking that ratio over time reveals whether a workflow is improving or quietly degrading — a rising cost per completed task usually means more retries, which usually means an upstream data or permission problem rather than a model problem.

One organizational note. Ownership of observability tends to fall between teams: platform engineering owns tracing, security owns audit, finance owns cost, and nobody owns the composite view. The companies that handled this well named a single owner for agent operations with visibility across all three, on the reasoning that the questions arrive mixed together. When a workflow starts costing triple and producing wrong answers, that is one incident, not three.

The EU AI Act timetable after the Digital Omnibus

Anyone planning an orchestration programme in Europe needs the current dates rather than the ones circulating in decks written last year, because they changed in June 2026 and the change is partial in a way that is easy to misread.

The AI Act entered into force on 1 August 2024 with staggered application. Obligations for high-risk systems were originally scheduled to apply from 2 August 2026 for stand-alone systems listed in Annex III, and from 2 August 2027 for AI embedded in products already regulated under Annex I. By late 2025 implementation was visibly behind — national competent authorities were not designated, harmonized standards were not finished, and the compliance tooling that high-risk requirements assume did not exist. The European Commission responded by publishing the Digital Omnibus on AI on 19 November 2025, proposing targeted amendments including a delay mechanism for the high-risk obligations.

The legislative path was contested. A second political trilogue on 28 April 2026 ended without agreement. Provisional political agreement followed on 7 May 2026. The European Parliament endorsed it on 16 June 2026, and the Council gave final approval on 29 June 2026, making it the first substantive amendment to the AI Act since adoption.

The resulting dates: high-risk obligations for stand-alone Annex III systems apply from 2 December 2027, and for AI embedded in Annex I regulated products from 2 August 2028. In the final text these application dates are no longer conditional on completion of harmonized standards, which removes an uncertainty that had made planning difficult. Transparency requirements under Article 50 were not deferred and took effect as scheduled. The machine-readable marking obligation under Article 50(2) moved to 2 December 2026 for systems already on the market at 2 August 2026 — a four-month extension rather than the six months originally proposed — while systems placed on the market after that date must comply at placement. A new prohibited practice covering AI systems for generating non-consensual intimate imagery and child sexual abuse material applies from 2 December 2026. Smaller organizations received documentation relief, with lighter technical documentation requirements for high-risk systems available to companies below 750 employees and €150 million turnover.

The strategic reading matters more than the dates. A deferral of sixteen months on the heaviest obligations is not a reason to stand down, for two reasons that legal commentators have made repeatedly. The first is that 2 August 2026 was not cancelled — transparency duties landed. The second is that the deferred deadline extends time for the single task most organizations have not completed and cannot skip: determining which AI systems they operate, which fall in scope, which are high-risk under Annex III as amended, and producing a defensible written classification for each. That inventory is the prerequisite for everything else, it takes months in a large estate, and orchestration makes it harder rather than easier, because agents assembled by business users inside productivity tools do not appear in any procurement record.

Orchestration layers create three specific classification difficulties. First, an agent that coordinates several systems may touch a high-risk use case incidentally — a general workflow agent that occasionally screens a job application is operating in an Annex III area whether or not anyone designed it to. Second, the boundary between provider and deployer obligations blurs when a company assembles an agent from a vendor’s platform, a third-party model and its own tools; who is the provider of the resulting system is a question that requires legal analysis rather than an engineering opinion. Third, the record-keeping obligations attach to systems, and an orchestration layer that executes thousands of heterogeneous workflows needs to be able to isolate the records for the ones that are in scope.

The penalty structure explains why this receives board attention. Fines for prohibited practices reach up to 7% of global annual turnover, which is a materially different exposure from the operational costs of compliance. Complete audit trails and model validation are explicit expectations for high-risk automated systems, which loops directly back to the observability architecture described earlier — the compliance record and the engineering record are the same record if the system was designed that way, and two separate expensive projects if it was not.

One useful piece of regulatory design: Article 9(10) of the AI Act permits integrating AI risk management into existing sectoral risk management procedures rather than maintaining a parallel structure. For firms already operating mature risk frameworks, that means the AI programme can be an extension of what exists rather than a new function, which is both cheaper and more likely to be maintained.

DORA, sector supervision and third-party concentration

Financial services faces the most developed supervisory expectations, and they arrived before the AI-specific rules, which makes the sector a preview of where other regulated industries end up.

The Digital Operational Resilience Act does not distinguish between a human operator, a microservice and an agent. If a workflow supports a financial service, depends on information and communications technology, calls third-party interfaces or can affect customers, it belongs in the operational resilience model. An agent that reads customer records, opens tickets, queries email, updates CRM data or calls a payment-adjacent interface is an ICT system within the regulation’s meaning, and the risk management obligations apply whether or not the firm thought of it that way. Germany’s BaFin issued non-binding guidance in January 2026 confirming that AI systems, generative models included, must be integrated into DORA-compliant ICT risk management frameworks.

The third-party pillar is where orchestration creates the sharpest exposure. Articles 28 to 44 require a register of information documenting all ICT third-party arrangements, submitted annually to competent authorities by 31 March, with contracts containing mandatory provisions on exit strategies, audit rights and security requirements. An orchestration layer multiplies third-party relationships: the platform vendor, the model provider, every MCP server operator, the identity provider, the observability vendor. Each is a dependency in a chain supporting a regulated service, and each needs to appear in the register with an exit strategy that has been tested rather than described.

Concentration risk is the supervisory concern that sits behind this. If most European financial institutions run agent workloads through two or three model providers on two or three clouds, a single outage or a single model behaviour change propagates across the sector simultaneously. The European supervisory authorities can designate critical ICT third-party service providers under Article 31, bringing the vendor itself under direct oversight, with the first round of designations expected during 2026 and cloud providers and the largest AI vendors the most likely categories. The Financial Stability Board’s work on AI in the financial sector identifies the same cluster of vulnerabilities: third-party dependency, service provider concentration, correlated market behaviour, cyber risk, model risk and data governance.

The two regimes apply concurrently and overlap usefully. A credit scoring system a bank operates using a third-party AI service falls under both — the DORA register covers the third-party relationship, the AI Act’s high-risk classification covers the algorithmic obligations including record-keeping under Article 12. Both require operational records at the AI request boundary, and both can be satisfied from a single per-request audit trail. Firms that built two compliance programmes are paying twice for one artifact.

The operational records that specialists expect to be requested during an inspection are specific: which AI vendor served each request, which workforce member or automated agent initiated it, which data category was exposed, which policy governed the decision, what the outcome was, and the timestamp. DORA also demands verifiable operational independence — a firm must be able to protect, detect, contain and recover without depending on the vendor’s support process, which for an agent workflow means having a documented and tested way to halt it and continue the business function manually.

The wider regulatory perimeter around this is thickening in parallel. In the United States, sector rules including model risk management expectations under SR 11-7 and state cybersecurity requirements such as NYDFS Part 500 apply to AI systems processing customer data, with risk assessments, access controls and audit trails expected. The Colorado AI Act took effect on 30 June 2026 with obligations on developers of high-risk systems. Payment card requirements restrict agent access to cardholder data under the same need-to-know and unique identification rules that apply to humans, which is a quietly demanding constraint: a shared service account fails the unique identification test outright. ISO 42001 has become the AI management system standard buyers ask vendors about, alongside the SOC 2 and ISO 27001 baseline.

The practical conclusion for regulated buyers: agent identity, per-request audit records and tested exit strategies are not compliance overhead added after deployment. They are the deployment. Firms that treated them as phase two have generally had to rebuild.

Data protection under orchestrated access

An orchestration layer makes personal data more reachable, and reachability is the thing data protection law is most concerned with. The legal questions that were manageable when each system had its own access control become harder when one actor can read across all of them.

Purpose limitation is the first pressure point. Data collected for billing has a lawful basis for billing. An agent that reads billing data to answer a marketing question has extended the purpose, and the fact that the extension was decided at runtime by a model rather than in advance by a person does not change the analysis. Organizations that mapped lawful basis per system found that mapping insufficient once a single agent could combine sources, and the remedy is to attach purpose constraints to the tool grant rather than to the system.

Automated decision-making obligations bite where the agent’s action affects a person. Article 22 of the GDPR governs decisions based solely on automated processing that produce legal effects or comparably affect someone, requiring a lawful basis, transparency and a route to human review. An orchestration layer that declines a refund, adjusts a credit limit, screens an application or closes an account is operating in that territory. The design consequence is that certain classes of action need a human decision in the loop by legal necessity rather than by risk preference, and identifying which classes is work for legal counsel and product owners together rather than for either alone.

Cross-border transfer creates a structural conflict that has no clean answer. If an agent orchestrating European customer data calls a model hosted outside the European Economic Area, the transfer analysis applies to the content of the prompt, which may include personal data assembled from several systems. Data residency requirements and the possibility of foreign government access under legislation such as the US CLOUD Act interact awkwardly with shared cloud environments, which is a large part of why self-hosted orchestration retained a market among European buyers. n8n’s positioning on data sovereignty — enterprises keeping control of their data while meeting GDPR, internal residency requirements and sector rules — is a direct response to that demand rather than a marketing preference.

Data minimization runs against how these systems work. A model performs better with more context; a data protection assessment prefers less. The reconcilable position is to minimize at retrieval — return the specific fields needed for the specific task rather than whole records — which requires tools designed with narrow, purpose-specific operations rather than generic record fetching. Most first-generation MCP servers return whole objects because it was simpler, and that choice is now a compliance liability in the estates that adopted them.

Subject rights add a mechanical problem. When someone requests erasure, the request must reach every place their data was copied, including caches, indexes, vector stores and conversation logs held by the orchestration layer. Companies that indexed everything for retrieval and logged full prompts for debugging created two new locations for personal data that their erasure process did not know about. Redaction at the request boundary, before logging, is the cheaper fix than retroactive log surgery.

Finally, the shadow AI dimension. Discovery of unmanaged agents matters for data protection as much as for security, because an agent nobody registered is processing personal data outside any assessment. Tooling for network-level discovery of AI use, policy enforcement across employees and agents, and real-time redaction of sensitive data exists precisely because organizations found substantial unsanctioned processing when they looked. A data protection programme that does not include an agent inventory is describing an organization that no longer exists.

Banking and insurance back offices

Financial institutions have the strongest incentive to orchestrate and the tightest constraints on doing it, which makes their choices instructive for everyone else.

The economics are compelling in the back office rather than the front. Reconciliation between core systems, exception handling in payment operations, claims triage, know-your-customer refresh cycles, complaint routing and audit evidence assembly are all high-volume, multi-system tasks with clear correctness criteria and painful manual cost. These are the workloads where an orchestration layer earns its keep — measurable baselines, deterministic checks available, and an existing control framework to attach to.

The constraint pattern is consistent. Every agent gets its own identity, because shared service accounts fail both DORA’s accountability expectations and payment card unique-identification requirements. Write access is granted per operation with approval thresholds mapped to monetary exposure. Data lineage is maintained so that an incident investigation can answer, in minutes, which data fed which decision. A governed inventory records each agent, the sources it reads and the third-party models it calls, feeding both ICT risk management and the register of information. Every definition, dataset and agent has a named owner, because supervisors hold the financial entity accountable even when the technology runs at a third party.

Insurance has an additional angle in claims and underwriting, where automated decisions affecting individuals fall under both the AI Act’s high-risk territory and the GDPR’s automated decision-making provisions. The practical design is that an agent assembles the file, verifies documents, checks policy terms and computes an indicative outcome, then a human adjudicates. That division preserves most of the cycle-time gain — file assembly is where the hours went — while keeping the decision human. Firms that tried full automation on claims decisions generally retreated to this shape after the first regulatory conversation.

Fraud operations shows an interesting inversion. Detection models were already automated; what orchestration adds is the investigation workflow around an alert — pulling transaction history, device data, related accounts and prior cases into one assembled view. That is retrieval and coordination rather than judgment, and it is where the measurable gain sits.

The failure mode specific to this sector is treating the agent as a model risk problem only. Model risk frameworks were built for statistical models with stable behaviour, documented assumptions and periodic validation. An orchestration layer changes behaviour when a hosted model version changes, when a tool description is updated, when a document is added to an index, or when a permission is adjusted. Validating it once tells you about that day. The governance object is the running system, not the model inside it, and firms that recognized this built continuous monitoring rather than annual validation.

Cost discipline arrives faster here than elsewhere because banks have mature technology cost accounting. The practice that spread quickly is per-workflow cost attribution with a threshold that triggers review, on the observation that a rising cost per completed task almost always indicates a data or permission problem upstream rather than a pricing change.

Healthcare and life sciences workflows

Healthcare presents the widest gap between the administrative work orchestration handles well and the clinical work it should not touch, and the organizations doing this competently are strict about the boundary.

The administrative side is enormous and largely uncontroversial. Prior authorization requests requiring assembly of clinical notes, coding data and payer rules from separate systems. Referral coordination across practices with incompatible records. Appointment logistics involving scheduling systems, transport, interpreters and equipment. Billing denial management where the reason for a rejection lives in one system and the supporting evidence in three others. Clinical trial site coordination, where document collection and regulatory filing consume disproportionate staff time. None of these involve clinical judgment; all involve reading and writing across systems that were never designed to talk to each other.

The clinical side is constrained by both regulation and prudence. Any system contributing to diagnosis or treatment decisions sits in high-risk territory under the AI Act and under medical device frameworks depending on its function, with obligations on documentation, validation, human oversight and post-market monitoring that a general-purpose orchestration platform does not satisfy by default. The pattern that survives review is retrieval and summarization presented to a clinician with sources visible, not recommendation.

Data protection is stricter than in most sectors and interacts badly with retrieval architecture. Health records carry special category status under the GDPR and equivalent protection elsewhere, and permission-aware retrieval becomes non-negotiable rather than good practice. A retrieval index built over clinical documents with service-account permissions is a serious breach waiting for a query, and the sector has enough examples to have learned this.

The integration reality in healthcare deserves specific mention because it differs from other industries. Interoperability standards exist and are widely implemented in name — record exchange formats, terminology systems, messaging standards — while actual semantic consistency between two organizations’ implementations is often poor. An agent reading a field that one hospital populates with a code and another populates with free text will behave inconsistently, and the model is not the problem. Terminology mapping is the unavoidable prerequisite work, and it is measured in months.

Life sciences has a distinct opportunity in regulatory and quality documentation, where submissions require assembling evidence from laboratory systems, manufacturing records, clinical databases and document repositories under strict traceability requirements. The traceability requirement, which sounds like a barrier, is actually an advantage: organizations in this sector already log everything, already have named document owners, and already run change control, which means the evidence layer an orchestration system needs mostly exists. The sectors that struggle most with agent governance are the ones with the least existing document discipline, not the ones with the most regulation.

Retail and readiness for agentic commerce

Retail faces the shift from both sides simultaneously: internal orchestration of merchandising, inventory and service operations, and external exposure to agents shopping on customers’ behalf. The second is the more consequential and the less well prepared.

The external requirement is that product data, pricing, availability, policies and checkout become readable and actionable by software rather than only by humans reading a page. That is what the commerce protocols encode. The Universal Commerce Protocol covers discovery, cart, checkout, orders and post-purchase. The Agentic Commerce Protocol handles checkout execution inside an AI surface with payment credentials shielded behind a shared token. AP2 supplies the authorization proof that lets a merchant or issuer verify a human actually authorized the purchase. They stack rather than compete, and a single transaction can involve all three.

The practical readiness checklist for a retailer is concrete: structured, complete and current product feeds; machine-readable inventory and pricing including promotions; policies on returns, warranty and shipping expressed in a form an agent can quote accurately; an agent-accessible checkout path; and a decision about which protocols to support. That last decision is genuinely uncertain, and the honest advice is to follow the payment service provider rather than to bet independently — Stripe, Adyen and the card networks are all shipping agentic capability, and a merchant is better off adopting what its provider supports than implementing a protocol directly.

Fee structure needs careful attention and current verification. Reported fee arrangements attached to early in-chat checkout products — combined platform and processing costs in the region of 7% on a $100 order, according to one analysis of the launch terms — were tied to a specific surface that was subsequently shut down in March 2026. Whether those terms apply to current agent commerce products is unconfirmed, and merchants should verify live terms with their provider rather than modelling from published figures. Getting this wrong changes unit economics on low-margin categories entirely.

Internally, the highest-value orchestration in retail sits in exception handling. A delayed shipment that requires checking inventory, notifying the customer, offering an alternative, adjusting the order and updating the forecast touches five systems and is currently handled by people copying between screens. Markdown decisions requiring sales velocity, competitor pricing, inventory position and margin targets are the same shape. Both have clear correctness criteria and measurable baselines.

The strategic question retailers are actually arguing about is discoverability. If a sizeable share of purchase journeys starts inside an assistant rather than a search engine or a retailer’s own application, the retailer’s position depends on being selected by an agent, and the selection criteria are not fully transparent. That is a distribution risk of the same kind that search engines created two decades ago, with the difference that an agent may complete the transaction without the customer ever seeing the retailer’s brand presentation. Retailers that treat agent readiness purely as a technical integration project are missing that the merchandising question — how do you differentiate when the customer never sees your page — has no established answer yet.

Agencies, consultancies and professional services

Professional services firms sit in an unusual position: they are early adopters of orchestration internally, and their business model is partly threatened by clients adopting it. Both halves are worth examining honestly.

Internally, the work is a good fit. A marketing agency running campaigns for thirty clients handles the same coordination problem thirty times over — briefing documents, asset repositories, advertising platforms, analytics, client communication and invoicing, each in a different system, often with different tools per client. Orchestration collapses the coordination overhead, which in agency economics is the difference between billable and non-billable hours. The measurable targets are specific: time from brief to first draft, time from client feedback to revised asset, reporting cycle time, and the proportion of staff hours spent on coordination rather than craft.

The client-side threat is real but narrower than the loudest predictions. Work that consisted of assembling information, producing standard documents and running routine processes compresses. Work that consists of judgment under uncertainty, accountability for outcomes, and access to people who will not take a meeting with a junior does not. The firms that suffered were the ones whose margin depended on billing junior hours for assembly work.

The commercial response that has worked is repricing rather than resisting. If a deliverable that took forty hours now takes eight, hourly billing destroys revenue while fixed-price or outcome-linked billing preserves it. Firms that moved to deliverable-based pricing before their clients noticed the change in effort retained margin. Firms that kept billing hours had an uncomfortable conversation.

There is a second business appearing here that is worth naming: orchestration implementation as a service. Mid-sized companies need agent governance, tool inventories, permission models, evaluation suites and audit trails, and they do not have the internal capability to build them. That is consulting work with clear deliverables, and it is being sold by firms ranging from the largest integrators — Accenture, BCG and Capgemini feature in the go-to-market of at least one hyperscaler’s enterprise agent platform — down to specialist boutiques running two-to-three-week readiness assessments. The specialist end has an advantage on speed and price that the large end cannot match on small engagements.

For agencies specifically, there is a client-facing service opportunity in agent-readiness of content and data. If assistants are becoming a route through which customers find and evaluate products, then making a client’s information retrievable, accurate and current inside those surfaces is a service line with the same logic as search visibility work, requiring different technical execution. The measurement problem is harder — attribution inside an assistant conversation is poor compared with a click from a results page — and any agency selling this should be candid with clients that the measurement is immature rather than pretending otherwise.

The internal governance point applies here as much as in a bank, and small firms routinely skip it. An agency agent with access to thirty clients’ advertising accounts, asset libraries and customer data is a concentration of access that would fail any client’s vendor security review if the client asked about it. Increasingly, clients are asking.

Manufacturing, logistics and field service

Physical operations have the longest-standing integration problem and the most conservative attitude towards automation, which produces a distinctive adoption pattern: orchestration arrives in the planning and administrative layers long before it approaches anything that moves.

The systems are genuinely heterogeneous. Enterprise resource planning, manufacturing execution, warehouse management, transport management, quality systems, maintenance systems, supplier portals and customer order systems, frequently spanning multiple instances from multiple decades. Many were integrated once, badly, and the integration is now load-bearing and undocumented. This is the estate where an orchestration layer’s neutrality counts for most, and it explains part of why SAP found an independent orchestrator worth a $5.2 billion valuation — its customers’ surrounding systems are exactly this mess.

The high-value workflows are exception-driven. A supplier delivery slips, which requires checking production schedules, alternative suppliers, safety stock, customer commitments and shipping options, then deciding what to change and updating five systems. A quality deviation requires assembling batch records, supplier certificates, test results and prior deviations. A maintenance alert requires checking parts availability, technician skills and schedules, and production windows. Each is a coordination problem with a defined answer, currently solved by an experienced planner who knows which screens to open.

Where the physical constraint bites is autonomy. An agent that reschedules production has consequences that cannot be reversed by clicking undo — material is consumed, labour is committed, a customer commitment is missed. The design that works keeps the agent in an advisory position: it assembles the situation, proposes options with the trade-offs quantified, and a planner decides. The gain is in the assembly, which was consuming most of the planner’s day.

Field service adds a mobile dimension where the interface question matters more than the orchestration. A technician needs the right information on a phone in a basement with poor connectivity, which puts hard constraints on latency and offline behaviour that a cloud-hosted agent chain does not naturally satisfy. Practical implementations pre-assemble a job packet before dispatch rather than orchestrating live during the visit.

Supply chain coordination across companies is where cross-organizational agent protocols will eventually matter most, because the current mechanism is email and spreadsheets between planners at different firms. Signed agent cards and declared capabilities offer a path to automating that exchange without bespoke integration per partner, and A2A deployments have been reported in supply chain contexts. The obstacle is not technical. It is that neither party’s contract says anything about automated systems acting on their behalf, and neither legal department wants to be first.

The measurement culture in manufacturing is an advantage worth exploiting. These organizations already track cycle times, first-pass yield, schedule adherence and cost per unit with rigour. Establishing a pre-automation baseline — the step most software-oriented companies skip — is routine here, which means manufacturing programmes are more likely to produce defensible numbers about what orchestration actually delivered.

Skills that gained value and skills that lost it

The individual-level change is less about job replacement than about which skills carry a premium, and the evidence available in mid-2026 points in a fairly specific direction.

The clearest signal comes from an unexpected place. Codex, a coding agent, reached five million weekly active users, and roughly a fifth of those users are knowledge workers rather than developers — a group growing several times faster than the developer population. People whose job title has nothing to do with software are using a software agent to do their work, because the agent can read files, run commands and complete long tasks in a controlled environment. That is a general work tool that happened to be built for programmers, and its spread outside programming is the most concrete indicator of what the near-term change looks like.

The skills that gained value are unglamorous. Specifying work precisely enough that an automated system can execute it correctly is now a broadly useful professional skill rather than a programming one. The ability to define what done looks like, enumerate edge cases, name the authoritative source for a fact, and specify what should happen on failure — these were project management competencies and are becoming general ones. So is verification: knowing how to check an output against a source rather than assessing whether it reads plausibly. Fluent wrong answers are the characteristic failure of these systems, and the people who catch them are the ones who check sources.

The skills that lost relative value are the ones that consisted of moving information between systems. Assembling a report from four sources, reformatting data, filling a template, chasing an update, compiling a status summary. Anyone whose role was substantially composed of these tasks has a real transition to make, and the honest framing is that the transition is towards judgment, relationship and accountability work rather than towards more coordination work.

There is a competence trap worth naming. Reviewing agent output is cognitively different from producing it, and it degrades over time in a predictable way: reviewers who see correct output ninety-five times stop reading carefully by the ninety-sixth. This is a well-documented pattern in every field that automated a task and kept a human as a checker. The mitigations are structural rather than motivational — sampling with deliberate verification against sources, deterministic checks that catch specific error classes automatically, and rotation so no one person reviews the same output stream indefinitely.

Career positioning follows from the earlier analysis of where value sits. The layer that coordinates is where the influence sits, which means understanding identity, permissions, data governance and audit is more useful than deep familiarity with any individual application’s interface. A professional who knows how their organization’s permission model works, where authoritative data lives, and how to construct an evaluation set is more useful in an orchestrated environment than one who knows every menu in a single tool. That is a real reallocation of what expertise means, and it favours people willing to learn how systems fit together over people who have mastered one system.

For anyone managing a team through this, the practical advice is narrower than the discourse suggests: pick one workflow the team dislikes, measure it for four weeks, automate the assembly portion while keeping the decision human, and measure again. That produces evidence, builds skill, and avoids the failure mode of announcing an AI programme and then hunting for something to apply it to.

Pricing models and the real cost of coordination

Pricing is the clearest evidence that vendors themselves believe the shift is real, because pricing is where a company reveals what it thinks it is selling.

The seat is breaking as a unit of value, and the reason is arithmetic rather than fashion. Per-seat licensing charges for headcount. When one person with an agent does work that previously required five, per-seat pricing penalizes the customer for becoming more productive and penalizes the vendor for having delivered the productivity. Gartner’s forecast had roughly 40% of enterprise SaaS including outcome-based elements during 2026, up from about 15% two years earlier, and projects at least 40% of enterprise SaaS spend shifting to usage, agent or outcome models by 2030. Deloitte’s technology predictions for 2026 model seat-based vendor revenue share declining from 21% to 15%. Supply already exists ahead of buyer readiness — one industry count found 83% of AI-native software companies offering usage-based pricing, and other tracking puts the share of companies using some form of usage-based billing higher still.

The models in circulation are distinct enough that conflating them causes budgeting errors.

Orchestration pricing models and what they expose the buyer to

The table lists published or widely reported terms rather than negotiated enterprise pricing, and every one of these is subject to change; the point is the structural difference in what each unit exposes the buyer to rather than the specific figures.

The outcome-pricing case with the most public evidence is Intercom. Its support agent launched at $0.99 per resolution, defined as an issue solved without human handoff, with real-world resolution rates reported in the 42% to 50% range in case studies referenced by third-party analysis. In April 2026 the billable event broadened from resolutions to outcomes, adding successful hand-offs, while keeping the commitment that no successful outcome means no charge. Reporting on the financial effect put net revenue retention moving from 112% to 146%, on the logic that outcome pricing lets the product expand inside existing accounts without seat friction. That is a substantial result and it explains the enthusiasm, though it comes from one company in one category with an unusually measurable unit of work.

Outcome pricing has a contractual requirement buyers underestimate: you need a written definition of what counts as a valid outcome before signing, or you will argue about it during every invoice cycle. A resolution that the customer reopened two days later, a hand-off the agent triggered unnecessarily, a task completed against stale data — each is a billing dispute waiting to happen.

The cost that surprises organizations is not the licence but the consumption. Production workloads at enterprise volume have been reported generating costs several times higher than pilot projections, with the multiplier driven by full context windows, multi-step reasoning chains and retry loops rather than by list-price changes. A coding agent at a couple of hundred dollars per developer per month in testing can reach an order of magnitude more at production scale. The controls that work are unromantic: caps on iterations per task, caps on context size, per-workflow spend limits with alerting, cheaper models for steps that do not need the expensive one, and cost per completed task tracked as a first-class metric.

There is a longer-term uncertainty in all of this that pricing strategists have started raising. If the cost of serving intelligence keeps falling, the elaborate apparatus of usage and outcome pricing may be arriving just as the underlying service becomes cheap enough that the pricing complexity is not worth maintaining. Software has always been deflationary; this generation is unusually so. Buyers signing multi-year commitments on consumption pricing should think about whether they are locking in the current cost curve at tomorrow’s prices.

Lock-in reassessed under open protocols

The standard argument says open protocols reduce lock-in: any client can talk to any server, so switching costs fall. That argument is correct about the connectivity layer and wrong about everything else, and the surveyed evidence bears that out — analysis of enterprise agentic adoption in 2026 found 76% to 81% of surveyed organizations concerned about proprietary dependencies, concentrated specifically in agent memory, model integration and orchestration tooling. Those are exactly the layers the protocols do not standardize.

Break the stack into components and ask what switching each actually costs.

Models are the most portable. Swapping a provider behind a routing layer is a matter of days plus regression testing, and the main risk is behaviour differences that an evaluation suite catches. This is why model vendors are pushing so hard into workspaces and administration consoles: the reasoning layer alone is not defensible.

Connectors are increasingly portable because of MCP. A server written for one client works with another. The residual cost is transport migration and re-authorization, which is real work but bounded.

Orchestration definitions are not portable. A workflow built in one vendor’s canvas does not export to another’s. When OpenAI announced in June 2026 that Agent Builder would leave the platform after 30 November 2026, every workflow built in it needed rebuilding elsewhere — an unusually clear demonstration of the risk, and a reminder that the vendor withdrawing a product is as likely a cause of forced migration as the customer choosing to leave.

Agent memory is not portable and is rarely discussed in procurement. Accumulated context about how an organization works, learned preferences, and history of prior interactions constitute value that lives in a vendor’s format. Nobody publishes an export path for it.

Identity and policy are the least portable of all. Rewiring every agent identity, conditional access policy, tool allowlist and audit integration to a different provider is a multi-quarter programme. This is the deepest moat in the stack and the reason identity incumbents hold the strongest position.

Evaluation suites and audit history carry switching cost that grows with time. A two-year audit trail in a vendor’s format is not something a regulated firm abandons casually.

The practical conclusion is to place lock-in deliberately rather than avoid it. Accept it where the switching cost is compensated by genuine advantage — identity and governance, plausibly, where a single provider integrated with everything is worth more than portability. Refuse it where alternatives exist: keep workflow definitions in a form you can read and rebuild, keep evaluation cases in your own repository rather than a vendor’s, insist on an export path for logs, and prefer standard protocol connectivity over proprietary connectors even when the proprietary one is slightly better.

Two contract terms are worth negotiating specifically and rarely are. First, an export right covering workflow definitions, evaluation data, memory content and audit logs in a documented format, with a defined window after termination during which it can be exercised. Second, a model version commitment — which versions are available, how long before deprecation, and what notice is given — because uncontrolled model changes are the most common source of unplanned rework.

The competitive pattern worth watching is that the vendors most confident about their position are the most willing to support open protocols, since standard connectivity increases the value of their governance layer without threatening it. Vendors that resist standard protocols are usually defending a connector business that the protocols have already commoditized.

Build, buy or assemble

The decision most organizations actually face is not build versus buy but how much to assemble, and the answer varies by component rather than by organization.

Buy the identity and governance layer. Building agent identity, conditional access, audit trails and policy enforcement is a security engineering project that competes directly with the identity vendors’ core competence, and doing it badly is worse than not doing it. Any organization already committed to an identity provider should use that provider’s agent capabilities unless there is a specific reason not to.

Buy connectors, build the ones that matter. Published MCP servers exist for common systems, and the registry contains thousands. For internal systems and for anything where the exposed operations need to be narrow and purpose-specific for data-minimization reasons, build. The rule of thumb that holds: buy where the system is standard, build where the semantics are yours.

Assemble the orchestration. This is the layer where organizations retain the most benefit from doing the work, because the workflow logic encodes how the business actually operates and that is not something a vendor knows. Assembly means composing a runtime, a policy layer, connectors and models rather than either writing everything or configuring one product.

Build the evaluation suite. Nobody else knows what correct looks like for your workflows. This is the highest-return internal investment in the whole programme and consistently the most neglected.

Buy observability, own the record. Use tooling for tracing and cost attribution, but ensure the audit record is captured in a form you control and can export, for the reasons the regulatory sections set out.

The choice of a primary platform should follow data gravity rather than feature comparison. If most of the relevant data lives in one vendor’s systems, the agents that work on that data belong there, because native permission inheritance and context are worth more than any feature difference. If data is genuinely distributed with no dominant location, neutrality matters more and an independent orchestrator becomes the better base — accepting that governance may then come from a separate control plane.

Three anti-patterns are worth naming because they recur.

The first is platform-first selection: choosing an orchestration vendor before identifying which workflows will run on it. This produces a licence, a centre of excellence, and a search for problems to solve. Gartner’s read on agentic project cancellations points at precisely this — projects driven by hype rather than by a use case, with costs and complexity discovered later.

The second is agent-washing internally: labelling a deterministic workflow as agentic to secure budget, then paying model costs and accepting model unreliability for something a scheduled job would have done more cheaply and correctly. The triage question is whether the task requires a decision that cannot be enumerated in advance. If it can be enumerated, write the rules.

The third is governance as phase two. Every organization that deferred identity, audit and cost controls until after the pilot succeeded ended up rebuilding, because the pilot’s architecture had no place to put them. The cheapest sequence is governance scaffolding first with one narrow workflow inside it, then expansion.

A staged adoption path for a mid-sized company

Most published guidance on this subject is written for organizations with a platform team and a security function. The harder case is a company of 200 to 2,000 people with a small IT group, a heterogeneous application estate and no capacity for a multi-quarter programme. A workable sequence for that company looks like this, and the ordering is deliberate.

Weeks one to three, inventory. Find out what already exists. Which assistants and agents are connected to company systems, who connected them, what they can reach, and under whose credentials. In most organizations this discovery produces surprises, because productivity tools let any member add connections. Include browser extensions, coding assistants with repository access, and anything running on a scheduled basis. This step needs no purchase and produces the risk register that justifies everything after it.

Weeks two to four, identity foundation. Decide the rule for agent identity — one identity per agent, named human owner, defined scope, expiry date — and apply it to what already exists before adding anything. If the identity provider supports agent identities, enable them. If not, at minimum eliminate shared service accounts and document which credentials each agent uses. Nothing else in the programme is safe without this.

Weeks three to six, pick one workflow and measure it. Choose a workflow that is high-volume, cross-system, disliked by the people doing it, and correctable if wrong. Good candidates: invoice exception handling, support ticket triage and enrichment, onboarding document collection, monthly reporting assembly. Bad candidates: anything customer-facing in real time, anything irreversible, anything where correctness is contested. Record the baseline for four weeks — cycle time, error rate, volume, staff hours — before touching it. This is the step most organizations skip and the one that determines whether the programme can ever demonstrate a result.

Weeks five to nine, build the narrow version. Deterministic scaffolding, model decisions at specific points, read access broad and write access enumerated, human approval on anything with financial consequence, full logging from day one. Use existing MCP servers for standard systems. Keep the chain short — one agent with several tools beats several agents passing messages at this scale.

Weeks eight to twelve, evaluate honestly. Build a case set of thirty to fifty real examples with known correct outcomes and run it. Measure against the baseline. Calculate the total cost including consumption, not just the licence. Then make an explicit decision to expand, adjust or stop, with the finance function present for the cost conversation.

Months four to six, generalize the platform, not the workflow. The reusable output of the first project is the scaffolding: identity pattern, connector inventory, approval mechanism, logging format, evaluation suite, cost attribution. The second workflow should take a third of the time of the first. If it does not, the first project built a workflow rather than a platform, and that is worth correcting before the third.

Budget honestly. The licence cost is the visible part and often the smaller part. Consumption at production volume, the internal time for inventory and evaluation, and the governance licensing — Microsoft’s per-user pricing for agent security capabilities is charged against human users regardless of how many agents run — together typically exceed the platform cost in year one.

Two organizational commitments make the difference between programmes that continue and programmes that quietly stop. A named owner for each agent, accountable for its behaviour and cost, so that a problem has an address. And a standing decision point where the programme can be stopped on evidence, which sounds pessimistic and is actually what allows the organization to take a risk in the first place. Projects that cannot be cancelled do not get approved; projects with a defined kill criterion do.

The realistic expectation on returns: the first workflow rarely pays for the programme. It pays for the scaffolding. The economics improve from the second workflow onward because the fixed cost is already spent, which is exactly why abandoning after one disappointing pilot is the most expensive possible outcome.

Competitive advantage when features stop being scarce

The strategic question underneath all of this is what a software company defends when features are cheap to build and easy to copy. Three answers hold up under examination and one popular answer does not.

Distribution holds. Being present where work already happens beats being better in a place users must go to. Microsoft’s advantage is distribution expressed as an identity relationship and a purchasing relationship. Model vendors’ pursuit of workspace surfaces is a distribution play. Retailers worrying about agent-mediated discovery are worrying about distribution. The consistent pattern: whoever is invoked by default wins volume, and volume compounds through data.

Governed context holds. Knowing what things mean inside a specific organization — which entities relate to which, what the current status is, who is accountable, which document is authoritative — cannot be replicated by a competitor who does not hold the data. Microsoft’s tenant context, Salesforce’s data model, ServiceNow’s process model and an analytical platform’s semantic layer are all versions of this asset. It is durable because it accumulates rather than being built.

Trust infrastructure holds. Identity, permissions, audit trails and the accumulated evidence of correct operation are switching costs that grow with time and are demanded by regulators rather than by product managers. This is the least glamorous asset and the strongest one.

Feature superiority does not hold. A better interface for a specific task is worth less when the task is increasingly performed by an agent that does not use interfaces. This is uncomfortable for a large share of the software industry, whose product differentiation is precisely a better interface for a specific task.

The consequence for companies whose product is a system of record is a genuine strategic fork. One path is to become excellent infrastructure — expose complete, well-described, permission-aware capabilities so that orchestration layers reach for you first, accept that users rarely see your interface, and compete on reliability, data quality and depth of operations. That is a viable business and it is closer to a database company than to an application company. The other path is to become an orchestration layer within a defined domain, which requires holding the context and permissions for that domain and is only available to companies that already own the relevant data.

The path that fails is the middle: staying an application with a good interface while an orchestration layer intermediates the relationship with the user. That company keeps its data, loses its interface traffic, becomes a line item in someone else’s platform decision, and discovers at renewal that the buyer is now managing a different variable.

For buyers, the same analysis inverts into a purchasing principle. Evaluate a vendor on how well it can be orchestrated, not only on how well it works alone. Concretely: does it publish a maintained MCP server or equivalent; are the exposed operations narrow enough to grant precisely; does permission enforcement happen at the source rather than at the connector; can actions taken through the interface be attributed to the acting principal in the vendor’s own audit log; and is there an export path for data and history. A vendor that scores well on these is one you can build on. A vendor that scores badly is one you will eventually replace, whatever its feature list says.

Scenarios to 2028 and the signals worth watching

Forecasting this market precisely is not possible, but the range of plausible outcomes is narrower than the volume of commentary suggests, and the signals that distinguish between them are observable.

Scenario one, the governance plane consolidates. Identity-anchored control planes become the standard purchase, agents are governed centrally regardless of where they were built, and the orchestration execution market fragments beneath a small number of governance vendors. This is the outcome Microsoft is building towards and the one current momentum favours. The signals confirming it: enterprises buying agent governance as a suite upgrade rather than a point purchase, ServiceNow’s control tower and Microsoft’s control plane being deployed together with a clear division rather than competing, and identity providers reporting agent identity as a growth line.

Scenario two, the domain platforms hold. Native context and permission inheritance prove worth more than central governance, and enterprises run agents inside their systems of record with lightweight cross-platform oversight. The signals: CRM and workflow vendors reporting that customers prefer native agents over externally orchestrated ones, and cross-platform governance products showing weak attachment rates in accounts that have a dominant application vendor.

Scenario three, the neutral layer wins the middle market. Companies with genuinely distributed estates and data sovereignty requirements standardize on independent orchestrators, and the segment consolidates around two or three vendors with strategic backing from the large application companies. SAP’s stake in n8n is evidence for this path. The signals: continued upward funding for independents, more strategic investments by application vendors rather than acquisitions, and self-hosting appearing as a requirement in European tenders.

Scenario four, a security event resets the timeline. A major breach traced to a compromised orchestration layer or a poisoned tool triggers procurement freezes and regulatory attention, delaying write-capable deployments by a year or more while gateway and verification controls mature. Given the documented state of MCP server security — over 30% of surveyed servers with at least one exploitable vulnerability, agents following injected instructions in roughly half of tested scenarios, and a disclosure describing up to 200,000 vulnerable instances — this is not a tail risk. The signals: any incident with a named enterprise victim, insurance carriers adding exclusions for autonomous agent actions, or a supervisory authority issuing specific guidance on agent write access.

These are not mutually exclusive. The most likely composite is scenarios one and three coexisting by segment, with scenario four compressing timelines somewhere along the way.

The forecasts worth tracking against reality, with appropriate scepticism about all of them: Gartner’s expectation that 40% of enterprise applications embed task-specific agents by the end of 2026, up from around 5% in 2025; that a third of enterprise software applications embed agentic capability by 2028; that roughly 15% of day-to-day work decisions are made autonomously by 2028; and that more than 40% of agentic projects are cancelled by the end of 2027. Note that the last of these is compatible with all the others — a market can see rapid embedding of agent features alongside a high cancellation rate for ambitious agentic projects, because those describe different things.

Three specific dates on the calendar shape the next eighteen months for anyone operating in Europe. 2 December 2026 brings the watermarking obligation for systems already on the market and the new prohibition on generating non-consensual intimate imagery and abuse material. 2 December 2027 brings the deferred high-risk obligations for Annex III systems. 2 August 2028 brings them for AI embedded in regulated products. The NIST agent interoperability profile expected around the fourth quarter of 2026 will shape procurement language in the United States, and the first designations of critical ICT third-party providers under DORA during 2026 will tell European financial institutions which of their AI dependencies come under direct supervisory oversight.

The single most informative signal to watch is mundane: whether write-capable agent deployments grow. Read-only agents are widespread and low-risk. The commercial thesis of this entire shift depends on agents that change things in systems of record, and every serious constraint discussed here — identity, injection, audit, liability, insurance — is a constraint on writing rather than reading. If write deployment keeps growing through 2027, the orchestration thesis is confirmed. If it stalls while read-only usage keeps climbing, the market has settled for a substantially less lucrative outcome than the current valuations assume.

Questions the current evidence cannot settle

Honest analysis ends by marking what remains unknown, and several of these questions are load-bearing for anyone making a large commitment.

Whether prompt injection is tractable. Every mitigation currently deployed reduces probability rather than eliminating the class. Nobody has demonstrated an architecture where an agent reads untrusted content and cannot be redirected by it. If this turns out to be irreducible, the ceiling on autonomous write access is lower than the market currently assumes, and the long-run architecture involves narrow, verified, deterministic action paths rather than general-purpose agents with broad tool access.

Who is liable when an orchestrated action causes loss. The platform vendor, the model provider, the connector author, the deploying company, or the human who approved a batch of actions without reading them individually. Contract terms are silent, case law is absent, and insurance products are early. This will be settled by litigation or by regulation, and until it is, conservative organizations are correct to keep humans on decisions with real exposure.

Whether adoption figures reflect production or experimentation. The gap between a defensible 41% of software organizations in some production use and widely repeated claims near 78% is not a rounding difference. Anyone building a business case should note that the market’s own view of its adoption is uncertain, and that vendors have incentives in one direction.

Whether outcome pricing generalizes. It works where the unit of value is measurable and disputes are rare — a support resolution, a completed transaction. It is unclear how it applies to work where the outcome is a judgment, a document, or a decision not to act. If it does not generalize, the pricing transition stalls at usage-based and the alignment argument weakens.

Whether cross-organization agent coordination reaches real volume. The protocol work is done and the legal groundwork is not. Signed agent cards solve authentication; they do not solve which party’s contract governs an automated task, what logging each side retains, or how a dispute about an automated decision resolves. Absent that, this stays inside pre-negotiated partnerships.

Whether the cost curve undermines the business model. If serving intelligence gets dramatically cheaper, the elaborate metering apparatus being built now may become unnecessary, and the pricing power that vendors are constructing may erode faster than the moats they are building around it.

Whether governance discipline scales to the agent population. Projections of agents outnumbering employees by orders of magnitude are incompatible with per-agent human review as currently practised. Either the review becomes automated — which requires trusting an automated system to govern automated systems — or the population grows more slowly than forecast. Both outcomes are plausible and they imply very different markets.

None of these uncertainties argue for waiting. They argue for building the parts that are useful under every scenario — inventory, identity, evaluation, audit, measured baselines — and deferring commitments that only pay off if a specific scenario holds.

Practical questions about orchestration layers, agent protocols and platform strategy

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

Microsoft Agent 365, the control plane for AI agents Microsoft’s own introduction of Agent 365, covering the agent registry, Entra Agent IDs, Work IQ access and the third-party and open-source agent ecosystem it governs.

Microsoft Agent 365 product page Current product documentation describing identity protection through Entra, threat protection through Defender and data compliance through Purview for managed agents.

Work IQ, Microsoft IQ and Agent 365 as the enterprise context layer Independent implementation analysis establishing the general availability dates for Agent 365 and Work IQ and the governance work required before enabling tenant-wide agent context.

Securing AI agents as tools move from reading to acting Microsoft security research mapping observed attacks against enterprise agents to OWASP agentic categories, with the vendor invoice scenario as a worked example and IDC agent population projections.

Everything your team needs to know about MCP in 2026 Technical overview of MCP architecture, authorization history across specification revisions, governance under the Agentic AI Foundation and the practical limits of the protocol.

MCP adoption statistics for 2026 Source-checked adoption figures including the official registry pull, GitHub topic counts and the Stacklok production-use survey, with explicit correction of previously circulated unsourced claims.

MCP adds an enterprise authorization layer Reporting on the authorization progression from OAuth 2.1 through resource indicators to client ID metadata documents, the 2026 roadmap priorities and the MCP Dev Summit enterprise track.

The Model Context Protocol and enterprise tool orchestration Peer-reviewed analysis of permission manifest architecture and tool orchestration governance, noting that the specification addresses connectivity while leaving governance undefined.

MCP security crisis and systemic design flaws in agent infrastructure Cloud Security Alliance research note cataloguing confirmed CVEs across MCP-integrated platforms, optional authorization in the specification and internet-exposed unauthenticated instances.

MCPTox, a benchmark for tool poisoning attacks on real-world MCP servers The benchmark paper behind the finding that strong commercial agents follow injected instructions in roughly half of tool-output attack scenarios, across 312 scenarios and 14 vulnerability classes.

Systematic analysis of MCP security Survey of more than 1,800 deployed MCP servers reporting that over 30% contained at least one exploitable vulnerability.

Are AI-assisted development tools immune to prompt injection Empirical comparison of tool-poisoning resistance across seven widely used MCP clients, showing wide variation in guardrail quality and demonstrated credential theft and phishing paths.

Linux Foundation launches the Agent2Agent protocol project The announcement establishing vendor-neutral governance for A2A after Google transferred the specification and SDKs.

A2A protocol specification and documentation Primary reference for agent cards, task lifecycle, transport bindings and the security schemes declared for cross-organizational agent communication.

Okta introduces Cross App Access to secure AI agents Original announcement of the OAuth extension bringing agent-to-app and app-to-app authorization under identity provider control.

Okta expands the Cross App Access ecosystem Update covering incorporation of XAA as an official MCP authorization extension, the Anthropic customer beta with HubSpot, Ramp and Webflow, and availability timelines.

Introducing AgentKit OpenAI’s agent tooling announcement, including the June 2026 update confirming the wind-down of Agent Builder and its evaluation product after 30 November 2026.

The next evolution of the Agents SDK Documentation of the sandboxed execution environment for long-horizon agent work across files and tools.

Introducing apps in ChatGPT and the Apps SDK The launch of third-party applications inside a chat surface, with subsequent extension to business and enterprise customers.

Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027 The primary source for the cancellation forecast, its stated causes and the recommendation to separate agent, automation and assistant use cases.

Who will control the enterprise agentic workforce Analyst comparison of Microsoft, Salesforce, ServiceNow, AWS and Google strategies for the enterprise agent control plane, based on 2026 CIO survey data.

EU AI Act omnibus agreement and postponed high-risk deadlines Legal analysis of the amended application dates for Annex III and Annex I high-risk systems and the new prohibition added to Article 5.

EU AI Act timeline relief, targeted simplification and new prohibitions Summary of the provisional agreement reached on 7 May 2026 and the staggered deferral structure agreed by the co-legislators.

The Digital Omnibus on AI and its effect on compliance roadmaps Analysis of the original Commission proposal, including the conditional delay mechanism and long-stop application dates.

The August 2026 high-risk deadline moved and what still comes due Practitioner reading of the final approval sequence and the argument that the deferral extends time for scope classification rather than removing the obligation.

DORA compliance requirements explained Reference on the five DORA pillars, the register of information filing requirement and the interaction with AI Act Article 9(10) for unified risk management.

DORA third-party risk for AI and what providers must show Analysis of critical ICT third-party designation under Article 31 and the per-request operational records expected during a supervisory inspection.

Building DORA compliance for banking AI agents Practical control mapping covering governed agent inventory, data lineage for audit trails, classification metadata and named accountability.

Agentic payments protocols compared Layer-by-layer comparison of ACP, AP2, x402 and the Machine Payments Protocol, including the Instant Checkout launch and subsequent pivot.

Agentic commerce standards for merchants Merchant-facing analysis of how UCP, ACP and AP2 stack, the FIDO Alliance transfer of AP2 and the unresolved status of previously published fee terms.

SAP backs n8n at a $5.2 billion valuation Reporting on the strategic investment, n8n’s integration breadth, multi-agent orchestration positioning and data sovereignty focus.

SAP invests in n8n, doubling its valuation Coverage confirming the valuation step from the October 2025 round and the wider set of SAP AI investments announced alongside it.

MCP connections for Notion custom agents Vendor documentation showing per-tool confirmation policies, credential inheritance behaviour and the distinction between native integrations and member-added MCP servers.

AI and the SaaS industry in 2026 Market analysis of application counts per organization, the coexistence of consolidation and vertical fragmentation, and the movement of pricing towards consumption and outcome models.

SaaS and AI agents in Deloitte’s technology predictions Forecast of software evolving towards federated real-time workflow services, with subscription and seat licensing giving way to hybrid usage and outcome pricing.

The decline of per-seat pricing Case analysis of outcome pricing in practice, including resolution rates, the April 2026 broadening of billable events and the reported net revenue retention effect.