The news

At its PegaWorld conference in Las Vegas on June 8, 2026, Pegasystems announced Pega Infinity 26, which it says will be available in Q3 2026. The principal change is commercial: Pega is moving away from per-token pricing for its AI agents toward a flat charge per completed "case," which it defines as a task carried out from start to finish, such as a customer changing an order, a loan approval, or a claim. Pega frames the move as removing what it calls the "AI token tax".

The pricing change rests on an architecture Pega calls Predictable AI. Reasoning-heavy AI work is concentrated at design time, when workflows are authored in Pega Blueprint and the new Infinity Studio. At runtime, a lighter-weight model identifies the user's intent, selects a pre-approved workflow, and executes it step by step; where an individual step requires a language model, for example to parse a document or summarize a prior interaction, that step is given bounded instructions rather than open-ended latitude. Pega gives two reasons: more consistent outcomes, because agents follow approved workflows rather than re-reasoning each request, and more predictable cost, because the heavier processing happens only once during design rather than on every transaction.

The architecture is not new to this release. Pega introduced Predictable AI Agents in May 2025 and integrated them into Pega Infinity '25, which reached general availability in December 2025. Infinity 26 primarily adds the outcomes-based pricing model, alongside a companion announcement that exposes Pega processes as Model Context Protocol (MCP) servers, allowing third-party agents from Anthropic, OpenAI, Google, and AWS to call them under Pega's governance controls. The release cites no named customer, quotes analyst Liz Miller of Constellation Research. The "more than 20x" savings figure comes from Pega's AI Token Cost Calculator and is qualified as applying "depending on workflow complexity and scale".

The bigger picture

Two industry currents explain the timing of this announcement.

The first is pricing. The customer-service software market has spent the past year and a half moving away from per-seat and per-token models toward charging for outcomes. Intercom Fin charges $0.99 per resolution. HubSpot cut its customer agent to $0.50 per resolved conversation in April. Zendesk runs around $1.50 per automated resolution on committed volume and has been selling outcome-based pricing since 2024. Salesforce launched Agentforce at $2.00 per conversation, a unit so loose that only roughly 8,000 of its 150,000-plus customers adopted it, which forced a pivot to per-action Flex Credits and Agentic Work Units. Sierra, Decagon, and Ada all sell per-outcome on custom enterprise contracts. Gartner, in a March 2026 forecast, projects that the cost of running inference on a trillion-parameter model will fall more than 90% by 2030, while noting that those provider-side savings will not fully reach customers and that agentic models consume between 5 and 30 times more tokens per task than a standard chatbot. Not all of it will reach the buyers, though. The unit price of thinking is falling while the number of units per task climbs, which is the squeeze every vendor in this market is now pricing against. Pega's per-"case" charge belongs to this trend, with its unit defined differently from a customer-service "resolution": a case spans a back-office task such as a loan approval or an insurance claim run end to end, rather than a single support interaction.

The second current is a deep disagreement across the industry about how much freedom an AI agent should have at runtime. One camp ships prompt-based tooling and lets agents reason and plan at each step, treating flexibility as the key point. Another constrains agents to pre-approved workflows and treats unbounded runtime reasoning as a liability, especially in regulated processes. Pega sits firmly in the second camp, and its CEO has said publicly that competitors asking users to write prompts are setting themselves up for trouble. The context underneath the argument is not trivial. A widely cited 2025 MIT study from its NANDA initiative found that roughly 95% of enterprise generative AI pilots produced no measurable return on the profit line, which the authors attributed less to model quality than to a "learning gap" in how organizations integrated the tools. This is the line the market is arguing about right now, and the vendors have started to pick sides.

My point of view and analysis

Start with the part Pega frames as leadership. On price, Pega is not leading, it is catching up, and the per-"case" charge is the same outcome-based move the customer-service vendors made first, just dressed for a different room. Credit where it is due, however, because the chosen unit is better than most: a completed back-office case is harder to game than a support "resolution" and maps to work a CFO already values. That is a real distinction. It is also a modest one, and it is not a first.

On the architecture, Pega's CEO is not entirely wrong about the risk he is arguing against. Letting a model improvise its way through a regulated claims process is asking for trouble, and the graveyard of failed genAI pilots is full of companies that could not audit what their agents did. The trouble is that the cure and the original promise of agentic AI pull in opposite directions.

Here is the question I cannot get my head around. There is real value in customer interactions that follow a rote path, and a great deal of work is exactly that; so Pega serving the rote case cheaply and consistently is a good thing, period. But the value of an agentic system was supposed to be the other case: the request that does not fit the workflow as designed, the genuinely novel situation. Pega's architecture is built to do the opposite of reasoning through those at runtime. So how does the system know it can safely run the rote workflow if it never reasons through the case at the outset? Pega's answer is the lightweight intent query that does the routing, which means the only runtime intelligence in the loop is intent classification, and classification is itself probabilistic and perfectly able to misroute. A request that matches no workflow then has three exits: forced onto the nearest approved path, escalated to a human, or handed to Blueprint to generate a workflow on the fly. However, that third option is the one Pega spends the whole pitch warning against, because runtime generation in a regulated process is precisely what it calls dangerous. You cannot headline determinism and keep on-the-fly generation as the safety valve without owning the contradiction.

There is a distinction underneath all of this. Deterministic guardrails wrapped around a probabilistic system set the boundaries of acceptable action without collapsing the space inside them. The agent still reasons; it simply cannot climb the fence. Pega is doing something else. At runtime, the approved space is the entire space. There is no reasoning inside the fence, because the fence is the answer. That is not an agent operating within guardrails. It is a workflow engine with a probabilistic front desk. For loan approvals and claims that may well be the right trade, and it should simply be named as one. The industry spent two years insisting agents would handle the unscripted long tail, and Pega's bet is that the long tail is where you get hurt, so it designed the long tail out. They may be right about the risk while conceding the promise without saying so. This is BPM, Pega's home turf since 1983, with an AI intake layer on the front. Calling it agentic is generous.

So here is what I would do before believing the deck. Ask Pega for one named production customer, on the record, who has run this at scale and watched the cost curve flatten, because a calculator output is not a reference you can phone. Then get the definition of a billable "case" in writing, including what happens when the workflow misroutes, fails, or escalates to a human, because "resolution" was always a vendor-defined word and "case" is no different, and that ambiguity surfaces on the invoice rather than in the contract. Finally, ask the uncomfortable one: what share of your real request volume does not map cleanly to a pre-approved workflow today, and what does Pega do with that slice? If the answer is "a human takes it" or "Blueprint writes a new one live," you are buying a very capable workflow engine, which may be exactly what you need, as long as you buy it with your eyes open.

The token critique landed because it is true, and the architecture is sensible for the work Pega is aiming at. I am just not convinced the market asked for agents that are forbidden from thinking the moment a request gets interesting, and I would like to know whether buyers are actually asking for this or whether the industry has decided the long tail was a bad idea all along.

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.

SAP Sapphire 2026 was a major platform announcement, a competitive shot at ServiceNow, a coherent acquisition story across Reltio, Dremio and Prior Labs. It featured an Anthropic partnership that puts Claude at the center of the SAP Business AI Platform. For anyone who cares about customer experience, it was also a missed opportunity dressed up as ambition.

If you watched only the keynote, you concluded SAP barely talks about CX. Klein did finance with JP Morgan. Herzig demoed pharma pricing. Industry AI showcased RWE wind turbines. The named flagship was the Autonomous Close Assistant. CX got line items.

That reading is incomplete. Here is what actually happened for CX at Sapphire 2026, what it means competitively, and what SAP and SAP CX customers should do about it.

What SAP actually shipped for CX

On the same day as the keynote, Balaji Balasubramanian, SAP's CX President and Chief Product Officer, published a substantive announcement listing ten named Joule Assistants for CX. Marketing gets Content and Campaign Assistants. Commerce gets Merchandising, Shopping and Order Management Assistants. Sales gets Sales, Deal Qualification and Deal Closing Assistants. Service gets Case Management and Service Management Assistants.

The supporting announcements are the part most analyst coverage missed. A Google partnership brings Gemini into SAP CX, plus adoption of the open Universal Commerce Protocol. Vercel handles storefront development. SAP Unified Payment runs on Adyen, with Checkout.com and PayPal configurable. Expanded Parloa and Amazon partnerships cover voice and digital service. A new SAP Commerce Cloud, cloud ERP edition targets mid-market. Two Industry AI scenarios for CX: Autonomous Revenue Growth Management and Unified Commerce.

All of it planned for general availability in Q3 2026.

For a category the keynote treated as a sub-bullet, that is a substantial product agenda. SAP Commerce Cloud has been a Gartner Magic Quadrant Leader for Digital Commerce for eleven consecutive years and the customer base is real. Adidas, Coca-Cola, Allianz, large utilities and banks all run on it.

The Cinderella problem

