Microsoft Build 2026 produced two announcements that, read together, describe something more interesting than the usual conference launch cadence: a plausible scenario in which enterprise AI stack decisions made in the next 12 months could become significantly harder to reverse. The operative word is "could". Several pieces of the announced architecture are not fully shipping yet. But the direction is clear.

The News

Microsoft delivered two related announcements at Build 2026.

The first came from Jay Parikh, EVP of CoreAI: the model is not the differentiator; the system governing it is. Microsoft's answer is a six-step loop. Agents are built in GitHub, contextualized with Microsoft IQ, which grounds them in enterprise data from Microsoft 365, core business systems, knowledge bases, and the web, run in Foundry, governed via Agent 365, and continuously improved through a hill-climbing optimization cycle. Agent 365, combined with Entra, Purview, and Defender, catalogues every agent in the estate, regardless of where it was built, and lets IT enforce policy across all of them.

The second came from Mustafa Suleyman, CEO of Microsoft AI: seven new MAI models built from scratch, with no distillation from third-party models. MAI-Thinking-1, the flagship reasoning model at 35 billion active parameters, benchmarks at parity with Anthropic's Claude Sonnet 4.6 on software engineering tasks at significantly lower per-token cost. MAI-Code-1-Flash is integrated natively into GitHub Copilot. MAI-Transcribe-1.5 claims leading accuracy across 43 languages at five times the speed of competing models. Image and voice models complete the family.

Alongside the models, Microsoft introduced Frontier Tuning: enterprises can train MAI models on their own workflow data using reinforcement learning environments. The model stays in the customer's Azure tenant, is trained on their operational traces, and owned by them. Microsoft's cited example: a model tuned to McKinsey's standards matched GPT-5.5 performance at roughly ten times lower cost.

The Bigger Picture

These announcements arrive midway through one of the more competitive contests in enterprise software: the race to become the orchestration layer for AI agents at scale.

Every major platform vendor has staked a claim. Salesforce closed its Q1 2027 with Agentforce at more than $1.2 billion ARR, up 205% year-over-year. ServiceNow repositioned at Knowledge 2026 as the AI Control Tower for Business Reinvention, an orchestration layer governing every agent, model, and action across the enterprise regardless of origin. SAP's Sapphire 2026 introduced the Autonomous Enterprise vision, with Joule orchestrating more than 200 agents across finance, procurement, supply chain, HCM, and CX. I wrote about this before here and here. Futurum Research, assessing the field days after Build 2026, identified Microsoft, Salesforce, and ServiceNow as the three early leaders, with orchestration and governance increasingly determining who wins.

The contest runs on two battlegrounds: interface control, which platform surfaces agents to users, and orchestration, which layer coordinates agents across systems and governs their behavior. Microsoft's Build 2026 argument is that it holds the strongest hand on both, because of one asset its competitors lack at the same scale: identity infrastructure. Azure runs in 95% of Fortune 500 environments. Entra is already the identity backbone across those estates. Governance-by-default, because it runs at the identity layer, is architecturally stronger than governance bolted on afterward.

ServiceNow's counter is strong. Its AI Control Tower is explicitly vendor-agnostic, covering AWS, GCP, Azure, SAP, Oracle, and Workday from a single policy point. The acquisitions of Armis and Veza give it a capability to map AI agent identities alongside human identities in a unified access graph that most of the market lacks today. And it combines control plane arguments with domain knowledge. SAP takes a different position altogether by not claiming to be the identity layer, but the authoritative business context layer, with Anthropic's Claude embedded in Joule for reasoning across HR, procurement, and supply chain. In brief, SAP is all about domain knowledge.

In summary, there are 3 main camps. Vendors that say that the systems and domain knowledge are key, others that claim independence and the group that positions itself in between, claiming both capabilities.

The MAI model launch adds to the equation in two ways. Since April 2026, when Microsoft and OpenAI amended their partnership to end Microsoft's exclusive IP license, Microsoft has had the freedom to develop its own Azure models. Build 2026 marks the first major shipment of that strategy. And it puts a native model option inside a platform that already governs identity, compliance, and access, at benchmarked parity, and at lower cost. One analyst framed it sharply: Microsoft is not ending OpenAI's presence, it is making that presence look optional. The same shift applies to Anthropic.

My PoV and Analysis

The Frontier Tuning architecture is the most underappreciated part of the announcement. Microsoft's marketing says "no vendor lock-in" because your model weights stay in your tenant. That is technically correct and commercially misleading at the same time. A model trained on your institutional workflow traces, tuned to your decision patterns, is deeply embedded in your operational context. That makes it incredibly sticky, creating, you guess correctly, lock-in. Migration does not mean exporting a file; it means retraining from scratch on a different platform. For most enterprises, that cost never gets budgeted. None of that makes it a bad decision. Institutional specialization is precisely what makes the model valuable. But buyers should know what they are choosing. The McKinsey benchmark Microsoft cites is an interesting data point, but not an independently audited one.

The identity-layer governance argument is solid, with one qualification. Entra's governance of human identities is mature. Governance of AI agent identities, like service principals, managed identities, tool-calling permissions at multi-agent complexity, etc., is newer and less proven. Agent 365 is GA, but its depth against real multi-vendor agent estates running across Azure, GCP, and on-premise systems has not been tested at production scale. ServiceNow can fairly argue that its AI Control Tower, designed from the ground up for agent governance rather than extended from human identity management, is currently better suited to that specific problem.

The timing question is important, too. Salesforce has 29,000+ and growing Agentforce deals. ServiceNow is offering AI Control Tower free for a year as a market stimulus. SAP shipped Joule Work with MCP and Agent-to-Agent protocol support. These are platforms in production motion. Microsoft's architecture is more comprehensive than any single competitor, but in some of its more important pieces, it is still catching up on deployment velocity.