Despite all this, the keynote did not put CX in the same tier as Finance, Supply Chain or Industry AI. No flagship CX customer on stage opposite JP Morgan. No Autonomous Service Resolution Assistant matched to the Autonomous Close. No CX product head with mainstage time. The CX story subsists in a blog post by the CX CPO. The Autonomous Close gets prime time in the Sapphire keynote.

This is the Cinderella problem. SAP CX has the product. SAP CX has the customers. What SAP CX lacks is executive air cover. The product team shipped. The C-suite did not promote.

The signal is clear. Adobe Summit features Anil Chakravarthy championing CX Enterprise Coworker. Marc Benioff personally champions Agentforce Service at Dreamforce. The market – and analysts, too – reads those vendors as doubling down on CX. When Klein does finance and supply chain and CX gets a blog post, they read SAP as deprioritizing CX. The signaling problem makes the purchasing budget harder to defend, even where SAP CX has the better product.

The E2E story breaks at the customer interface

The bigger structural problem is what this does to SAP's own Autonomous Enterprise pitch. SAP says the autonomous enterprise runs on Joule across finance, supply chain, procurement, HR and customer experience. That is the E2E argument. It is a strong argument. It claims SAP can orchestrate cross-application, cross-department processes because SAP owns the system of record and the agentic platform on top of it.

Like each chain, it breaks at the weakest link. CX is this weakest agentic; the pitch breaks right there. And it breaks where it hurts most. Customers do not experience companies through CFO close cycles. They experience companies through service tickets, sales conversations, commerce checkout flows and marketing engagement. An enterprise that can compress financial close from weeks to days but still routes every service case to a human is not autonomous. It is back-office automation with a CX problem.

The Cinderella treatment of CX hurts SAP more than SAP appears to recognize. The cost is not just lost CX deals. It is the credibility of the Autonomous Enterprise narrative itself.

Where SAP CX sits competitively

Adobe is the most credible CX competitor in the marketing and commerce arenas. CX Enterprise Coworker launched at Summit on the same NVIDIA OpenShell runtime SAP uses, with multi-model interoperability across Anthropic, AWS, Google, Microsoft and OpenAI. AEP Agent Orchestrator, Brand Concierge, Real-Time CDP and the Magento commerce stack form a consistent CX agentic story. Adobe does not compete in ERP, so the two only collide in marketing, commerce and customer data. Adobe is winning the visibility fight there easily.

Salesforce with Agentforce 360 plus Operations is at $540M ARR with Service Agent, Personal Shopper and Buyer Agent shipping is the 800-pound-gorilla. Headless 360 makes Salesforce CX accessible through any MCP front end. Salesforce wins front-office. SAP wins back-office. They collide in customer-to-cash.

Microsoft Dynamics 365 Copilot for Service and Sales are generally available. Microsoft Agent 365 hit GA on May 1 at $15 per user per month. SAP wins ERP depth. Microsoft wins productivity surfaces and developer mindshare.

ServiceNow Autonomous CRM processes 100M+ customer cases monthly. AI Control Tower with 30 enterprise connectors positions ServiceNow above the application layer. This constitutes a real threat to SAP Service Cloud in enterprise customer service, particularly where ServiceNow ITSM already runs.

Mid-market matters more than enterprise watchers want to admit. HubSpot Breeze has shipped Customer, Prospecting, Content and Data Agents for years. Zoho Zia ships 100+ pre-built agents at $40 per user per month. SugarAI rebranded around precision selling and ERP signals last month. Creatio went seat-free with Unlimited on May 1. Freshworks Freddy and Zendesk AI Agents are GA. The new SAP Commerce Cloud, cloud ERP edition signals SAP wants to compete here. The pricing model will be the test.

What the platform actually does for CX

The platform announcements help SAP CX in tangible ways. Reltio gives Service Cloud a customer golden record across SAP and non-SAP systems with MCP support. Dremio lets agents reason on commerce and customer data without moving it. Prior Labs brings frontier tabular foundation models for the propensity scoring, churn prediction and lifetime value modeling LLMs are bad at. Free Joule Studio through 2026 lets SAP CX customers build custom agents without the per-seat AI surcharges Salesforce stacks on top. AI Agent Hub on LeanIX governs SAP and non-SAP CX agents at no charge.

No doubt, these are useful pieces. But they are not enough to offset the signaling problem.

Three recommendations for CX buyers

Audit the ten Joule Assistants for your modules with GA dates, not roadmap dates. All ten are planned for Q3 2026. Plan is not GA. Push SAP for module-specific commitment dates before signing renewal or expansion contracts. The free Joule Studio through 2026 is a real negotiating lever and a good opportunity to evaluate SAP as a credible CX alternative.

Run a real CX agent bake-off across the relevant vendors. SAP Service Management Assistant against Salesforce Service Agent. Adobe Brand Concierge against SAP Content Assistant. Test agent quality on your actual customer data, using your actual intent. The winner is the one whose agents resolve your cases or convert your shoppers, not the one with the best slide deck.

Take the CX orchestration plane decision deliberately, and not by accident. If your non-SAP CX estate is substantial (Salesforce Sales Cloud, Adobe Experience Manager, ServiceNow Customer Service Management, Zendesk, Freshworks, HubSpot), the question of where CX agent governance lives is now architectural. SAP AI Agent Hub, ServiceNow AI Control Tower, Salesforce Agent Fabric and Microsoft Agent 365 are not interchangeable. Test which one actually governs your non-SAP CX agents in production today. Loyalty is not a strategy.

Three recommendations for SAP

Ship an Autonomous Service Resolution Assistant or another relevant CX agent with the same visibility as the Autonomous Close. These agents exist. The flagship treatment does not. The Autonomous Close got JP Morgan, a named customer arc and Klein keynote time. CX deserves a named flagship agent with a named customer reference. Adidas, Coca-Cola, Allianz are sitting right there. Use them. The cost of doing this is a quarter of marketing investment. The cost of not doing it is another lost year as Cinderella does not get found by her prince, aka the customer.

Put the CX CPO on the next Sapphire mainstage with a named customer, or two. Balaji Balasubramanian wrote a substantive blog post. This is good, necessary – but insufficient. The mainstage signals priority. Service Cloud, Commerce Cloud, Emarsys and Customer Data Cloud are competitive products with reference customers and Magic Quadrant placement. They need keynote time, not blog time. SAP's bench can match Adobe's Chakravarthy and Salesforce's Benioff. The question is whether the C-suite decides to.

Decide whether CX is core or peripheral to the autonomous enterprise pitch, and commit visibly. Either invest with budget, headcount, roadmap parity and executive time equal to Finance and Supply Chain, or stop including CX in the E2E story. The Cinderella position helps no one. As said before, an autonomous enterprise that can close books in days but routes every service case to a human is not autonomous. It is back-office automation with a CX problem. Either fix the CX side of the story or shrink the story to fit what is real.

My PoV

SAP Sapphire 2026 shipped more for CX than the keynote let on. Ten named Joule Assistants. Partnerships with Google, Vercel, Adyen, Parloa and Amazon. A mid-market commerce edition. Two Industry AI scenarios. The product is more substantive than the press and analyst coverage suggests.

What is missing is the executive championing. The product team did its part. The C-suite did not do theirs. That asymmetry is the structural problem Sapphire 2026 did not fix, after I had some hope last year.

Let’s see when Cinderella finally gets to dance.

On May 4, 2026, SAP announced two acquisitions in the same breath: Dremio, an Apache Iceberg-native agentic data lakehouse, and Prior Labs, a pioneer of Tabular Foundation Models. Neither acquisition is exotic. Together, they are contributing to the most coherent enterprise AI platform strategy any major vendor has shown this year.

Let me unravel what each company actually brings, why the combination matters, what it means for the competitive field, and — most importantly — what buyers and SAP customers should be doing right now.

The Problem SAP Is Solving

Before diving into the deals, let's formulate the problem addressed. SAP's CTO Philipp Herzig said it clearly: "Enterprise AI doesn't stall because the models aren't good enough; it stalls because the data isn't ready for AI agents".

That is not a marketing line. It describes a pattern analysts and practitioners see constantly: AI pilots perform in a sandbox and fail when they hit production. The reasons are familiar: data is locked in proprietary formats across a dozen systems, there's no consistent business context, ETL pipelines take months to build, and governance gaps make audit-ready AI decisions nearly impossible.

SAP has also faced an additional problem. The narrative about SAP is and always was that it works brilliantly if everything lives inside SAP and required considerable engineering if you want to connect it to anything else. In an enterprise world where the average organization uses dozens of SaaS applications, that story is a liability.

Both acquisitions address these problems directly from different angles.

Acquisition One: Dremio and the Data Layer

Dremio is an open-data lakehouse built on Apache​ Iceberg. That description undersells it. Dremio co-created Apache Polaris, the open catalog standard for Iceberg multi-engine interoperability, and Apache Arrow, the in-memory columnar format that is the plumbing of modern analytics. These are foundational open-source contributions. Dremio's customers include Shell, TD Bank, and Michelin; these are enterprises with complex, multi-environment data estates that needed exactly what Dremio offers: federated query across any data source, without copying data or running ETL.