On the models: MAI-Thinking-1 at Sonnet 4.6 parity is strong, and building it without third-party distillation is importatnt for enterprise IP hygiene. But benchmarks are a snapshot. Anthropic has shipped Claude Opus 4.6, 4.7, and 4.8 since the start of 2026 alone. Parity today does not guarantee parity in six months. And it is parity to Anthropic’s mid-tier model.

What Build 2026 consolidates is a combined structural position no other titan holds: the identity layer, the developer platform, the productivity offerings, and now owned models across all primary modalities. SAP has process depth and models but not the identity layer. Salesforce has CRM data depth and interface momentum but no developer platform or owned models. ServiceNow has governance credibility and IT workflow depth but no productivity solution and no owned models. Microsoft now has all four.

Whether the Frontier Tuning plus identity governance combination creates the kind of enterprise AI commitment that changes stack consolidation decisions over the next 18 months is the open question. If it does, the most exposed competitors are ServiceNow, whose governance position gets squeezed by an identity-native argument, and the model vendors Anthropic and OpenAI, whose enterprise contracts require a deliberate additional procurement choice rather than sitting as the obvious default.

Neither is displaced. Both face a changed market dynamic.

The platform decision and the model decision used to be separable. They may not be for much longer.

What Google Cloud Next 2026 actually told us about the titan pecking order

Google Cloud Next 2026 wrapped last week. The official version of the story is the one Google wanted you to read: 260 announcements, 1,302 customer use cases, the Gemini Enterprise Agent Platform, eighth-generation TPUs, a $750 million partner fund, an $240 billion Marketplace backlog. Big numbers. On-message keynote. Tidy "agentic era" framing.

The more interesting story is who showed up to validate it, and what Google actually built underneath.

Five of the seven enterprise titans I track walked into Las Vegas and announced expanded partnerships that all rest on the same architecture: Gemini Enterprise as the agent control plane, with the titan's product playing the role of premium ingredient. Salesforce. SAP. ServiceNow. Oracle. Adobe. Add Workday and Palantir Technologies to the picture, both adjacent to my titan list but visibly aligned in the same direction.

Two titans were not in the picture. Microsoft, because Copilot is the direct counter-position and Cloud Next is not Microsoft's stage. Zoho, because Zoho's stack does not need a Google motion and Zoho's buyer is not the same buyer.

Both absences matter. More about them a little later.

What Google actually built

Let’s start with the framing. Google did not just ship a model platform with new features. It repositioned Google Cloud from "AI development environment" to enterprise agent control plane. Vertex AI services and roadmap evolutions are now delivered through the new Agent Platform rather than as a standalone product. That is not a naming change, it's an entirely different playground.

The Agent Platform stack now visibly includes:

• Agent Identity for cryptographically secure agent authentication
• Agent Registry as the catalog of every agent and MCP server in scope
• Agent Gateway for traffic control and screening
• Agent Observability for production monitoring
• Agent Simulation for pre-deployment testing
• Agent Evaluation for measurable performance against benchmarks
• Agent Runtime with sub-second cold start
• Agent Inbox for human oversight of long-running agents
• Agent Studio as the low-code builder
• Agent Development Kit (ADK) across Python, Go, Java, with TypeScript

Sitting alongside this is the new Knowledge Catalog, which aggregates native context from partner data platforms and applications including Salesforce Data360, SAP, ServiceNow, Workday, and Palantir into a single accessible layer for Gemini agents.

That layer matters. It is the third leg of the orchestration story alongside interface (Gemini Enterprise app, Slack, Workspace) and runtime (Agent Platform). And physics teaches us that a third leg creates stability.

The Agent Marketplace and Agent Gallery surface partner-built agents directly inside the Gemini Enterprise app, with an IT-driven request-and-approval governance model. Open protocols carry the connective tissue: A2A, A2UI, and MCP, all positioned as neutral interoperability standards rather than proprietary lock-in.

This is the playground Google built. It is not a naming change. It is Google trying to redraw the enterprise AI battlefield.

Not by owning the CRM.

Not by owning the ERP.

Not by owning ITSM, HCM, marketing automation, or the system of record.

But by embracing them all.

It is Google Cloud repositioning from “AI development platform” to enterprise agent control plane.

Now look at who joined this merry party.

The seven partnership announcements, decoded one by one.

Salesforce

Agentforce Sales is in open beta inside Gemini Enterprise. Slack hosts Gemini Enterprise as a private preview app. Agentforce gets native Gemini reasoning through Atlas Reasoning Engine, with multimodal support across text, image, and video. Zero-copy access to Google Lakehouse is on the late-2026 roadmap. New BigQuery connectors for Salesforce Informatica IDMC are available now. Pepkor reportedly consolidated 64 million customer profiles down to 24 million using Salesforce Data 360 plus BigQuery, a 25 percent personalization reach lift. The framing from Srini Tallapragada is "agentic interoperability".

The translation is simple: Salesforce is letting Google become a distribution and work-surface partner for Agentforce, while Salesforce keeps the customer-data gravity and Atlas Reasoning Engine. Slack is the part of the deal that helps Salesforce most. Google Workspace and Gemini Enterprise are too big to ignore. This move is consistent with the recently announced Headless 360.

The tension that nobody named on stage is nevertheless there. If a buyer ends up with Agentforce on one side and Gemini Enterprise on the other, who governs the agents, where do they run, and which vendor gets paid for the orchestration? That fight is coming. Get yourself some popcorn!

SAP

SAP's announcement was imo the most strategically interesting of the week, and worth having a deeper look.

SAP Business Data Cloud (BDC) Connect for Google enables bidirectional zero-copy data sharing between SAP and BigQuery. Cortex Framework metadata in BigQuery grounds Gemini agents in SAP enterprise context. Joule Agents in SAP CX become deployable inside Gemini Enterprise. SAP Engagement Cloud picks up agentic capabilities for content development, marketing briefs, visual concepts, and collaborative multi-agent execution. Marketing is the first GA use case in H2 2026, with the model designed to extend across the SAP CX portfolio over time.