The specific integration SAP is executing is significant. SAP Business Data Cloud will become an Apache Iceberg-native enterprise lakehouse. That means SAP and non-SAP data can coexist on the same open foundation without format conversion or data movement. A universal catalog built on Apache Polaris means every system — SAP and otherwise — can read and write using the same standards. The Dremio AI Semantic Layer adds consistent business context across all sources, so that an AI agent querying HR data from SuccessFactors and financial data from a non-SAP system is working from the same definitions, not two conflicting ones.

For SAP's agentic AI play, this is a big improvement. Joule agents need data to act on. If that data is fragmented, ungoverned, or requires human pre-processing before an agent can consume it, agentic AI becomes expensive proof-of-concept work rather than production value. Dremio's self-managing platform with automated clustering, compaction, query optimization, reduces the operational burden of keeping an AI-ready data estate running. The MCP integration Dremio already ships means any LLM or AI agent framework can access enterprise data without custom integration work.

What is production-ready versus pending: The transaction closes Q3 2026, subject to regulatory approval. The Dremio platform itself is proven at enterprise scale, so this is not an early-stage bet. The integration work to embed Dremio fully into SAP Business Data Cloud will take time after close. Buyers should expect a meaningful roadmap presentation at SAP TechEd 2026 rather than a shipping product today.

Acquisition Two: Prior Labs and the Intelligence Layer

Prior Labs is a different kind of acquisition. This is not a product acquisition. It is a research acquisition with a specific thesis: Large Language Models are the wrong tool for structured business data prediction.

The argument is technical but intuitive. LLMs are trained on text. They have a rudimentary understanding of tables and statistics. When you ask an LLM to predict payment delays, supplier default risk, or customer churn from tabular ERP data, you are using a tool designed for language on a problem that is fundamentally about numbers, distributions, and correlations within structured datasets. Tabular Foundation Models (TFMs) are purpose-built for exactly this domain.

Prior Labs' flagship model series, TabPFN, has been academically validated: published in Nature, top-ranked on TabArena, the leading benchmark for tabular models, and with over three million downloads as an open-source tool. The most recent TabPFN-2.6 matches the accuracy of a four-hour automated machine learning pipeline, produced instantly, in a single model. For enterprise use cases like predicting payment delays, supplier risks, upsell opportunity scoring, and churn probability, that is a meaningful capability gap versus what LLMs can offer today.

SAP will commit more than €1 billion over four years to scale Prior Labs into what it is calling a globally leading frontier AI lab for structured data, based in Europe. Prior Labs will operate as an independent entity and will retain its open-source strategy. The scientific advisory board will include Yann LeCun (ACM Turing Award winner, Advanced Machine Intelligence) and Bernhard Schoelkopf (Max Planck Institute for Intelligent Systems, ELLIS president). That is not a list assembled for press release credibility. Both are significant contributors to the field.

The European angle matters beyond headlines and marketing. Regulatory pressures on AI data handling, EU AI Act requirements for explainability, and data sovereignty concerns make a European-based frontier AI lab genuinely useful for SAP's core customer base. An AI model built and governed in Europe, on structured business data, with academic validation and an open-source foundation, addresses a set of enterprise objections that American hyperscaler AI labs cannot easily resolve.

What is production-ready versus pending: Prior Labs' existing models are available and proven at the research level. Their integration into SAP's commercial product stack, embedding TabPFN predictions into S/4HANA, CX, or SuccessFactors workflows, requires post-close engineering. The €1B investment is a four-year commitment, not a capability that appears in the next release cycle.

Why the Combination Matters: A Three-Layer Stack

Looking at these acquisitions together, SAP is assembling a three-layer stack for enterprise agentic AI:

Layer 1: Data access and governance: Dremio + SAP Business Data Cloud. Federated access to SAP and non-SAP data, open Iceberg-native foundation, AI-ready governance, no data movement required.

Layer 2: Business intelligence from structured data: Prior Labs' TFMs. Accurate predictions on tabular business data that LLMs cannot match; payment delays, supplier risk, churn, upsell scoring.

Layer 3: Agent orchestration: Joule + Business Technology Platform. SAP's existing AI agent and process automation layer, is now able to draw on a governed data foundation and specialized prediction capability.

The coherence here is unusual. Most enterprise AI announcements from large vendors are additive: another LLM integration, another AI assistant feature, another partnership with an LLM provider. This one is different. SAP is making a structural argument about what enterprise AI requires. Not just a better model, but the right kind of model running on clean, federated, business-context-aware data, and is acquiring the capabilities to back it up.

The Partnership Question: Databricks and Snowflake

This is where the Dremio acquisition gets complicated, and SAP customers with existing data platform investments need to pay close attention. In the 15 months before today's announcement, SAP built two high-profile partnerships around exactly the problem Dremio solves. Both are now in a different position than they were yesterday.

The Databricks situation

In February 2025, SAP launched SAP Databricks as a first-party service natively embedded in SAP Business Data Cloud. This is not a partner integration, but a component of BDC itself, paid via BDC Capacity Units. Databricks committed $250 million to support customer and SI success on the joint platform. It was positioned as the flagship data engineering and AI layer for BDC.

Dremio competes directly with this story. Where SAP Databricks brought data engineering, ML workloads, and Unity Catalog-governed analytics into BDC, Dremio brings an Iceberg-native lakehouse, federated query across SAP and non-SAP data, and an AI semantic layer. These capabilities overlap substantially.

The underlying table format tension makes this sharper. Databricks' platform is built primarily on Delta Lake, with Iceberg support added later. Dremio co-created Apache Iceberg's catalog standard, Apache Polaris, and is Iceberg-native by design. SAP's stated direction is to make Business Data Cloud Iceberg-native. If that commitment holds, SAP's own first-party data architecture moves toward the format Dremio built, and away from the format Databricks built on.

SAP has not addressed what happens to SAP Databricks after the Dremio close. The most plausible near-term outcome is that Databricks retains a role as the ML and AI model development workbench within BDC with Unity Catalog, model training, MLflow, Mosaic AI, while Dremio becomes the lakehouse storage and federated query layer. That is a narrower role than Databricks was sold as in February 2025, and it represents a meaningful change in the commercial argument for SAP Databricks. Customers who made BDC decisions partly on the strength of that integration should ask explicitly, in writing, what the integration roadmap looks like after the Dremio transaction closes. Remember Hybris? or SAP Marketing Cloud?

The Snowflake situation

Snowflake's position was structurally weaker before today. When SAP and Snowflake announced their partnership in November 2025, the difference in status was noted immediately: SAP Databricks was a first-party service inside BDC, while SAP Snowflake was a solution extension, an add-on. SAP's data and analytics leadership confirmed the distinction publicly. Snowflake was the third major data platform partnership SAP announced that year, after Databricks and BigQuery.

The Dremio acquisition makes Snowflake's position harder to defend commercially. Snowflake has bet heavily on Apache Iceberg adoption; it is one of the company's core strategic moves to remain relevant as the industry converges on open table formats. This Iceberg compatibility means SAP and Snowflake can still interoperate through an Iceberg-native BDC. But compatibility is not the same as commercial necessity.

The core proposition of the SAP-Snowflake partnership was: bring your existing Snowflake deployment, connect it to SAP Business Data Cloud via zero-copy BDC Connect, and get federated access to semantically rich SAP data without moving it. Dremio offers the same federation story natively, from inside BDC, without a separate Snowflake contract. For customers now deciding between SAP BDC + Snowflake and SAP BDC + Dremio as their non-SAP data federation layer, the math has changed.

There is also a timing question. The SAP-Snowflake BDC Connect integration was planned for H1 2026 general availability. Now that SAP has announced a native Dremio-based federation layer, watch whether that H1 2026 timeline holds or slips, and how the roadmap changes. I expect SAP's engineering prioritization to change.

What buyers with existing partner investments should do

Three hot questions for anyone already using or evaluating these partnerships:

Will Databricks' role inside BDC narrow from "first-party lakehouse service" to, e.g., "ML and model workbench"? If so, the ROI case for SAP Databricks changes, and customers who bought it as a data platform should model what Dremio covers versus what Databricks still delivers uniquely. Get that scoping conversation started now, before the Dremio transaction closes and SAP has to commit to a position.

Does the SAP-Snowflake BDC Connect rollout and ongoing development proceed on the original timeline? If SAP's native federation story via Dremio reduces internal urgency to complete the Snowflake integration, customers who built roadmaps around the Snowflake partnership will need to know. Ask immediately.

For both Databricks and Snowflake, the more important question is not whether the partnerships survive — they almost certainly will in some shape and form — but whether they survive with the same scope. SAP has a track record of gradually narrowing partner integrations once it builds equivalent native capability. Both Databricks and Snowflake should be scenario-planning for that conversation. And SAP customers should avoid being caught in the middle of it.

How This Changes the Competitive Map

None of SAP's major competitors is positioned identically. Each has a different set of strengths and gaps.

Microsoft has Microsoft Fabric as its unified data platform and Copilot as its AI layer. Fabric is a credible, well-funded platform, but it is Azure-native and more proprietary than an Iceberg-first architecture. Microsoft does not have a tabular foundation model research capability. The company's AI investments are primarily in OpenAI-based large language models, which face the limitations on structured data prediction that SAP's CTO named.

Salesforce has Data Cloud as its data unification layer and Einstein as its AI layer. Data Cloud is impressive for CRM-centric use cases and requires other data to be ingested into Salesforce's ecosystem. It is not a federated architecture. Salesforce's AI investments are focused on their customer data estate, not the broader structured data prediction problem. Compared to SAP's core industrial, manufacturing, and financial services customer base, that is a narrower scope.

Oracle is actually the most interesting comparison. Oracle has full-stack control (SaaS, PaaS, IaaS) and deep integration across Fusion applications and OCI. Like SAP, Oracle has a large base of structured operational data. But Oracle has not made a comparable move on the data layer (no Iceberg-native federated architecture commitment) or on the model layer (no TFM research acquisition). Oracle's agentic AI story is about embedding agents into Fusion workflows, not about predicting outcomes from structured data with specialized models.

Snowflake is worth watching as an indirect competitor. Dremio and Snowflake serve overlapping markets. Both are open-data lakehouse platforms. Snowflake has its own Iceberg support and Cortex AI layer. The SAP acquisition gives Dremio the enterprise ERP context and customer base that Snowflake competes for separately. Combined with SAP's process knowledge, the Dremio + SAP Business Data Cloud stack could become a strong alternative for Snowflake's enterprise analytics customers, particularly those running SAP.

The Open-Source Angle

Both acquisitions come with an explicit open-source commitment from SAP. That is not accidental and it is worth taking seriously.

Prior Labs' TabPFN has 3 million downloads and academic validation. SAP's stated intention to preserve the open-source strategy means the research community continues to develop and validate these models, which benefits SAP's commercial implementation. Dremio co-created Apache Iceberg's catalog standard Polaris and the Arrow query format. SAP's commitment to continue contributing to these projects matters for interoperability. It is what makes the "no vendor lock-in" claim credible.

For enterprise buyers, the open-standards story addresses a real concern: if you rebuild your data architecture around a vendor's AI platform, what happens in five years if you need to change vendors? An Iceberg-native, Apache Polaris-cataloged data estate is portable in a way that a proprietary format is not. SAP is betting that customers who build on open standards will stay, not that they have to stay.

What Buyers and SAP Customers Should Do

If you are an existing SAP customer: The most near-term action item is understanding what the Dremio acquisition means for your data estate. Specifically: how much of your business data lives outside SAP today? If the answer is "quite a lot", which it is for nearly every organization, then the Iceberg-native Business Data Cloud architecture becomes highly relevant to your AI readiness. Get on the roadmap conversation with your SAP account team now, before these capabilities are generally available.

If you are evaluating ERP vendors: SAP's TFM bet is a meaningful differentiator in the 2027-2028 timeframe, not immediately. But the evaluation question is important today: ask any ERP vendor you are considering what their structured data prediction story is beyond LLM-based AI. The question will either reveal a thoughtful answer or reveal that they haven't thought about it.

If you are not an SAP customer: Do not dismiss Dremio's trajectory because it is now inside SAP. The open standards commitment means Dremio-based data architectures remain viable in non-SAP contexts. Watch whether SAP's integration approach over the next 18 months preserves that independence or quietly narrows the platform to favor SAP data sources.

If you are a data platform decision-maker: The Dremio acquisition raises the strategic importance of your Iceberg adoption timeline. Organizations that have already standardized on Apache Iceberg as their table format will find the integration into Business Data Cloud straightforward. Organizations still on proprietary formats (Delta Lake, Hive, legacy warehouses) should factor this development into their modernization roadmap.

On timing: Both transactions are pending regulatory approval and are expected to close in Q3 2026. Neither capability is available in production today. Do not let this announcement accelerate or delay operational decisions that need to be made in the next quarter. Use the time to build internal alignment on data readiness strategy.

MyPoV

SAP has spent years getting credit for being the system of record for the world's largest enterprises, and criticism for being difficult to integrate with everything outside its own walls. These two acquisitions are a direct response to that criticism.

The Dremio play says: we will be the data layer for your entire estate, not just your SAP estate. The Prior Labs play says: we will build the AI that actually understands the data that runs your business, not just the AI that talks about it.

Neither of these is guaranteed to work. Post-acquisition integration is where most ambitious platform strategies starve. The open-source commitments are credible today but have to be proven under commercial pressure. The regulatory timelines are a fact of life. And the €1 billion Prior Labs investment is a four-year commitment in an AI research environment that moves faster than any multi-year plan can anticipate.

But directionally, this is the right problem statement and a good approach to solving it. The data readiness problem exists The LLM-for-everything assumption is flawed for structured business data. And the open-standards position is defensible in a way that proprietary data platforms are increasingly not.

The question SAP customers should be asking isn't whether these acquisitions make sense. They do. The question is how fast SAP can execute the integration without losing what makes both companies valuable: the engineering credibility of an independent data platform and the academic rigor of a research-first AI lab.

That execution question will be answered over the next 24 months. Start watching now.

The most consequential enterprise AI governance document published this year arrived in late April with surprisingly little fanfare. SAP's updated API Policy, version 4/2026, is a short document in plain English. The clause that is most interesting is Section 2.2.2. It restricts how autonomous and generative AI systems are permitted to interact with SAP APIs. Read literally, it has the potential to change the architecture of agentic AI projects across every SAP customer landscape.

Read carefully, it is also more interesting than the lock-in headlines suggest. The policy targets a specific category of AI behavior, not AI as such. It connects to commercial mechanics that go well beyond API stability. And the literal text, in its current form, will probably not survive the next two policy revisions intact. There is a lot to unpack.

I will walk through what the policy actually says, how the SAP-watching community is reading it, what the rest of the major enterprise vendors are doing in comparison, what counts as an "endorsed architecture”, and what customers and partners should be doing about it now. I’ll close with a view on whether the policy can stand the test of time.

What Section 2.2.2 actually says

The operative sentence is direct. “Except through and within the limits of SAP-endorsed architectures, data services, or service-specific pathways expressly identified and intended for such purposes, SAP prohibits API use for interaction or integration with semi-autonomous or generative AI systems that plan, select, or execute sequences of API calls”. The same paragraph also prohibits scraping, harvesting, or systematic large-scale data extraction.

Three things flow from that. First, only Published APIs, those listed on the SAP Business Accelerator Hub or in product-specific documentation, are usable at all. Internal, private, and reserved-namespace APIs are out. Second, published APIs must be used for their documented purpose. Third, any agentic use of those APIs has to flow through SAP-endorsed pathways. The policy explicitly reserves enforcement rights including throttling, suspension, and termination of access. It also explicitly prohibits circumvention through proxies, intermediary services, custom code, or impersonation.

That is the legal fence. The interesting question is what it means.

The five readings circulating in the community

The professional discourse on this policy has organized into roughly five interpretations, and most of them are simultaneously true.

The first reading is that SAP is closing the back door on undocumented APIs. For years, real projects depended on internal SAP endpoints that worked in practice but were never officially supported. Marian Zeis, who maintains the curated registry of SAP MCP servers and runs one of the more careful technical blogs in the community, told The Register that “the changes are more restrictive than the community expected” and that SAP is too slow to publish or improve templates, leaving real projects dependent on undocumented APIs to keep pace with what their use cases require..

The second reading is more commercial. As SAP CX architect Jorge Ocampos puts it directly, SAP is not objecting to Claude, GPT, or Gemini. It is controlling the path through which agents touch SAP data and SAP transactions (Spanish). That path is BTP, Joule, AI Core, the Generative AI Hub, SAP Build, Integration Suite, and Business Data Cloud. The same agent running outside this stack may be non-compliant; running through it consumes AI Units under SAP's new consumption-pricing model. Snap Analytics reaches the same conclusion from the data side: all roads now lead to BDC. That’s cynical, but probably accurate.

The third reading is the lock-in concern. The Register captured this most directly, and DSAG, the German-speaking SAP user group, made it formal. DSAG's board went on record demanding contractual clarity (German), transition timelines, transparent fair-use thresholds, and protection for existing integrations. Their basic position is that SAP cannot announce that the SAP Business Accelerator Hub and product documentation govern customer architecture without first making those documents formal contract components.

The fourth reading is more sympathetic. The policy does not kill AI on SAP. It targets a specific category that practitioners have started calling attached AI, agents that plan, select, and execute API calls against productive systems, as opposed to detached AI, which helps humans understand SAP, generate code, search documentation, or design data models without touching live transactions. Distinguishing the two is the most useful conceptual move available right now. Most coverage skips it.

The fifth reading is procedural. SAP has created compliance fog by not publishing an enumerated whitelist. The phrase "SAP-endorsed architectures, data services, or service-specific pathways expressly identified and intended for such purposes" is doing enormous work, and right now nobody knows exactly what is on the list. That ambiguity is uncomfortable when enforcement can include throttling and termination.