The headline from SAP itself describes Gemini Enterprise as "central hub for data integrations and multi-agent coordination”. On the surface, that is a vendor conceding the orchestration layer.

It is not. Read it again.

SAP is not handing over the operational core. SAP is making sure the Gemini agents that buyers run cannot meaningfully execute against enterprise data without going through SAP's very own grounding layer. Cortex Framework metadata in BigQuery is the move that matters. It means the semantic context for "what a customer record actually means in this enterprise" runs on SAP's side. Google gets the AI execution layer. SAP gets to stay the meaning layer.

That is SAP looking stronger, not weaker. The friendly stage handshake is going to turn into a knife fight in the field about where business logic lives. SAP appears to have positioned itself well for that fight.

ServiceNow

ServiceNow AI Control Tower integrates with Gemini Enterprise Agent Platform so that every agent and MCP server across both platforms appears in a single governed registry. Now Assist for IT Operations Management is available through Gemini Enterprise, focused on alert and incident management. Joint solutions ship in three industry domains: 5G autonomous network operations, retail predictive maintenance, and IT systems, all using ServiceNow agents and Gemini agents handing off through MCP and A2A. ServiceNow took home four 2026 Google Cloud Partner of the Year awards, including Agentic AI Innovation.

John Aisien positioned the agreement as "open, interoperable platforms, not walled gardens”. This framing is doing real work, and it is also strategically necessary. ServiceNow is the workflow titan most directly in Google's strategic crosshairs. Both companies want to be the orchestration layer above all systems. This partnership smooths the surface. Still, the strategic overlap is significant.

ServiceNow's strongest argument remains: "We already run the workflows, approvals, incidents, assets, service models, and operational context. Don't bolt orchestration on top. Run it where the work already lives". Google's counter is: "We can orchestrate across all of you, including ServiceNow". Both arguments are valid, and both are strong. Buyers will pick based on what they value more, neutrality across systems or depth inside the workflow platform that already governs work.

Partners today. Rival underneath. Both are true.

Oracle

Oracle's announcements were broader than the Database Agent that most coverage led with. The full set: Oracle AI Database Agent for Gemini Enterprise (currently in preview on Google Cloud Marketplace), a Managed MCP Server for Oracle workloads (also in preview), Database Center integration, Knowledge Catalog integration, GoldenGate integration, VPC Service Controls. Oracle AI Database@Google Cloud is now available across 15 regions with more to come.

Business users can query Oracle data in natural language without writing SQL. Identity propagates from Gemini Enterprise to the database via OAuth. Oracle's Deep Data Security enforces row- and column-level access at the database layer. Query processing stays inside the database, which Oracle frames as a security and latency benefit, and which has the side effect of keeping Oracle's data gravity intact.

Oracle is doing what Oracle has always done well. Make sure its database estate is unavoidable. Give Google enough access that the partnership is real. Do not pretend Oracle is going to own the AI front end. The Managed MCP Server, Knowledge Catalog hookup, Database Center, and GoldenGate pieces all point in the same direction: Oracle data stays central to AI execution regardless of where the agents are built; and the data stays in Oracle.

The database does not need applause. It needs to remain indispensable. Mission accomplished, I'd say.

Adobe

Adobe Marketing Agent for Gemini Enterprise lands in Google’s Agent Gallery. It connects natural language queries to Adobe's CX agentic capabilities, with insights on campaign performance, audiences, and journey monitoring, accessible from inside Gemini Enterprise. The integration is more lightweight than the others, which is consistent with Adobe's pattern.

Adobe benefits from showing up in the Gemini work surface, especially when marketing teams already live and breathe inside Workspace and Slack. But this is a distribution play, not a control-layer move on the level of SAP, Salesforce, Oracle, or ServiceNow. Adobe joins the gallery without conceding much architecturally and without claiming a piece of the orchestration plane. This is consistent with the Adobe Summit messaging.

Workday

Workday shows up through the Sana Self-Service Agent, which summarizes information from Workday and other sources and handles HR and finance tasks across hundreds of skills covering pay, time, and absence. Workday is also part of the Knowledge Catalog third-party context aggregation.

Workday is playing the employee-service and finance/HR productivity angle. It’s useful, sticky, high-volume in daily user activity. Compared with SAP and ServiceNow, it is narrower in operational control. Compared with Adobe, it is comparable in scope. Workday had a solid presence at this event, not a strategic re-positioning.

Palantir

Google says that Palantir is adding Gemini and BigQuery integrations for commercial customers, connecting models to critical AI workflows and operations. Palantir is also part of the Knowledge Catalog third-party context aggregation.

Palantir is the awkward guest at the titan table. It’s not a classic business application vendor but increasingly competing at the operational decision layer with Foundry and AIP. Google wants Palantir workloads close to BigQuery and Gemini. Palantir wants model optionality without losing AIP control. The integration is real and worth tracking precisely because Palantir does not usually settle for being an ingredient.

The pecking order this event produced

Most strategically advantaged: Google Cloud. It created the playground. The full agent control plane (Identity, Registry, Gateway, Observability, Simulation, Evaluation), the Knowledge Catalog, and the Marketplace make Google the layer everyone else runs on. Google’s risk is that it wants to be the enterprise control plane without owning the transactional cores that SAP, Salesforce, Oracle, ServiceNow, and Workday control. That requires relentless execution, not keynote poetry.

Most durable titan: SAP. SAP owns the operational core. The combination of BDC Connect and Cortex Framework gives SAP a stronger bridge into Google's AI without surrendering enterprise meaning. SAP's posture is "use Google's AI, but ground it in SAP business truth". That is the right defense and a subtle offense at the same time.