All five readings hold. The policy is technically defensible, commercially self-serving, contractually ambiguous, conceptually sound for its stated target, and procedurally underdeveloped. Customers and partners need to internalize all five at once.

The attached versus detached distinction

This is the single most important conceptual handle on the policy, and it is worth slowing down for.

Detached AI is what most people are using today. ChatGPT helps a developer read an SAP help page. Claude drafts an ABAP method based on documentation. GitHub Copilot in agent mode edits a UI5 application. A community MCP server lets a coding assistant pull SAP documentation into context. None of this touches a productive SAP system. None of it is targeted by Section 2.2.2.

Attached AI is different. A LangGraph agent reads open purchase orders from S/4HANA OData, decides which to escalate, drafts a follow-up email, and posts updates back. A Bedrock-based finance agent calls invoice APIs, validates against vendor data, and triggers a payment release. A custom MCP server exposes SAP business objects to a general-purpose Claude or GPT agent, which then plans and sequences calls to mutate records. This is what Section 2.2.2 is talking about, and this is what now requires an SAP-endorsed pathway.

The distinction matters because most of the panic is misdirected. The customer who is running Copilot for ABAP development is fine. The customer who has a non-SAP agent platform reaching into S/4HANA over OData to execute business workflows is not, unless that path is routed through Joule, the MCP Gateway, BTP, or BDC.

How this compares to what other vendors are doing

Across the major enterprise software vendors, every player is doing something to govern agentic API access. The interesting observation is how differently they are choosing to do it.

SAP regulates the pathway. Section 2.2.2 demands that agent traffic enter through approved architectures. Salesforce, with one important exception, regulates the result. Agentforce sits behind the Einstein Trust Layer with per-conversation pricing and an Acceptable Use Policy that limits automated decision-making with legal effect. The exception is Salesforce's tightening of Slack data terms last year, which restricted external AI tools like Glean from indexing Slack messages. That move is narrower than SAP's, but it points in the same direction.

Microsoft regulates the gateway. The Azure AI Gateway, Agent 365, and the Microsoft Agents SDK are explicitly framework-agnostic. Microsoft's documentation advertises support for OpenAI, Anthropic, LangChain, Copilot Studio, and AWS or Google-hosted agents. The control mechanism is identity, observability through Entra and Purview, and token-rate limiting. ServiceNow is similar in spirit. The December '25 ServiceNow release added A2A v0.3 with tested interop against Vertex AI, AWS Bedrock, and Azure AI Foundry, plus recursive-loop protection for agents that might trigger themselves. Oracle has gone resource-bound, with default tenancy limits of two agents and capped tool counts per agent. HubSpot has gone outcome-based, charging roughly fifty cents per resolved conversation. Zoho's MCP server is explicitly model-agnostic.

In other words, every vendor is choosing a control point. SAP is alone in choosing architectural restriction at this scope. That is not in itself wrong. It is, however, a competitive contrast that Microsoft, ServiceNow, and the hyperscalers will exploit aggressively in CIO conversations over the next two quarters.

What counts as an SAP-endorsed pathway

The policy does not list the endorsed pathways. The SAP Architecture Center, the AI Golden Path, and product documentation do, and the working inventory is reasonably stable.

For published API access, anything on the SAP Business Accelerator Hub, plus product-specific documented APIs across S/4HANA Cloud, SuccessFactors, Ariba, CX, Concur, Fieldglass, and BTP services, used as documented. For the agent runtime stack, AI Core with Kubernetes-namespace-based resource isolation, the Generative AI Hub for foundation-model access with prompt registry and content filtering, AI Launchpad, the SAP Cloud SDK for AI, the SAP Cloud Application Programming Model, Joule Studio in SAP Build, and the BTP Cloud Foundry and Kyma runtimes.

For action and process, Joule itself as the orchestrator, Joule Skills for deterministic operations, SAP Build Process Automation and Build Actions, SAP Document AI, and the Document Grounding Service. For execution boundaries, the MCP Gateway running within Integration Suite, which is what enforces tool allow-lists, per-tool authorization, and human-in-the-loop approval before any system change. Also the Intelligent Scenario Lifecycle Management framework for embedded AI inside S/4HANA, where the data never crosses the system boundary.

For integration and eventing, Integration Suite with API Management, Event Mesh and Advanced Event Mesh, Cloud Identity Services with App2App tokens, and the BTP Audit Log. For data, SAP Business Data Cloud as the strategic foundation, BDC Connect for zero-copy sharing into Databricks, Snowflake, Microsoft Fabric, and Google Cloud Platform, Databricks-in-BDC, Datasphere, the HANA Cloud Vector Engine with authorization-aware row-level security, and the Knowledge Graph. For interoperability, A2A as SAP's preferred external protocol, MCP used internally with community and official MCP servers emerging including a planned official ABAP MCP server in Q2 2026, and the Joule Agent Gateway for inbound agent consumption from Vertex AI, Copilot Studio, and Bedrock. The Agent Gateway is not yet generally available as of this writing, which matters for anyone being told to use it today.

The architectural pattern shift this implies is straightforward. The old pattern was Agent calls APIs calls SAP. The new pattern is Agent calls a governed SAP pathway calls published APIs and events and data products calls SAP. More mediation, more logging, more SAP architecture in the stack, almost certainly more SAP spend.

The three situations and what to do about each

Customers and partners fall into three buckets, and the compliance work differs for each.

If your AI agents are built by SAP and run on SAP technology, this is the lowest risk category. Joule, the Sourcing Agent, the Dispute Resolution Agent, embedded agents in SuccessFactors and Ariba, all of these are inside the intended architecture by construction. The work to do is operational rather than architectural. Track Assist consumption. Document write-action approvals for finance, HR, procurement, and master-data. Press SAP for transparent, predictable pricing of AI Core capacity, foundation-model token consumption, BDC data egress, and the fair-use thresholds DSAG has been asking about (German). SAP-built does not mean risk-free. It means policy-aligned.

If you are a partner or ISV building on SAP technology, the work is to prove your architecture against the policy. Build a compliance pack for every solution. Inventory every SAP API, endpoint, connector, event, and integration artifact. Show, for each one, the link to the SAP Business Accelerator Hub or product documentation. Map every API to its documented purpose. Classify the solution explicitly: does it include an AI system that plans, selects, or executes sequences of API calls? If yes, identify the endorsed pathway used. Define write-action approval thresholds for anything financial, HR-related, master-data-mutating, or supply-chain-critical. Capture audit traces for every agent action. Get written confirmation from SAP for any gray-zone design choice. Verbal assurance from your account team is not contractual.

If you are running AI agents built on non-SAP technology, you face the highest-risk situation, and it is the one where the policy bites hardest. The safer architectural pattern is to separate reasoning from execution. Let the external Bedrock, Vertex, Copilot Studio, or LangGraph agent reason on data grounded through BDC, Datasphere, or HANA Cloud Vector Engine. Let SAP-controlled services execute. Use A2A into Joule for actions, not direct API orchestration. Use IAS App2App tokens, not shared service accounts. Implement human-in-the-loop gates for finance, HR, procurement, supplier master, pricing, payments, inventory, and production. Stop using undocumented APIs. The policy explicitly prohibits using proxies, gateways, custom code, or intermediary services to circumvent these controls, so the technical workarounds are not just policy violations, they are explicitly flagged as such by name.

A consequence worth pointing out is that the policy interacts with SAP Digital Access licensing. An autonomous agent that creates 10,000 invoice documents through SAP, regardless of where the agent itself runs, owes Digital Access fees on those documents. Section 2.2.2 controls the path; Digital Access meters the documents. The two are coupled. Customers who treat them separately will be surprised on their next true-up.

Will the policy stand the test of time?

My thinking is that the spirit of the policy is durable but the literal text is not, and the gap between the two will close through clarification rather than enforcement.

The legitimate parts of Section 2.2.2 are uncontroversial. Anti-scraping language, throttling rights, anti-circumvention clauses, and the principle that published APIs shall be used for their documented purpose are consistent with how every major SaaS vendor protects shared infrastructure. As autonomous agents proliferate, vendors that do not tighten these controls will face genuine availability and security crises. The risk that an unsupervised agent creates for an ERP system is real. SAP is not wrong to insist on execution boundaries and identity enforcement.

The restrictive parts run into headwinds. Enterprise architecture is moving in the opposite direction, toward open multi-agent meshes built on standards like MCP and A2A that are explicitly designed to make API-gated walls obsolete. The autonomous-agent restriction is unenforceable in its strongest reading because SAP cannot reliably distinguish agent traffic from human traffic on the wire. Enforcement will collapse to volumetric throttling, which the policy already authorizes directly, and contractual audits triggered by complaints, both of which exist already. And the policy contradicts SAP's own open-platform messaging; CEO Christian Klein walked the message back on the investor call (starting minute 53), stating that this policy mainly refers to SAP’s domain know how and not customers’ data, within days of publication, and DSAG has formally surfaced the contradiction.

My prediction is that within the next months, SAP issues clarifying material, starting with an updated FAQ and then a v5 policy, that does three specific things. It explicitly grandfathers existing partner solutions and customer integrations that pre-date the new policy. It defines "SAP-endorsed architectures" as a maintained, versioned list with deprecation timelines. And it softens the autonomous-AI restriction to a fair-use throttling regime plus an explicit anti-circumvention clause, dropping the architecture-bounded prohibition.

The longer the literal text stands without that clarification, the more competitive damage Microsoft, ServiceNow, Salesforce, and the hyperscalers will inflict by framing themselves as the open alternative for any enterprise that does not want to route every agent action through Walldorf's runway. The risk of an Indirect Access redux, where SAP burns customer goodwill in audit disputes over agent traffic that customers thought was compliant, is certainly there. SAP burned years of trust in 2017 and 2018 over that issue. Customers still keenly remember and are wary.

Closing read

The policy is technically defensible, commercially self-serving, and strategically fragile in its current form. The fragility is curable, and SAP can, and should, cure it, and fast. Doing this requires three things SAP can actually control: publishing a clear, maintained whitelist of endorsed agentic architectures and pathways; certifying non-SAP-runtime agent patterns through A2A, BDC Connect, and the MCP Gateway so that customers do not have to put every agent inside BTP to be compliant; and making the endorsed pathways genuinely valuable rather than merely mandatory. The BDC Connect zero-copy sharing into Databricks, Snowflake, Fabric, and GCP is the working blueprint for what good looks like on the read side. The harder challenge is delivering the same quality on the write side, where Joule and the MCP Gateway need to become the best way to execute SAP transactions from anywhere, not just the only compliant way.

SAP made the perimeter grab. Now it has to earn it. The next two policy revisions will tell us whether the company understood that or not.

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.

There is a moment in every technology cycle where a vendor decides the best way to signal relevance is to put the current buzzword in its name. We seem to be in that moment.

SugarCRM, the mid-market CRM vendor backed by Accel-KKR, just rebranded to SugarAI. The company declared that CRM as a category has failed to deliver on its 30-year-old promise and that AI makes a fundamental reset possible. CEO David Roberts frames it as moving from "AI as a feature" to "intelligence as the system."

That is a strong claim.

And a good claim!

Let us see what is behind it.

What Sugar Is Actually Saying

Strip away the rebrand fanfare and there are three substantial moves here.

First, Sugar is narrowing its identity around what it calls "precision selling." The concept: CRM should stop being a passive system of record that sellers resent updating and start actively telling them where to focus, what accounts are at risk, and what to do next. This is not a new aspiration in the CRM industry. What makes Sugar's version more interesting than the usual hand-waving is the second move.

Second, Sugar is leaning hard into the ERP-CRM bridge. The 2024 acquisition of sales-i gave Sugar the ability to ingest transactional data from over 180 ERP systems and surface revenue signals that traditional CRM cannot see. When a distributor's reorder volume drops 30% or a manufacturing customer shifts purchasing patterns, that signal lives in the ERP, not in the CRM. Sugar is betting that connecting these dots is where real value sits. Cameron Marsh at Nucleus Research called this "a pragmatic approach to AI," and he is right. It is one of the more grounded AI stories in CRM right now.

Third, Sugar is doubling down on verticals. Manufacturing, wholesale, distribution. Industries with long buying cycles, complex product catalogs, and deep account relationships. Industries that largely sat out earlier waves of sales technology because those tools were not built for their world. Sugar is saying: we are built for your world.

All three moves are coherent and mutually reinforcing. That alone puts this rebrand ahead of most.

The Name Problem

Here is where my enthusiasm somewhat decreases.

Every enterprise software vendor will have AI deeply embedded within 24 months. When that happens, having "AI" in your brand name will feel like calling yourself "CloudCRM" in 2024. Nobody does that, because cloud became table stakes.

The brands that age well are anchored to outcomes. Salesforce is about the sales force. ServiceNow is about service delivery. SugarAI is about... a technology ingredient. If Sugar can make "precision selling" synonymous with its brand the way Salesforce owns "CRM," the name not only survives, but can become category shaping. If precision selling remains a tagline rather than a category, expect another rebrand by 2029.

I give this name a coin-flip chance of lasting five years. The strategy underneath it is far stronger than the label on top.

At the very minimum, this rebranding becomes a conversation starter, gives some startup vibes and an internal catalyst to focus efforts, which are good things in themselves.

The Competitive Landscape Sugar Needs to Navigate

SugarCRM co-founder Clint Oram, who stepped away from the company in 2025 after 21 years, shared a competitive read that is worth examining.

He argues that the rebrand matters most in the context of Salesforce, HubSpot, Zoho, and Creatio. His take, in brief: Salesforce is a juggernaut where switching costs keep accounts locked. HubSpot serves a fundamentally different market (SMB, short sales cycles, inbound-first). Creatio owns the DIY ops buyer who wants to build processes, a segment Sugar moved away from years ago. And Zoho's horizontal "everything" brand cannot match Sugar's vertical depth.

He is largely right. But there is a significant gap in this competitive frame.

Microsoft Dynamics 365 is the competitor Clint does not name, and it may be the most dangerous one Sugar faces. In mid-market manufacturing and distribution, Microsoft already has native ERP (Business Central), native CRM, native AI (Copilot), and the entire Microsoft 365 productivity stack, including Teams that buyers already live inside. Sugar's anti-complexity pitch works well against Salesforce. Against Microsoft, that argument is harder to sustain. The buyer who runs their email, collaboration, ERP, and business intelligence on Microsoft will need a compelling reason to add a separate CRM vendor to the stack. This reason could be "precision selling".

SAP is another factor. Sugar targets verticals where SAP is the dominant ERP. If Sugar's story is "we bridge CRM and ERP data," buyers running SAP S/4HANA will ask why they should not just use SAP CX. The SAP CX suite has been struggling, which creates real opportunity, but SAP is not walking away from its installed base.

Freshworks competes at the lower end of mid-market with Freddy AI and a simpler deployment model. There is no direct ICP overlap, but Freshworks is moving upmarket and Sugar should be watching the rearview mirror.

And a word about Zoho. Zoho actively moves away from a horizontal approach and is building interesting ERP and AI capabilities, focusing its messaging around value. Along with the company's upmarket move, there is another one to watch out for.

What Precision Selling Needs to Become

The concept is sound, more than sound, actually. Its defensibility might become a challenge.

"Precision selling" as a term is intuitive and appealing. But it is also generic enough that any competitor could adopt it tomorrow. Salesforce could fold it into Agentforce messaging. Microsoft could embed it into Copilot for Sales positioning. The term is strong. The moat around it is shallow, unless there will be a trademark around it.

For precision selling to become a durable category rather than fizzle out as a campaign, Sugar needs three things.

Customer evidence. Five to ten reference customers publicly attributing measurable revenue lift to the ERP-CRM bridge and AI-guided selling. With the help of partners like Technology Coast Partners, this shouldn't be hard to achieve. Analyst placements (Nucleus Leader, Constellation ShortList) are necessary but not sufficient. Buyers trust other buyers more than they trust quadrants.

Product proof. The AI guidance has to demonstrably change outcomes, not just surface insights. There is a meaningful difference between "here is a dashboard showing your account is at risk" and "here is the specific action that will retain this account, based on what worked in 40 similar situations." Sugar needs to be on the action side of this divide.

Repetition at scale. Category creation requires marketing investment that a PE-backed mid-market vendor may or may not be willing to sustain. Accel-KKR's appetite for brand-building spend will determine whether precision selling becomes a market term or stays a Sugar term.

What Buyers Should Do

If you are evaluating SugarAI for your shortlist, here is how to cut through the rebrand noise. Start by ignoring the name. A rebrand tells you what a company wants to be. A proof of concept tells you what it actually is.

Ask for vertical references who can quantify results. it's not about logos on a slide but about customers in your industry who will tell you what changed after they connected ERP and CRM data through Sugar. No references, no result. Just a vision.

Backtest the AI. Ask Sugar to run their precision selling guidance against your last two quarters of actual deals. Would the recommendations have changed outcomes? Would at-risk accounts have been flagged earlier? Retrospective validation is the fastest way to separate signal from marketing.

Compare against Microsoft, not just Salesforce. If your organization already runs Dynamics 365 or Business Central, the integration cost of adding Sugar as a separate layer needs to justify itself against what Microsoft delivers natively. If you are not on Microsoft's stack, Sugar's independence becomes an advantage.

The Bottom Line

SugarAI is a better strategy than it is a name. The vertical focus, the ERP bridge, and the precision selling concept are coherent and differentiated. The brand name bets on AI remaining a meaningful differentiator in a world where it is rapidly becoming wallpaper.

The next 18 months will tell us whether Sugar built a category or just changed a logo.

Zoho aspires to deliver the operating system for businesses with the goal of driving customers' margins by unifying business operations on one single technology platform. The most important part for delivering this vision is Zoho One. 