Most interesting tension: Salesforce. There's a great integration story today. The unresolved question is whether Agentforce and Gemini Enterprise will eventually compete for governance and orchestration once buyers are running both in production. And they will. Procurement will notice when both vendors invoice for the same workflow.

Most direct control-plane rival: ServiceNow. A visible partner. And an architectural competitor. The "open, interoperable" framing is correct in principle, and it is also the terminology a vendor uses when its core product overlaps strategically with the platform it just partnered with. The deciding factor for buyers is whether they want a neutral AI control plane above systems, or agentic execution inside the workflow platform that already governs work.

Most pragmatic: Oracle. No applause needed. The database stays indispensable. Managed MCP Server, GoldenGate, Knowledge Catalog hookup, VPC Service Controls all point in the right direction for Oracle. That’s pragmatic, and dangerous in the right way.

Useful but narrower: Adobe and Workday. Both gain Gemini Enterprise distribution reach. Neither announcement changes their strategic center of gravity. There is nothing earthshattering about them. They are domain wins, not control-plane bids.

Adjacent: Palantir. This is worth watching specifically because Palantir does not usually accept ingredient status.

The two missing names

Microsoft. Copilot exists exactly to defend the position Google is now contesting. Microsoft has spent two years building Copilot Studio, Microsoft 365 Copilot, Dynamics 365 agents, and an Azure-side AI tooling that competes head-on with what Google just announced. Microsoft was never going to show up at Cloud Next to validate Gemini Enterprise. Why would it?

The more interesting question is whether Salesforce, SAP, ServiceNow, and Oracle agents will sit as comfortably inside Copilot in twelve months as they now do inside Gemini Enterprise. Right now, the answer is no, and the gap appears to be widening. I expect Microsoft to respond at Build and Ignite. The main question then is whether the response will be "we have parity" or "we are bigger and we will route around you”.

Zoho works a different market segment. Zoho also builds its own AI stack. The company rarely participates in this kind of big vendor partnership theater. The absence is consistent and not so interesting when looked at in isolation. It becomes interesting, however, when paired with the observation that Zoho's mid-market and SMB-plus customers are largely outside the buying pattern Cloud Next 2026 is shaping. Two different conversations happening in two different rooms.

Open protocols, not walled gardens. Maybe.

I want to be careful about reading the "open, interoperable" framing.

A2A, A2UI, and MCP are all real, and they matter. ServiceNow's positioning is correct in principle. Salesforce kept Slack. Oracle kept the database. SAP kept Joule as the engagement layer in SAP applications. Adobe kept its CX stack untouched. Workday kept HR. Palantir kept AIP. None of these vendors handed over the asset they care most about.

But the registry is Google's. The gateway is Google's. The gallery, the runtime, the inbox, the identity model, the agent governance plane: all Google. Open protocols are not the same thing as a neutral platform. They are the price of admission to a platform that acts as a host.

The real question for the next twelve months is whether the protocols stay open enough that buyers can swap the host. If a customer can take A2A-compliant agents built around Gemini Enterprise and re-host them on Copilot Studio or AWS Bedrock AgentCore without rewriting most of the orchestration, the open framing holds. If swapping costs are high in practice, "open" is doing marketing work that the architecture does not back up.

I do not yet have any evidence either way. I expect to in the next two quarters with the first multi-vendor pilots moving into production.

What buyers should do this quarter

Force each titan to defend the front door. Salesforce will say Slack and Agentforce. SAP will say Engagement Cloud and Joule. ServiceNow will say ServiceNow. Microsoft will say Copilot. Google will say Gemini Enterprise. Make them defend the answer with specific cross-system workflows for agentic work. Note which vendor accepts being an ingredient in someone else's interface and which one fights for the seat.

Pin down the dates on zero-copy commitments. The Salesforce zero-copy with Google Lakehouse is late 2026. SAP BDC Connect is rolling out across 2026. Oracle's Managed MCP Server is in preview. Most of the headline-friendly capabilities are not in your tenant today. Build your 2026 plan around what you can run by Q3, not what is on a slide.

If you are a Microsoft shop, run a parallel evaluation. Bring in Copilot Studio. Ask whether Salesforce, SAP, and ServiceNow agents are first-class citizens inside it at the depth that Cloud Next demonstrated for Gemini Enterprise. Force Microsoft to demonstrate parity, not promises.

Treat the Agent Marketplace and Agent Gallery as procurement infrastructure. If your IT team adopts Gemini Enterprise as the agent procurement layer, that decision shapes which titans show up first in your future RFPs. Make this choice deliberately.

Test the governance question before you buy. If you end up with Agentforce, Joule, Now Assist, and a Gemini-Enterprise-built custom agent all running for the same business process, who governs them? Procurement will notice when you are paying twice for orchestration. Make a vendor own the answer in writing, and see to it that the SKUs do not overlap too much.

The unspoken partnership

The most interesting partnership at Next 2026 was the one nobody put in a press release. Five of seven titans, plus Workday and Palantir, plus a long list of consulting firms and ISVs, are all visibly aligning to ensure that Microsoft Copilot is not the only place enterprise AI gets done. None of them said that. All of their actions imply it.

That is the alliance worth watching.

I am still skeptical about how durable this alignment is once Microsoft responds, and buyer realities surface in the second half of 2026, and once we see what "open protocol" really means in production. All vendors will optimize for their own positions. They always do, and they need to. The orchestration question may stay answered for a year, or it may reopen the moment someone like Microsoft offers a credible alternative.

For now, Gemini Enterprise has the momentum. The titans showed up. The protocols are public. The Marketplace is live. The control-plane components are named. Google moved from "another model vendor" to "the agentic substrate the application titans run inside of”.

This is a very different conversation than the one we were having last year. It’s worth paying close attention to how it evolves and whether it is the right one.

Three titan announcements in two weeks reveal what enterprise software vendors are actually fighting over in 2026, and it is not agents.