Zoho One is Zoho's premier bundle of business applications. Currently, Zoho One consists of around 55 applications that support sales, marketing, email and collaboration, helpdesk and customer support, finance, HR, analytics, and business processes. Of these, customers use on average 22. 

Zoho One can be licensed as an all-in-one platform but also be part of a journey that starts at first licensing one application, then more and then moving to Zoho One directly or via licensing one of the other suites (such as CRM+, Projects+, Finance+, or Workplace, and others).

The most used applications in Zoho One are CRM, Analytics, Books, Meeting, and Workdrive.

At the time of writing this, Zoho One has around 75,000 customers, which makes it Zoho's most popular product. The largest customer has around 32,000 employees. Customers are distributed worldwide in more than 160 countries, with the highest numbers in the United States and the European Union. 

Organizations that have implemented Zoho One are from a variety of industries, although the top five industries are the high tech, professional services, Real Estate and Construction, Retail, and Banking/Financial Services/Insurance industries.

On November 18, 2025, Zoho announced many enhancements to the suite. The enhancements are focusing around three key areas:

·       Experience

·       Integrations

·       Intelligence

The biggest enhancement in the experience category is that Zoho essentially removes the boundaries between the 55 apps that are part of the suite with a concept that the company calls “spaces”. The objective of spaces is to unify parts of the overall user experience and thereby increase user productivity. A space groups a number of apps that are relevant for one or more purposes via a horizontal toolbar. It provides users with apps that are necessary to achieve business objectives in one single place. Spaces can be personal, e.g. for increasing one’s individual productivity, organizational, or departmental. Zoho delivers a number of customizable spaces. Customers can create their own spaces to better serve their needs and processes. 

Similar to this, boards remove analytical boundaries between the apps. A board is essentially a dashboard that can work across data from different applications. A good example for this are tasks, that can live in different applications and that can be brought into one single UI that allows contextual filtering via a board.

Similar to the boards, and to further facilitate the navigation and use across Zoho One, Zoho implemented an action panel and a quick navigation option, with the action panel aggregating action items across apps and the quick navigation speeding up navigation across applications.

Last, but not least, Zoho added Vani to Zoho One. Vani is a visual team space that enables teams to collaborate on documents and tasks.

On the integration side, Zoho now offers a view into all Zoho-to-Zoho integrations in one spot and offers to unify application-specific portals into one single portal that offers a central workplace across them. This portal covers Zoho applications, external applications, and custom-built applications. In addition, Zoho offers what the company calls pragmatic integrations. Pragmatic integrations allow to centrally configure integrations across Zoho One to external services, with domain verification being the first example. Last, but not least, Zoho introduces “outcome-based” integrations, which are basically cross-application workflows. With outcome-based integrations, customers can create cross-application workflows via a Zoho-provided wizard. This wizard takes care of the backend integrations while customers can concentrate on achieving the outcomes they want to see. This gets supported by an MCP server that exposes around 200 Zoho and third party apps ready to act as agents and MCP clients. 

In addition, Zoho unifies intelligence across Zoho One. AI capabilities across the apps are now available via Zoho One. Zia Hubs got enhanced to get its own space in Zoho One and supplementary workflows that make company data utilized. Zoho’s Ask Zia will soon be available in the bottom toolbar, allowing prompt-based searches across apps and providing contextual intelligence to guide decision making. 

Last, but not least, Zoho added a number of more technical enhancements, ranging from enabling customer-defined encryption, directory stores, cloud LDAP, cloud RADIUS and more. 

Analysis  

Zoho positions Zoho One as the operating system for businesses. While this is a bold statement, it was already largely true before this release. Still, since 2023, Zoho One has evolved a lot in terms of breadth and depth of its functional coverage without Zoho making much fanfare about it. The increasing number of customers (75,000, up from around 40,000 in 2023) and the fact that customers on average use 22 of its applications now are testament to the suite’s success. Zoho One certainly hits a sweet spot, also with its attractive pricing.

Want to know more? Read my full report here.

These days, we are drowning in conflicting information about the value of generative and/or agentic AI. I, myself am researching for good studies that dive into the ROI that is generated by this technology, with limited success. Most information is anecdotal, or comes from success stories, which cannot get used too literally.

Two major 2025 reports from MIT and Wharton, respectively, paint starkly different pictures of AI adoption and adoption success. While the meanwhile often quoted MIT NANDA “report” on the state of AI in business often gets quoted with 95 percent of all businesses not getting any ROI from their gen AI initiatives, a recent study by the Wharton Business School shows a very different result with 74 per cent of enterprises showing a positive ROI. Why is one so pessimistic and the other so optimistic? As I have written before, a closer look at the data reveals the 95% "failure" narrative is a myth, or even a scare, and the real story is probably a different and far more differentiated one, which Wharton names Accountable Acceleration.

Is GenAI really a 1-in-20 lottery ticket or is it rather a core business function? So, let’s have a look.

Methodology matters – debunking the 95% failure rate

In contrast to the NANDA “report” that relies on a fairly small sample of about 150 survey responses and 52 structured interviews, the. Wharton report bases on a large-scale, quantitative and longitudinal study. It surveyed around 800 senior decision-makers at businesses of different sizes and is tracking trends for the third consecutive year. Therefore, its data is built for statistically valid conclusions.

In addition, MIT NANDA’s rather sensational number of a 95 per cent failure rate is the result of a different focus. This “report” solely looks at custom, task specific agentic AI implementations that reach production state and measurable P&L impact. It does not look at the value of widely adopted generative AI tools like ChatGPT, Copilot or Perplexity. Instead, it dismisses their impact by labeling them as as tools that primarily enhance individual productivity, not P&L performance. And this, despite their obvious success that the report also identifies. 40 per cent of general purpose LLM implementations go into production with about 90 per cent of all employees using privately purchased licenses for ChatGPT, Perplexity, et. al. This is an indication that the corporate implementations are not exactly looking at the right pain points.

In contrast to this, the Wharton report identifies this as the primary source of value creation. Its data shows the top use cases are data analysis, content creation and its summarization and presentation (p. 30). This is the ROI. The MIT report is like arguing 95% of companies get no return from email because it only boosts individual productivity. This doesn’t make much sense as an increase in productivity is a return. Wharton, in turn, identified how businesses identify and measure ROI and found that almost 75 per cent of all businesses report a positive return on investments, with smaller businesses (p. 45) and some industry sectors (p. 47) seeing a higher return. But the picture is clear.

The ROI story – mainstream and measured

Given all this, the Wharton study seems to be a far more credible source of information about the current usage and ROI of generative AI. There is only a small fraction of businesses that sees a negative ROI, with some businesses seeing it as neutral or too early to assess.

The numbers vary across industries, but the general picture is clear. Generative AI is not a high-risk gamble. On the contrary, if implementations are managed appropriately, it does deliver results and consequently, Wharton concludes that we have now regular usage in core business operations, with embedded ROI metrics. More than 70 per cent of the surveyed organizations are formally measuring ROI, with a focus on productivity gains and incremental profit.

There is both, an increasing usage of generative AI and a continued significant investment, including into own research and development. Wharton dubs this phase as “accountable acceleration”, moving on from exploration- and experimentation-oriented phases in the previous years. I guess, there needed to be a catchy marketing phrase …

And, as said above, it’s showing results. Of the surveyed businesses, 74 per cent are seeing positive returns. This includes 35 per cent reporting "significantly positive ROI" and 39 per cent "moderately positive ROI". This data flat out contradicts the 95 per cent failure narrative of MIT NANDA. Apparently, we are not looking at a divide with a 95 per cent chasm but rather a far smaller spectrum of adoption speed and maturity.

Buy – or rather build?

Now that we are clear about well-managed generative AI initiatives showing a positive impact, the make or buy question looms again. NANDA quite unequivocally says “buy”, as they find that the failure rate of custom implementations is double the failure rate of strategic partnerships with a vendor and systems integrator.

Wharton roughly shows an equal distribution of efforts in new technology, enhancing existing technology and internal research and development efforts.

Which is not necessarily a contradiction, as it basically says, “buy and adapt”. Some scenarios can be supported by delivered software, some needs training or fine tuning, other models need to be specifically built.

Businesses are adopting a far more sophisticated hybrid strategy than simply make or buy. Firms are not just "buying" off-the-shelf tools; they are investing significant capital to build custom, proprietary solutions that drive competitive advantage.

The MIT report's "buy, don't build" advice, in contrast, is very simplistic. While I stick to the recommendation that I made in my article Beyond the Hype: Unlocking GenAI ROI in the Enterprise, the truth is more nuanced. It is basically the same as for the implementation of enterprise software in general. Stick to best practices where there is no significant or lasting competitive differentiator and invest into custom implementations where a differentiator with a competitive advantage lies.

The real barrier

Which leads us to what prohibits businesses from taking even more advantage from the use of generative AI. As Wharton shows, the main problem is not the technology, at least not only. There are credible studies that show a decreasing likelihood of success with increasing complexity of the modeled scenario, including CRM-Arena Pro and TheAgentCompany, but then these agree with the Wharton findings that success is very well possible.

The technology is mostly ready.

The real barrier is people and organization – essentially corporate culture. Management needs to set an example, people need to be educated and, very importantly, governance needs to be in place that both helps the users and protects the business. This requires change management. According to Wharton, the toughest challenge facing businesses are a lack of skills, employee fear for their jobs and management’s ability to constructively manage the necessary change by convincing the employees that the use of AI is not about technology grabbing their jobs.

From sensationalism to strategy

What we can confidently say is that the generative AI landscape is not as dystopian as the NANDA “report” makes it appear. This narrative is created on a too small data set and a questionable definition of “value”. It is fundamentally biased by an underlying agenda – which comes from the authors pointing a way into their solution of overcoming the technology problem. The Wharton "Accountable Acceleration" study provides the more data-driven, and optimistic view. Generative AI has gone mainstream. The return of investments can get measured, is being measured, and it is proving positive, with few exceptions.

The "GenAI Divide" isn't a chasm between success and failure, caused by poor technology.

It is rather a spectrum of maturity and of connecting investments into generative AI into strategic business KPIs. And, of course, selecting the right problems to solve. The real challenge is not to find a silver bullet that automagically solves business challenges. It's the boring work of business transformation. It is about investing into and aligning people, investing in training, setting smart guardrails, and executing a hybrid build and buy strategy.

This is the real, actionable roadmap to success.

If you want to explore, how this roadmap could look like for you, get in touch with me for an informal conversation.

Before immersing myself into SAP Connect 2025, I had a number of questions that I would like to get answered during the event. These included the ones below and naturally focused on SAP’s CX and AI sides of the house. Some of them I got answered, some of them not, at least not explicitly.

• What is the plan to make SAP CX more prominent in the CRM/CX marketplace and what are main reasons that you see for customers preferring other CX solutions over SAP’s?
• What do customers say that they are missing in the CX suite?
• Where do you see the limits of agentic technology in the near to mid-term? Apart from adoption problems …
• And where do you see most potential for agentic AI going forward?
• What are adopted (agentic) use cases that concentrate on business transformation, gaining capabilities, uplift as opposed to “increasing efficiency”?
• How does SAP deal with the dichotomy between “human augmented by machine” and mass layoffs?
• SAP Consulting as well as SIs do face a need to change their business models away from billable hours. What do you recommend SIs do? How does SAP support them in this venture? How do you foresee the overall ecosystem change with an estimated increase of use and deployment of generative and agentic AI

But more about all this in a minute.

Of course, SAP took this event to announce a flurry of new capabilities across its suite of applications, AI, and technology, as evidenced in the long innovation guide and the theme-describing press release for the event, although I’d say that the event went well beyond “AI that partners with people, data that defies boundaries and applications that turn data into action”. To be sure, SAP Connect extended on the vision that got outlined during last Sapphire.

True to its name, SAP Connect was about connecting – or breaking, to use a stronger word – the silos that are imposed by different types of business software, predominantly, but not only, SAP’s business software and in extension the silos between business departments, The approach was to co-host conferences focusing on the different lines of business while providing the connecting tissue by means of cross references, supported by customer testimonials, in the keynotes.

And I want to say that this largely succeeded. Jon Reed wrote a great piece covering this using Heartland Dental as an example. Other customers like Migros or confirmed their success that got achieved through cross departmental collaboration. “Collaboration is a very, very key for service. We promote support cross-functional collaboration, that begins from idea, of course, but all colleagues from marketing, business and also colleagues from the stores but we work also together with other legal entities in our group, for example, of a work together, very tightly with the bank. And so, we work together with our financial colleagues in the context of practical credit card format is an integrated part of our loyalty program and so it's very important to get them common understanding and the common understanding is also based on a common technology. Baseline we work on a common data Lake. We have Cloud platforms, and this is also the key for a common understanding, for a 360-Degree of our customer view”. Similarly, Wella. Both of them part of the CX keynote.

Or, looking at supply chain processes, SLB, Red Bull and HP. All of them look at cross-functional cooperation as a critical success factor.

And these have only been some examples from the keynotes.

This is powerful support for the SAP E2E story. The only way to tell this even more powerful is to actually embed deep references into other lines of business within these key notes, e.g., closing the loop between demand (CX) and supply including finance. Basically, showing how the different SAP portfolios strengthen each other in a synergistical way.

This would emphasize on the power that the integrated capabilities that SAP commands have. After all, there are at best 2 to 3 companies that can dare telling a story like this: Oracle, to some extent Microsoft on an enterprise level, and Zoho with a bit more of a mid-sized focus for now. This is a tremendous opportunity for SAP, but one that requires not only having the capabilities – which SAP has – but also a messaging that does not disregard a crucial part of any business. An end-to-end story works only if it is supported by an equally strong story for each part of the business.

Ok, Connect works, but how about CX?

Having said this, let’s dig into a topic that is dear to my heart. For a long time, I have been saying that SAP treats its CX suite as a kind of Cinderella – the unwanted stepdaughter. The story being a fairy tale, it has a positive end. Does SAP’s CX suite now get the recognition it deserves?

Since last Sapphire, my view is slowly changing. CX appeared in Christian Klein’s Sapphire keynote, albeit not very prominently and had a more significant experience in Muhammad Alam’s keynote during SAP Connect, which you can revisit in Jon’s watch party with Josh Greenbaum and Bonnie Duncan Tinder that covers it extensively including valuable commentary. As said, giving CX a more prominent place is important, as it is a key ingredient of an E2E story and functionally an indispensable part of any business. There also have been significant announcements with a new loyalty solution, an engagement cloud, a digital service agent, WalkMe being made available for the CX solutions and an interesting revenue intelligence app on the SAP Business Data Cloud. My recommendation is to build on this momentum and to also have Christian Klein put more emphasis on CX going forward. No voice gets heard better and lends more credibility than the top dog’s CEO’s (sorry, Jon, I couldn’t resist using one of your techniques here). Having talked to the CP of  SAP CX, Balaji Balasubramanian, SAP CX Head of Product Strategy Riad Hijal and the new SAP CX CMO Jessica Keehn, I see the outlines of a plan going forward. I am keen to observe it come to fruition (and perhaps help, too?). One thing is for sure, during Sapphire and also during SAP Connect, there was an emphasis on becoming category leader where SAP invests. And there surely are considerable investments into SAP CX.

What about AI?

As part of the press release for this event as well as throughout keynotes, Q and A’s and individual discussions with SAP executives, there is one consistent theme: “AI that partners with people”, or in other words humans are getting help from technology instead of being replaced. This is a very laudable messaging although it is doubtful that a vendor, even one as powerful as SAP, is able to prescribe customers what to do with its technology. It is the buyers’ choice whether they follow this philosophy … or not. Alam and other executives repeatedly emphasized that their objective for using their own AI technology is not replacement of people. Instead, they aim at increasing their organizations’ outcomes by making their team members more productive. SAP COO Sebastian Steinhäuser presented some impressive numbers during his keynote. Apparently, SAP made its flywheel of apps, data and AI work for itself. From a limitation point of view, SAP bets big on the Business Data Cloud that is to deliver clean, consistent, reliable data as the foundation for well-working and collaborating agents that “help execute complex workflows within a specific function”.

For SAP, as well as its competitors, the challenge remains to not fall into the trap of explaining major layoffs as a result of the efficiency gains through their AI. Doing so, would destroy the narrative of AI creating business results through being a helper, not replacement, of people, and thereby the credibility of the tellers of this story.

And what about partners?

SAP has always been strong about ecosystem and partnerships. Given, that AI is all about platform, it makes an ecosystem play even more important. However, the ecosystem changes. IP becomes ever more important, especially over integration services. These get increasingly supported by AI, which requires SI’s to rethink their business models. They need to change from IP that “lives” in the heads of consultants and enables billable hours to IP that is encoded into software and AI. This requires them to adapt to survive and to continue to thrive. SAP encourages them to do this change and to create their AI infused solutions. To be frank, I expect the importance of SI’s in the SAP ecosystem to reduce in favor of ISVs. In future, implementations will require less effort and will have a higher degree of automation. Consulting will be again what it was, becoming more strategic again and less about the nitty-critties about implementing the desired solution. Not having had the chance to go in depth into a detailed discussion, this is probably a topic for another article or a few LinkedIn posts.

Famous last words

I think that SAP came in strong during this conference. The flywheel tells a sound story, and SAP is uniquely positioned to make this vision a reality. Are there pitfalls along the way? For sure. Will SAP trip into some of them? Probably. Will it matter? Likely not. For SAP, as well as for other businesses the game to play is adapt and overcome. And this is something that SAP can do. The company has shown it numerous times.

The remaining proving ground remains CX. There is considerable investment, competitive, in some areas even leading functionality. What is missing is, credibility. As one colleague this week told me “As far as I am concerned, SAP doesn’t have CX solutions”. Ouch. That needs to change.