If you have been tracking enterprise AI announcements through 2025, you have been watching a race about agent counts. How many prebuilt agents. How many industry-specific use cases. How many customer stories. Agents were the marketing, the demo, the SKU. A year of the same playbook.

Something shifted in April 2026.

Inside a two-week window, Salesforce, SAP, and ServiceNow each published an announcement that, at first glance, looks like more of the same agent theater. Salesforce launched Headless 360 at TDX 2026 and the Agentforce Experience Layer. SAP pushed a simplified-architecture argument alongside a persistent agent memory layer on BTP. ServiceNow rolled out Context Engine and, on its SPM community blog, Fred Champlain published an essay reframing governance itself as "strategic decision debt”.

Different products. Different audiences. The same structural move.

All three titans just walked one layer down the stack.

Read individually, each announcement is a product release. Read together, they are a category shift. The competition is no longer about who has the best agent. It is about who owns the substrate those agents operate on. And each titan is staking a different piece of it.

The Pattern Nobody Is Naming

Strip the vendor branding from all three sets of material and the structural claim is identical:

“Your agents are only as good as the layer underneath them. The data they ground on, the logic they inherit, the memory they carry, the permissions they respect, and the decisions they represent. That layer is what we sell.”

These three vendors are by no means the only ones making this shift. They just did it in a remarkably short period, and on stages loud enough to frame the category.

The pitch is more sophisticated than the 2025 version. Agent count was a volume game, easy to parody and easy to commoditize once every vendor had a hundred prebuilt agents. Substrate is harder to commoditize, harder to rip out, and (not surprisingly) easier to price at a premium once customers have built architectural dependencies on it.

Each titan is claiming a different piece of the substrate. None of the claims overlap cleanly. All of them expand the vendor's footprint.

Salesforce: The Interface and Intent Layer

Salesforce made the boldest move. Headless 360 exposes every platform capability as API, MCP tool, or CLI command, which means external coding agents (Claude Code, Cursor, Codex, Windsurf) get live access to an org's data, workflows, and business logic. Agentforce Vibes 2.0 ships with open agent harnesses supporting both Anthropic and OpenAI SDKs. Developers no longer need to work inside Salesforce's own IDE.

Is the new? Not quite; API-first architectures exist for quite some time. And they are a best practice.

However!

The accompanying Agentforce Experience Layer (AXL) is the delivery side. Build logic once in Salesforce. Deliver the same agent response into Slack, Teams, mobile, ChatGPT, WhatsApp, a customer portal, or any third-party surface, with the UI rendering automatically adapted to each channel. Permissions inherit from the Salesforce platform.

This part is new.

The subtext is the real story. For twenty-seven years, Salesforce's primary interface was the browser. Headless 360 is an explicit statement that the browser has become optional. VentureBeat's framing of the Salesforce answer to "does a company still need a CRM with a graphical interface?" was a blunt no, and that is exactly the point. Joe Inzerillo, Salesforce's president of enterprise and AI technology, said Headless 360 lets agents operate directly on the platform's business logic and datasets "rather than relying on separate integrations or user interfaces”. Read together, Salesforce is telling buyers it wants to remain the system underneath, even when the user never opens a Salesforce tab.

Not everyone loves it. The "Context, Work, Agency, Engagement" framing can create the ultimate vendor lock-in architecture, and the pricing is conspicuously silent. Headless 360 is included in platform licenses today. That is a statement about today. Salesforce's historical pattern is to introduce capability in the base tier and later wrap premium SKUs around it. CIOs should be asking the pricing question before making the architectural commitment.

SAP: The Data and Process-of-Record Layer

SAP is running a different play. It is not trying to be the interface layer. It is trying to be the gravity well.

The simplified-architecture argument is a rejection of the 2024 playbook, which basically said: sprinkle Joule on top of S/4 and be AI-ready. The current SAP pitch, across the Clean Core guidance, the Reltio acquisition, the Business Data Cloud strategy, the SAP-RPT-1 foundation model for structured data, and the new agent memory layer on BTP, is a single argument: your AI is only as trustworthy as the ERP data underneath it, and most of the world's transactional data lives in SAP.

The agent memory layer deserves a deeper look. Persistent memory is where consumer AI assistants finally became useful. ChatGPT remembering preferences, Claude carrying project context across sessions. Enterprise agents have historically been stateless, forcing users to re-prime the same context on every session. SAP's answer to this problem is to build memory as a BTP service, grounded in HANA Cloud Vector, with short-term, long-term, and reflective memory tiers governed by enterprise policies (retention, right-to-be-forgotten, audit trail).

Not a plug-in. A layer.

The SAP story has one recurring weakness, though: pace. DSAG's Technology Days 2026 in Hamburg, which drew more than 3,000 participants, delivered a consistent message from users. More clarity. Less architectural theater. Customers want SAP to ship faster and integrate more smoothly, not add more conceptual layers. The "simplified architecture" framing is partly defensive. It is a tacit acknowledgment that the SAP AI stack has become overwhelming to prospective buyers and to existing customers trying to execute.

ServiceNow: The Governance and Decision Layer

ServiceNow made the most conceptually ambitious move of the three. And it did so without a single major product announcement on the day.

Fred Champlain's piece on the SPM community blog introduces "strategic decision debt" as a category. The argument: the accumulated weight of unmade, unclear, or inconsistent portfolio-level decisions is what actually prevents enterprises from turning AI capability into AI outcomes. It is not a technology problem. It is a governance problem. And, Champlain argues, the governance layer is what ServiceNow sells.

The product scaffolding around the argument is substantial. Strategic Portfolio Management. Enterprise Architecture. The newly announced Context Engine, built on ServiceNow's Service Graph and Knowledge Graph, which captures the "why" behind decisions alongside the "what." AI Control Tower for governing agent behavior. TrustCloud and ComplianceCow, both of which received ServiceNow investment, shipped AI-native risk and compliance apps directly on the platform earlier in the week, reinforcing the partner-network moat.

The piece that matters most is the language. If "strategic decision debt" becomes a term CIOs use in quarterly reviews, ServiceNow owns the vocabulary, which means it owns the sales motion. No other titan has been publishing framework-level essays this quarter. Salesforce is publishing product pages. SAP is publishing architecture diagrams. ServiceNow is publishing a hypothesis about why enterprises are stuck and is offering its product portfolio as the answer. That is analyst-grade positioning, and it is rare from a vendor.

The Two Battlegrounds

I look at all these titan moves through two lenses.

• Interface control: who owns how users and agents access business applications.
• Orchestration: who owns the layer that coordinates work across systems.

This set of announcements maps cleanly on either lens.

Salesforce is the aggressive play on interface control. Own the access, and you own the orchestration that follows. AXL is the clearest multi-surface interface-layer bet any titan has made so far. SAP's interface-control play is softer, still routing interactions through Joule and its own surfaces. ServiceNow, interestingly, is not fighting for the interface at all. It is interested in being the backbone under whatever interface the user happens to be using.

On orchestration, the roles invert. Salesforce orchestrates experiences across channels, and, excluding what MuleSoft does, is quieter on orchestrating workflows across non-Salesforce systems. SAP orchestrates processes across SAP and non-SAP via BTP, Integration Suite, Advanced Event Mesh, and now master data via Reltio. ServiceNow makes the most conceptually interesting move by extending orchestration into the decision flow itself. Context Engine plus Service Graph plus Knowledge Graph is orchestration applied to how decisions get made, not just how tasks get executed.

Three titans. Three different pieces of the substrate. No direct overlap. Significant expansion of footprint for each.

The Titans Who Skipped This Quarter

Reading these three announcements in sequence raises an interesting question. Where are Microsoft, Oracle, Adobe, and Zoho?

Microsoft in particular is the puzzle. Copilot, Fabric, Dataverse, Foundry, Power Platform. Every component needed to tell the same substrate story is already on the Microsoft roadmap or already shipped. The gap is the narrative. Microsoft has the pieces, but Satya Nadella's team has not bundled them into a coherent layer-down argument the way Salesforce and ServiceNow have. If Build 2026 does not fix that, Microsoft cedes the architectural high ground on substrate for yet another quarter, while three of its main competitors keep compounding.

Oracle's AI Data Platform push is similar to SAP's BDC play but has not surfaced an equivalent integrated narrative. Adobe remains anchored to content and CX. Zoho continues its integrated-suite, lower-price playbook with less architectural theater, which is arguably the right move for Zoho's segment and consistent with its philosophy. It keeps the company out of this conversation, though, and that is a choice with consequences.

What Buyers Should Actually Do

The three recommendations from my LinkedIn post on this hold, and they deserve elaboration.

Stop evaluating AI features in isolation

A feature list is a snapshot. The substrate is what survives the next 18 months. Ask every vendor you are evaluating which layer of the substrate they claim to own, analyze whether the claim is architecturally coherent or three product pages stapled together, and what happens to your architecture if the vendor executes on that claim versus if they don't. Features come and go. Architecture commitments do not.

Ask the pricing question now, not later

Headless 360 is included in Agentforce 360 platform licenses today. SAP's agent memory layer is part of BTP today. ServiceNow's Context Engine sits inside existing product lines today. None of these vendors has announced whether they will keep the substrate capabilities in the base tier indefinitely. The historical pattern says no. Build your architectural dependencies with pricing clarity, not without it. And build the architecture in a way that those dependencies do not become impossible to unwind later. After all, today’s pricing clarity might be tomorrow’s pipe dream.

Treat "memory," "context engine," and "experience layer" as three costumes for the same problem

All three titans are building a substrate for agents to reason over. The vocabulary differs. The underlying capabilities: persistent cross-session state, grounded enterprise context, consistent multi-surface delivery are the same, just with different strengths and weaknesses in each implementation. Write down the capabilities your agents need. Map each vendor's product to these capabilities.

Do not let vendors map you to their product pages.

Three Things to Watch

Whether Microsoft responds at Build 2026 with a bundled substrate narrative, or lets Copilot keep carrying the whole story alone.

Whether SAP's Reltio integration actually ships as the promised trusted-data spine for Joule Agents or becomes another BTP component that customers must stitch together themselves.

Whether Salesforce's "Trust Moat" language around AXL holds up in enterprise deployments, where the every agent needs consistent permissions across Slack, Teams, ChatGPT, a customer portal, and more. If it does, lock-in critique loses force. If it does not, the critique becomes the dominant analyst read.

The Question That Matters

All three titans have moved one layer down, coming from different angles. The logic is sound. The architectural ambitions are serious. The open question is whether three companies each trying to own a different piece of the substrate produces three coherent platforms, or three partial platforms that leave buyers integrating the substrate themselves.

Twelve months from now, we will know whether April 2026 was the moment the agent conversation matured, or the moment it splintered.

I am curious whether CIOs are reading these three announcements as compatible stories, or as three competing bids for the same piece of architectural real estate.

So, the time of agentic AI has come?

What does this mean? Not for businesses, but for business users. These days, the main tool in the quiver of every business user in an enterprise is … the web browser. Initially web interfaces to business software and then SaaS software has seen to this.

The result? Employees needed to build their workflows around a plethora of different web applications, having open a corresponding number of tabs at any given time. I just counted the ones that I have open: fifty-three. And that doesn’t even count the web browsers that I do not even recognize as such. For example, Apple Calendar, or Microsoft Outlook. Maybe even MS Word … one never knows where there’s a browser these days …

Now, with agentic AI moving into the business, these workflows will need to change. How, that heavily depends on the vendors one works with and, of course, the size of the own business.

One of the main considerations when moving towards agentic workflows or agent-supported workflows is the orchestration of agents. This becomes especially important when working with different software packages and this is also a core reason for the emergence of protocols like MCP (model context protocol) and A2A (agent to agent) or ACP (Agent Communication Protocol) that are currently developed. Plus, there are a few “agentic” browsers emerging that allow for the orchestration of different agents on the user level.

But what is best, what to use – and when?

After all, many of the vendors that are already in house, have their own strategies. And many of the buyers, too, plus some limitations, like budgets, or time.

Vendor strategies

Vendor strategies for placing the orchestration layer depend on their value proposition and positioning. These strategies can largely be put into four buckets, the browser and frontend, application, application platform, and infrastructure, although this can be detailed out. Also, some of the larger vendors pursue more than on strategy. These are particularly the ones that offer an application suite. It can be expected that some of the mid-tier business application vendors will follow a multi-layer agentic orchestration strategy, too.

Browser and front-end layer

This layer is the one closest to the user and embeds agent and agent orchestration capabilities directly into the browser. AI agents to interact with the user interface (UI) of any web application, simulating human actions like clicking buttons, filling forms, and navigating menus. Its power lies in its universality; it does not require the target application to expose APIs, thereby making the entire web a programmable surface for automation. This strategy is essentially an extension of RPA. It is easy and convenient for the users who can automate pretty much every task with very limited technical skills. From a technical perspective, it doesn’t require API access. For browser makers or RPA vendors, this is the entrance into businesses via agentic automation. On the flip side, there is a considerable security risk as the agents may autonomously act in logged-in user sessions. Technically, they are somewhat unstable, as any change in a web applications layout or document object model has the potential to break the automation flow.

Still, this will probably become an important agentic automation strategy, especially on the consumer side, not in the least because also Google and Microsoft with their massive reach are pursuing this avenue.

Application layer

An application layer strategy focuses on domain (application) specific AI agents that are built into SaaS applications. These agents are regularly pre-trained on the domain data models, workflows and core business logic. Their integration into each other theoretically allows the execution of complex and context aware tasks within the boundary of the domain. Theoretically, as research has shown that the complexity that can get covered still has significant constraints. From a user perspective, this strategy offers a very fast time to value as agents are pre-trained, pre-integrated and work in an application that they already know. From a technical perspective, they are easy to train or fine-tune as they are already grounded in the data that the application itself works on. Further, it is pretty easy to provide guardrails and authorizations to prevent unauthorized data access. Disadvantages include their confinement into the hosting application. Using them to orchestrate cross-application workflows regularly requires implementation and integration work.

This strategy delivers high short-term value as the agents are likely to do a very good job. However, it is not very likely that vendors that follow this strategy become a top choice as an agent orchestration platform, unless they also play in the application platform layer.

Application platform layer

Vendors in this category make their technology platform the orchestration hub, supporting enterprise workflows that stretch across applications of different vendors, including vendors outside their own ecosystem. They leverage their access to data, knowledge graphs, metadata, as well as their range of business applications to provide a central environment or building, deploying, managing, and governing autonomous agents. Successful execution of this strategy makes them a kind of an operating system for autonomous agents. Businesses that have decided for an ecosystem can gain a single source of truth for data and processes, including unification of governance, security, and compliance. This enables the automation of the most complex and impactful business workflows. This and pre-built integrations across the vendor's own application suite reduce development complexity for intra-ecosystem workflows, freeing the IT team for other tasks. On the negative side, following this strategy causes a vendor lock-in, which makes it hard to move into another ecosystem. If it isn’t already implemented, the platform implementation itself can become costly and complex. While standards are emerging, the technical integration with agents in non-ecosystem applications may be cumbersome. Also, the platform itself often evolves slower than other orchestration architectures.

In spite of the disadvantages, this is probably one of the most viable strategies, because digital agents, as part of technology, are a platform game. There is a good chance that these platforms become the “system of record” for agent orchestration, given that they embrace the evolving open standards for agent collaboration.

Infrastructure layer

Vendors that focus on this strategy do not deliver end-user agents but on delivering the underlying frameworks, tools, protocols, i.e., the "plumbing" that is required to build, connect, and orchestrate multi-agent systems. They focus on offering the foundational components that enable developers and citizen developers to construct agentic applications by enabling them to compose capabilities from various applications. It is a platform strategy. In that sense, it is a subset of the application platform strategy.

The primary advantage of this strategy is that it allows users to have maximum flexibility and control. It is (mostly) application vendor independent and avoids a lock-in to any application vendor. From a technical perspective, this strategy enables an open, extensible, and composable architecture. It aligns with software development practices like microservices, that build complex systems from smaller, independent, yet interoperable components. From a user perspective, this comes with the disadvantage of requiring significant in-house development expertise and capacities as the complexity of building, managing, and governing a heterogeneous multi-agent system is substantially higher than using an integrated platform. Technically, the full responsibility for ensuring security, scalability, reliability, and observability of the entire system lies with the implementing organization.

The viability of an integration layer strategy is pretty high. Many (enterprise) customers will have multi-ecosystem infrastructures and pursue a best-of-breed strategy. These will find themselves attracted by an infrastructure-based orchestration layer.

What does this mean for businesses?

Agentic AI has gained significant traction, if not (yet?) in results but certainly in share of mind. Consequently, it is foreseeable that more and more businesses will, or will need to, implement and deploy digital agents, that in turn need to cooperate with each other. E.g., a sales agent in a sales system and a support agent in a service desk are of limited value if they cannot collaborate to provide a unified user- and customer experience. This simple reality is driving the market away from monolithic, connected systems toward collaborative, multi-agent architectures. This makes agent interoperability not just an option but a must. Expect all major vendors to embrace open standards like MCP, A2A or ACP to strengthen their own competitive position by avoiding the need for another vendor’s agent integration platform. Second, this way they can protect their own revenues in times of reduced importance of seat-based pricing. Welcome back to indirect access charges.

To make an implementation of an agent orchestration platform a success, businesses of all sizes need to have criteria of what constitutes good or desired outcomes, against which vendors and then the implementation can get measured. At the very basis, the chosen toolset needs to accomplish the job, i.e., orchestrate agents across applications fast and reliably. To accomplish this, it is likely that orchestration needs to happen on different layers, in-app, on a platform layer and/or on the front-end layer to support cross-app orchestration. It needs to provide guardrails, especially authentications and rules for escalating decisions or actions to humans and provide the observability that is necessary for its monitoring and an audit trail. A lock-in should be avoided as much as possible, so the technology stack should be open’ish instead of highly proprietary. I know that this is quite hard to achieve and that nearly every vendor attempts to create barriers to change.

 The priorities of these criteria differs between sizes of businesses and even from business to business. E.g., a very small business is less likely to orchestrate agents on an application platform level than an enterprise. Likewise, enterprises that pursue a best-of-breed strategy are more likely to use infrastructure layer orchestration than application platform based orchestration. Of course, process complexities play a role, too.

So, let’s break this down in four categories, looking at enterprises with 1,000 or more employees, midmarket companies with 100 – 999 employees, small businesses with 3 – 99 employees and “solopreneurs” with one or two system users.

Enterprises

Enterprises target at achieving autonomous yet strictly governed cross-vendor operations at scale. They require strong audit, risk and change control built into the agent orchestration system.

These companies typically operate very complex, global, and heterogeneous IT environments that often include multiple CRMs and ERPs, deeply entrenched legacy systems, and hundreds of cloud applications. These companies have mature yet often understaffed IT, architecture, and development teams.

The goal is not only automation but achieving or retaining the ability to transform the business with the help of the agentic orchestration architecture.

Recommended strategy

Enterprises should architect and build out a composable, multi-layer “agentic mesh”. They should not seek to buy a single, all-encompassing solution. Instead, the strategy is to architect a resilient and adaptable agentic mesh that leverages a central platform, neutral integration layers, and open standards to enable interoperability and avoid vendor lock-in.

How to get there

Depending on what is already available in the company, a three-step roadmap should be employed.

• Migration of ad-hoc agents to a central agent fabric and establishment of agent and action registries.
• Implementation of least-privilege authorizations for the agents and actions and ensuring observability as well as approval workflows that cover development/deployment as well as runtimes.
• Introduction of multi-agent patterns, e.g. planner/worker/validator, etc., to reduce risk and definition and measurement of service level objectives. The system needs to be increasingly self-healing and have roll-back possibilities.

Midmarket companies

Midmarket companies target at having a scalable, governed, cross-domain automation with clear ownership that over time can grow into an agentic mesh. These companies typically have multiple departments, each with established processes. The tech stack is already moderately complex and heterogeneous. It mostly includes a central ERP and a CRM alongside many departmental apps. There is a dedicated internal IT team.

The primary goal is to break silos and to move from departmental efficiency to end-to-end, cross-functional process automation and improvement.

Recommended strategy

Midmarket companies should build out a primary platform for agent orchestration while maintaining their flexibility. To select this platform, they should start at evaluating the application platform offerings of their core business application vendors. The focus of this evaluation are its capabilities to orchestrate agents outside of its vendor’s ecosystem.

How to get there

Depending on what is already available in the company, a four-step roadmap should be employed.

• Selection of a small number, e.g. two to three, meaningful end-to-end processes for agentic automation.
• Modeling of these processes in the agentic fabric and their instrumentation with relevant KPIs.
• Use of agents only where they can get measured.
• Increasing autonomy of agents with growing confidence, starting with safeguarding the agents behind human approval steps.

Small businesses

Small businesses typically want to reduce the number of manual hand-offs between a set of core applications while keeping governance simple. These businesses typically have small teams and growing process complexity, in combination with a collection of function-specific SaaS applications like a dedicated sales system, different marketing apps, a helpdesk tool, an accounting package, etc. IT support is often limited and/or outsourced.

The primary goal is to streamline core business functions and improve efficiency within departments.

Recommended strategy

Small businesses should build out in-app agentic capabilities and high-volume integrations. The focus should be on solving specific, high-impact business problems with the use of agents, e.g., within sales, marketing, and service, and then automating processes that span across the chosen core systems.

How to get there

Depending on what is already available in the company, a three-step roadmap should be employed. Two core objectives are speed of resolution and the avoidance of a vendor lock-in.

• Selection of a number of high-volume flows, starting with automation via in-app agents, then connecting them across apps.
• Definition of service level objectives with corresponding KPIs and measure, initially keeping human-in-the-loop steps which get removed with growing confidence.
• Replacing of frontend-based integrations with API-based integrations

Solopreneurs

Solopreneurs are typically plagued by the need for entering the same data multiple times while operating on limited budgets. There is no dedicated IT staff, and a reliance on a handful of disconnected, low-cost SaaS applications.

Their goal is to automate time-consuming “swivel chair” processes to increase their personal productivity without creating administrative overhead and bigger expenses.

Recommended strategy

Solopreneurs should automate their time-consuming repetitive processes, focusing on personal productivity and simple connectors. This is best achieved using no-code tools that can deliver immediate time savings while not requiring technical expertise of significant investments.

How to get there

The immediate focus should lie on quick wins.

• Definition of a small number of systems as sources of truth.
• Identification and listing of swivel-chair tasks.
• Automation using a lightweight no-code IPaaS tool in combination with browser agents, starting from easy, going towards difficult.

Summary

As you can see, these strategies and tactics form a graduation from simple to complex. The start is improving personal productivity via single tasks, followed by moving towards in-app agents and then an agent fabric with formalized guardrails and increased measurement of outcomes. From there, the orchestration system becomes a platform that ultimately offers a catalog of agents and their actions, credentials that support a tiered, trust-based autonomy model, supported by full observability.

If you need some help on this road, contact me.