Every AI CRM vendor selling into 2026 has an AI agent story by now. The differentiator is no longer whether agents exist, but who is allowed to build the next one, how long that takes, and what happens to the bill once it works. For decades, CRM has promised growth and mostly delivered data entry, decaying from a system of action into a system of record. The agentic shift changes that, and with it the questions buyers should ask. Let’s put Creatio's AI CRM to those questions, following a deal from lead to order to see how much orchestration ships out of the box and how much a revenue team must assemble. The findings are published in full in my report, AI CRM for Revenue Growth: Inside Creatio's AI-Native No-Code Platform.

The company behind the platform

Creatio is a privately held, AI CRM and no-code workflow automation company headquartered in Boston, founded in 2014 by Katherine Kostereva, who remains CEO. It ran as bpm'online until a 2019 rebranding, bootstrapped until its first institutional round in 2021. A $200 million round led by Sapphire Ventures in June 2024 lifted its valuation to $1.2 billion; total funding raised now stands at roughly $268 million, and it reported around 50 percent year-over-year revenue growth at the time.

Creatio employs around 1,000 people and sells through more than 500 implementation partners worldwide. The company’s partner program has held a 5-star rating in CRN's Partner Program Guide for eight consecutive years. Customers span more than 100 countries, among them AMD, Colgate-Palmolive, and MetLife, with millions of workflows launched daily.

One platform, two studios

The product serves marketing, sales, and service on a single unified data model. Creatio Studio sits on top, split into Business Studio for no-code applications and AI Studio for autonomous agents, both sharing one data, security, and governance model. An in-app AI Twin now lets end users build their own agents from an IT-approved library without leaving the CRM. What makes this an AI CRM rather than a CRM with AI attached is where the intelligence sits: Creatio combines predictive, generative, and agentic AI in a single Creatio.ai architecture, reachable by end users in natural language, instead of bolting a chatbot onto a system of record.

Two authoring patterns cover most agent use cases. Prompt agents are simple assistants defined by a natural-language instruction plus the tools and skills the agent is allowed to use. Workflow agents are multi-step processes built on the same drag-and-drop designer that powers the rest of the AI CRM. Both are built by the same business-side practitioner who already configures pipelines and dashboards. There is no separate developer queue, AI-specialist hiring profile, or code repository in the middle.

Creatio was named a Leader in Nucleus Research's November 2025 LCAP Technology Value Matrix, and it was the only Leader in Forrester's 2024 Wave for low-code platforms built for citizen developers. That recognition shows up in practice too: BSN Sports runs its entire deployment for 2,600 users with just three administrators, while Howdens rolled out to 7,000 users across more than 800 depots in twelve weeks. Nucleus has separately measured 61 percent faster lead response, 70 percent faster implementation, and 37 percent lower total cost of ownership against legacy systems. Industry editions — including an agentic banking Solution that provides the basis for a Banking Blueprint that covers onboarding, lending, and KYC/AML — extend the platform into regulated sectors.

The pricing bet

In 2026, Creatio introduced an Unlimited plan tied to its Unlimited Enterprise operating model. One subscription covers unlimited users, custom agents, applications, workflows, custom objects, and API calls as a single platform fee, with AI included rather than metered. Beneath it, credit-based consumption is the default and per-user licensing remain available; AI Studio and AI Studio Twin add no incremental license.

The test: five agents, one deal

To test the authoring claim directly, I looked at a five-agent scenario across a single deal's lifecycle, combining shipped Creatio.ai agents with customer-specific ones authored in AI Studio:

• An ICP-fit agent and an engagement-fit agent jointly qualify inbound leads, built on Creatio's Account Research and Lead Scoring agent patterns, promoting a lead to sales-accepted once both clear their thresholds.
• An opportunity-health agent layers S/M/L risk sizing on Creatio's native MEDDPICC scoring, reads the opportunity record and call transcripts, and gates stage advancement until the criteria are met.
• A SPIN-style coaching agent proposes concrete next moves on a stalled deal but cannot act without rep approval.
• A service-brief agent, built on the shipped Customer Support and Knowledge Base agents, compiles ticket history, sentiment, and invoice status into an on-demand pre-call summary.

All five are registered, monitored, and governed in Creatio's unified administration layer, with PII policy, approval gates, cost thresholds by agent and model, and audit logging applied uniformly, whether the agent shipped with the product or was authored in-house. Each customer sets the rigidity, from letting agents auto-transition stages to requiring a human at every gate.

How the competition does it

Most competing approaches to agent-building fall into one of three patterns:

• an agent designer wired tightly to a fixed data model, as with Salesforce's Agentforce and ServiceNow's AI Agents;
• a horizontal builder paired with a separate CRM, as with Microsoft's Copilot Studio and Dynamics 365; or
• a pro-code toolkit that still needs the engineering capacity it was supposed to eliminate.

Each carries a trade-off: opinionated designers constrain any customer whose process diverges from the vendor's reference, horizontal builders mean stitching two governance models together, and pro-code toolkits demand the scarce engineers they promised to free up. Creatio's pitch is that collapsing the AI CRM, the data model, the process engine, and the AI authoring layer into one product, governed from one console, sidesteps all three.

Analysis

The architectural claim holds up on inspection: governance, authoring, and the AI CRM itself sit in one architecture rather than three, which is a structural condition most agentic CRM vendors talk about, but few actually deliver.

The Unlimited Enterprise pricing model is the more interesting bet, however. It shifts the conversation from seats to execution at a moment when every competing consumption model bends upward exactly as AI adoption succeeds. The caveat is that Creatio's own default is AI credit-based consumption, so the unlimited promise and the metered tier still need reconciling. Whether it holds as genuinely unlimited at scale is the open question I would flag for any multi-year commitment.

The weaker spots are predictable for a company this size. Brand recognition in the upper enterprise and the North American mid-market still trails the legacy CRM incumbents, and delivery runs through that partner network, where outcomes vary with partner maturity. Neither is disqualifying, but both belong in a buyer's due diligence.

The AI CRM category itself is still being defined, so the more durable test isn't feature count. It's whether this architecture and this commercial model survive contact with deployments larger than the reference customers cited above.

Want the full picture, including the complete five-agent scenario, the competitive comparison, and the SWOT? My full report is available for download here.

The Ghost of Cluetrain

In 1999, the Cluetrain Manifesto famously declared that "markets are conversations." It was an inspiring, romantic notion that promised to democratize commerce, wresting power from faceless corporate monoliths and handing it back to a sovereign consumer. Fast forward to today, and that conversation has been thoroughly co-opted. What was supposed to be a bilateral dialogue has devolved into an automated, highly-optimized monologue. The emergence of agentic AI, which features autonomous software agents supposedly operating on our behalf, promises a return to that original democratic vision. But let us be honest: is this actually a revolutionary shift, or is it just another iteration of vendor-controlled slop designed to monetize our decisions before we even make them?

The dream of conversational commerce was simple: technology enables humans to speak to other humans at scale. Instead, the vendor community realized that humans are expensive, inconsistent, and prone to demanding fair treatment. The corporate response was to replace them with IVR systems, chatbots, and automated messaging. These tools were never designed to foster actual conversations; they were designed to create efficient deflection barriers. Now, we are told that generative AI and agentic systems will change all this by acting as our personal proxies. But will it come true?

TL;DR

If you want to watch the full CRMKonvo, please go ahead here (optimized for smartphones) or here (optimized for tablets/computers).

Else, be my guest and continue to read.

Or do both …

The Illusion of Agentic Agency

During our recent CRMKonvo with Dan Miller, founder of Opus Research, we wrestled with this paradox. We have been apocaloptimists when it comes to conversational AI, marveling at the technology's ability to improve our lives while ignoring its potential as a tool for corporate surveillance. The simple truth is that the economic incentives of surveillance capitalism remain unchanged. When a vendor provides you with an "autonomous assistant" to help you shop, that assistant is not working for you; it is a digital Trojan horse. It is programmed to maximize the vendor's margins, steer you toward high-commission partners, and dynamically adjust prices based on your historical data. They call it serving you better; in reality, it is just more sophisticated extraction.

This is where the asymmetry of power becomes glaringly obvious. The consumer enters the arena with a simple objective: to find a quality product at a fair price. The vendor enters with predictive algorithms, historical CDPs, and agentic bots designed to extract the maximum possible lifetime value from that specific consumer. When these two forces meet, it is not a conversation; it is a “negotiation” where one party has access to the other's entire cognitive blueprint. If your personal shopping agent is hosted, managed, or trained by the same corporate infrastructure it is supposed to negotiate against, your agent is effectively a double agent.

The Guardrail Paradox and the Friction of Safety

One of the most fascinating aspects of our discussion centered on the concept of guardrails. In theory, guardrails are designed to protect users, prevent systemic bias, and ensure compliance. In practice, they are a friction point. If you are a malicious actor, or a vendor looking to maximize short-term profit, you do not want guardrails; building and maintaining them requires computational and human effort. Consequently, the path of least resistance is to deploy systems with minimal oversight and dealing with the possible fallout later. When they put restrictions in place, they often reduce legitimate user choices instead of protecting the user.

This creates a bizarre scenario where the consumer is locked in a digital playpen, restricted by strict guardrails on what their agent can ask or do, while the vendor's algorithms roam free in the wild west of data exploitation. The guardrail paradox is that by trying to make AI safe, we often make it useless for the consumer while doing absolutely nothing to stop the vendors from using unbridled models to leverage market dynamics. It is an asymmetric conflict: the defensive side must comply with every rule, which are set by the offensive side.

The 'Trusted Agent' in a Corporate State

Senator Warner and others have proposed regulatory frameworks that would authorize approved entities, be they banks, credit card issuers, or the vendors themselves, to host "trusted user agents." This is a farce of epic proportions. How can anyone believe that a vendor-hosted agent will prioritize the consumer's interests? The Martech community has spent decades building systems to capture, analyze, and exploit user data. To expect these entities to host an objective, consumer-first agent is akin to asking the fox to protect the chicken coop.

Such proposals do not democratize AI; they institutionalize the power dynamic favoring the vendor, dressed up in the shiny new clothes of trusted agentic technology. The vendor-hosted agent will inevitably suffer from a conflict of interest. It will prioritize the products that yield the highest margin, mask competitive alternatives under the guise of "simplifying choice," and feed our preferences back into the corporate data lake. True consumer agency cannot exist within a closed corporate ecosystem. It requires independent, decentralized, and locally run models that answer to no one but the individual user.

Pay-to-Play Algorithms and the Opacity of LLMs

Let us look at a concrete example of how this plays out in the real world. Generative AI led to the discipline of GEO (generative engine optimization) to ensure being highlighted in search feeds and assistant recommendations. This is the reality of a black box. When you ask a modern LLM for a product recommendation, you have absolutely no way of verifying why it chose a particular vendor. There is no transparent ledger of recommendations. It is entirely possible that the recommendation you receive is the result of an agreement between the LLM provider and a corporation.

As long as these models remain opaque, any promise of objective personal assistance is a marketing myth. The algorithms are trained on data that is already heavily skewed by advertising dollars and SEO manipulation. Therefore, when an agentic bot uses it, it is recycling corporate propaganda, presenting it as unbiased advice. This is not artificial intelligence; it is automated salesmanship. To combat this, we need absolute transparency in how recommendation engines operate, including a public ledger of all corporate sponsorships and algorithmic biases that influence the output. A tall order.

The Scalability Farce of Manual Compliance

Even if we establish clear privacy guidelines, such as the right to be forgotten or standard opt-outs like in the GDPR, e.g., implemented using the IEEE My Terms standard, the enforcement mechanism is broken. If a consumer requests that their data be deleted or excluded from training sets, how do they verify compliance? They cannot. If you send a compliance request to a trillion-dollar tech company, that request likely lands on the desk of an understaffed compliance team using a manual process to scour databases, call transcripts, and unstructured chat histories. This does not scale. It is impossible for these enterprises to manually comply with millions of granular privacy requests.

The vendor's SOP will be to say they complied. Yet, once your data has been ingested into an LLM, it is practically impossible to "un-train" that model on your information. The data becomes an inseparable part of the algorithmic weights. Therefore, any regulatory framework that relies on retroactive compliance is a toothless tiger. We must shift the battleground from retroactive deletion to proactive, systemic prevention.

VCONs and the Architecture of True Data Sovereignty

If we want consumer agency, we must shift the paradigm. This is where technologies like Virtual Conversations (vCon) become critical. A VCON is a standardized, secure digital container that houses the transcript, audio, and metadata of a conversation. Crucially, instead of relying on a vendor's pinky-promise to respect our privacy, the data itself is encapsulated with its own governance rules. This is a step toward true data sovereignty, but it requires a massive cultural and technical shift.

Conclusion: Taking Back the Loop

The term "human-in-the-loop" is frequently used to describe safe AI integration. But as agentic AI evolves, we are moving toward a world where humans are removed from the loop, replaced by autonomous agents transacting with other autonomous agents. If we do not demand models that genuinely operate on our behalf, we will find ourselves shut out of our own decision-making processes. This is time to stop being passive consumers of AI convenience and start being active architects of our digital autonomy.

Pragmatic Playbook for Enterprise CX Buyers

Enterprise buyers are currently being bombarded with vendor pitches promising that agentic AI will magically solve their customer experience woes. If you are a buyer and concerned about ethical AI use, here is your survival guide to avoid making an expensive, possibly brand-damaging mistake:

Prioritize Architectural Integrity Over Hype: Do not be seduced by an agent's ability to generate natural-sounding excuses. Demand to see the integration map. If the agent cannot access your back-office CRM and ERP data securely and deterministically, it is not an agent; it is a glorified chatbot with a larger vocabulary.

Mandate Strict, Verifiable Data Boundaries: Ensure that your customers' data is never used to train a vendor's public LLM. If the vendor cannot guarantee and prove that your proprietary customer interactions are kept in a secure, isolated RAG environment, walk away. Your customer data is your competitive moat; do not give it away to train your competitor's next model.

Implement 'Agent-in-the-Loop' Safeguards: Autonomous agents are highly efficient at going sideways before they go south. Never deploy an agentic system in a customer-facing role without a deterministic routing mechanism that instantly escalates complex, emotional, or high-value interactions to a well-trained human agent, complete with full conversational context.

Insist on Standardized Metadata and vCon Support: Prepare for a future of decentralized data. Your architecture should support standard containers like vCons to ensure that as consumers demand greater control over their conversational data, your systems can comply programmatically rather than relying on manual, unscalable processes.

TheStreet ran a piece this week arguing that, of Microsoft's two Copilot announcements, the shift to usage-based pricing matters more to investors than the DeepSeek flirtation. That read is correct. It is also the tell.

Here is what Microsoft actually did. Copilot Cowork, the agent that reaches across Microsoft 365 to run multi-step work on your data, is coming off the flat per-seat add-on and moving onto consumption billing the company calls "Copilot Credits." Charles Lamanna, who runs Copilot, told Axios the product could not be offered on an unlimited-use basis. The users he pointed to are the ones doing hundreds of tasks a week. He called them "way productive." And then he said the part vendors normally keep off the slide: their costs go very high.

So the most productive users are the expensive ones. Hold that thought, because the whole argument lives there.

What "good for investors" is really saying

A pricing model earns the label "good for investors" when three things are true. Revenue starts to track cost-to-serve. Revenue scales with consumption instead of sitting flat per seat. And the vendor stops eating the margin on its heaviest users. All three are true here. None of them is a statement about whether a customer got value.

That is the gap I want to sit in for a minute.

Usage-based pricing meters an input. Tokens, compute, credits, whatever the unit. The customer does not buy tokens because they want tokens. They want a finished report, a resolved ticket, a reconciled spreadsheet. The token count is the cost of producing the outcome, not the outcome. And the relationship between the two is loose at best.

TSIA put it plainly in its May analysis of AI pricing: usage does not equal value, and consumption models often fail to reflect actual business value. That is not a critic talking. That is a research firm whose audience is the vendors building these models.

Agents make the coupling worse, not better

A chatbot answers and stops. An agent keeps going. It reads files, calls tools, checks its own work, hits a wall, tries again. Each of those steps burns compute, and the steps are what get metered. Every retry, every verbose detour, every loop the agent runs to second-guess itself adds to the bill. The customer pays for all of it.

Now ask yourself the hard question. Does a workflow that took the agent three retries and a long chain of self-checks deliver more value than the same workflow done cleanly in one pass? Of course not. It delivers the same outcome and costs more. Under seat pricing, that inefficiency was the vendor's problem. Under usage pricing, it is line-itemed onto the buyer's invoice.

The billing platform Flexprice, which sells the plumbing for this, says it out loud to its own customers: retries, loops, and background jobs are friction, not value, and usage-based pricing only works when customers gain something real as the meter climbs. Their warning to vendors is the buyer's whole case.

The people who get punished are the people who bought in

We do not have to guess how this lands, because GitHub Copilot already ran the experiment. On June 1 it moved to token billing. The median user barely noticed. The pain landed on the top five to ten percent, and it landed hard: community projections of bills jumping ten to fifty times, one developer modeling a move from roughly $29 a month to nearly $750, another claiming $50 to $3,000. TechCrunch called it the end of Copilot's golden age.

Look at who those heavy users are. They are not abusers. They are the people who took the vendor's three-year advice to use the tool for everything, built agentic workflows around it, and made it part of how they work. The pricing change penalizes exactly the depth of adoption every vendor claims to want. And the old safety net, where running out of premium budget dropped you to a cheaper model so you could keep working, is gone. What is gone, too, is the cost ceiling.

Lamanna's "way productive" power user and GitHub's top-decile developer are the same person. The model charges most to the customer who is succeeding most. Reward and penalty have swapped places. The reward now goes to the vendor.

The structural problem, which is bigger than the bill

Now the second half, and this part is more important than any individual invoice.

Think about where accountability for value sits in each pricing model. With outcome-based pricing, the vendor gets paid when a result lands and not before. Fin's (formerly known as Intercom) Fin charges 99 cents per resolution, billed only when the customer confirms the AI actually solved the problem. Under that model, every failed attempt costs the vendor. So the vendor has a direct, financial reason to make the agent efficient, accurate, and sparing with compute. Their margin depends on it.

Usage pricing inverts that incentive. The vendor is paid for activity regardless of whether the activity worked. An agent that burns more tokens, retries more often, and reasons more verbosely produces more revenue, not less. I am not claiming Microsoft will deliberately bloat Cowork to pump credits. I am saying the financial pressure that used to push toward lean, effective agents has been switched off; and switched-off incentives have a tendency of showing up in the product eventually.

The demand side pulls in the same direction. There is a name for it now: tokenmaxxing, the workplace habit of treating AI usage as a proxy for productivity, where people get judged on how many token they burn rather than on what they shipped. Built In's writeup is blunt about it: the habit rewards visible activity, not results. So stack the three forces. Buyers under pressure to run up consumption as a status signal, a vendor that meters by consumption, and an agent that inflates consumption on its own. Everything drives the meter up. Nothing points it at the outcome.

That is the real cost of the model. It moves the vendor one step further from owning the question of whether you got value, and it hands that entire question to you. The vendor essentially plays Pontius Pilate. The buyer now runs FinOps for AI. You set the budget caps. You write the spending policies. You read the consumption dashboard. You type /cost to see what a task burned. Microsoft, to its credit, is shipping all of those controls, and they are better than the ones GitHub fumbled out the door. But notice what they are. They are tools for the customer to govern value. They are not the vendor guaranteeing it.

The honest counterargument

I would be doing the same vendor-spin thing I just criticized if I left out the other side.

Flat pricing for agentic tools is inherently unsustainable. The economics are upside down: the model subsidizes the heaviest five percent and overcharges the lightest fifty. Metered billing is the rational fix for that, and for a low-volume or experimental buyer it is a better deal than paying a fat seat fee to barely use the thing. Aligning price with cost-to-serve is a good thing. It is just a vendor virtue, not a customer one, and the trick to watch is anyone presenting the first as if it were the second.

Cheaper models do not solve the coupling problem. A fine-tuned DeepSeek on Azure lowers the unit price of the metered thing. It does not make the metered thing track value. You are paying less per token for a number that still has a loose relationship to your outcome. And who knows how many additional tokens a potentially inferior model burns.

Where this lands

On my orchestration battleground, Cowork is the M365 layer that coordinates work across your apps and your Graph. Pricing that orchestration by consumption reframes it from a capability you own into a utility you rent by the drink. That is a substantial shift in who carries the risk when an orchestrated workflow goes long, and it is the buyer.

So, on the null hypothesis. Is usage-based pricing good for customers? Largely no, and for the reasons the question assumed. The metered unit is loosely coupled to value, agents widen that gap rather than closing it, the model bills the most engaged users the most, and it relocates the entire burden of value accountability from the vendor onto the buyer. Good for investors and good for customers are not in alignment here. On this one, they partly trade off.

Three things to do if you are buying.

Model your power users, not your average. The average user will not break your budget. The fifteen people who actually adopted the thing will, and they may very well be the ones delivering your return.

Make the vendor define the unit before you sign. If a task can cost anywhere from a few credits to a few hundred depending on how many times the agent talks to itself, that is not a price, it is a range. And you'll end up at the upper end, trust me. Ask vendors to commit to a per-outcome cost and watch how fast the conversation gets vague.

Push for outcome terms on anything that has a definable outcome. Resolution, completion, ticket closed. If the vendor will only price the effort and not the result, they are telling you something about how confident they are in the result.

The interesting question is not whether usage pricing is here. It is. The question is whether buyers will accept a model where the vendor is paid the same whether the agent nails it on the first try or flails through ten, or whether the market pushes back toward paying for outcomes the way Fin does. Or Zendesk. Or Hubspot. Or others. I do not know which way that goes. But the vendor whose margin improves when its agent works harder is not, structurally, the vendor most motivated to make the agent work better.

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.

If you only read the press releases, Zendesk Relate 2026 told a strong, clean story. The era of the chatbot is over. Welcome the Autonomous Service Workforce. Resolution replaces deflection. Outcome-based pricing is the new norm. Specialization beats generalist orchestration.

That’s strong. Really strong.

If you also watched the customer panel, listened to the day-two keynote, and had the chance of having analyst one-on-ones, you got a richer story. One in which the strategic bets are well-placed, the customers describe a more nuanced reality than the slogans, and three specific refinements over the next twelve months that would turn a strong position into a durable moat.

I came home quite positive. Here is why, and where I think the next twelve months are important.

What Zendesk announced and why it lands

The headline product story was the Autonomous Service Workforce: a network of specialized AI agents working alongside humans, orchestrated through what Zendesk now calls the Resolution Platform and improved continuously by the Resolution Learning Loop. Agent Builder gives customers a no-code interface to build bespoke agents. The Copilot suite expanded to four personas: Agent, Admin, Knowledge, Analyst. Voice AI handles 60+ languages mid-conversation. Employee Service AI agents from the Unleash acquisition live inside Slack and Teams. Knowledge Graph spans SharePoint, Google Drive, Notion, Guru, Contentful and Document360. Model Context Protocol support is bidirectional. Quality Score evaluates every interaction.

This is quite a handful.

Two of these messages are more powerful than the others. The first is resolution over deflection. Zendesk charges only when a resolution is verified by a second AI evaluation model; outcome-based pricing as the natural commercial expression of the philosophy, and a model Forrester has been telling vendors to move toward for the past year. The second is specialization over generalization. The argument is that 19 years of CX data, billions of  service interactions, and an opinionated service stack beat horizontal platforms using commoditized LLMs.

It is a strong argument. It is also working. Zendesk reported 130% year-over-year AI ARR growth, 20,000 active AI customers out of an 80,000 base, and more than 1,500 competitor replacements in 2025. Salesforce's own May 2026 State of Service survey shows agentic AI adoption in service jumping from 39% to 66% in twelve months. This is independent confirmation that the market is genuinely re-platforming, not just re-branding, and that Zendesk's growth sits inside a rising tide.

What customers told us and what it confirms

The customer panel completed the story. Stacy Niven of Direct Supply, Dena Fuentes of Emburse, Sam Bellach of Lyra Health, Jessica Hsieh of Levi's, Elymae Cedeño of Bumble, and Rob Giglio of Canva each added a dimension the headlines could not.

First, data foundation is more important than vendors usually admit. Stacy described Direct Supply's multi-year rebuild. Half of orders have been manually touched, processes worked in spreadsheets, an internally developed chatbot they walked back on because the product data was bad. Sam Bellach put it plainly: AI is only as good as the data feeding it. Salesforce's research confirms this: 59 to 72% of service professionals name data readiness as the top AI blocker. The Zendesk message would land even more cleanly if it acknowledged this work upfront. The customer panel, by being candid about it, did the job the brand did not need to.

Second, customers want more human connection in the AI era, not less. Jessica Hsieh cited research that 61% of CX leaders see live volumes rising. Elymae Cedeño at Bumble was emphatic that in a trust-and-safety product, humans are foundational. Levi's deploys AI for "where's my stuff" so human agents can be reserved for judgement and empathy. This is a tailwind for Zendesk's design philosophy — human-as-architect, AI-as-tool — and it argues for sharpening the messaging around that strength, not against the strategy itself.

Third, the outcome-pricing model has earned its lead, and the field will likely catch up over the next year. Sam Bellach, who is on Zendesk's Customer Advisory Board,  pushed back on the rigidity in what she describes as a candid debate. This debate is about the chicken-and-egg problem of spending ahead of proven RoI, the lack of mid-contract convertibility between agent-seat and resolution spend, and the ambiguity in what counts as resolved.

Forrester's Q2 2026 Conversational AI Wave found only one vendor scored above 3 of 5 on pricing flexibility. The fact that Sam is comfortable having that debate in public is a signal in itself. Zendesk leads the category and is co-designing the next version with its best customers.

Fourth, the most interesting moment of the week. Rob Giglio's part of the day-two keynote was structured around his recent frustration with someone else's deflection bot; he half-named "a name that sounds a lot like Zierra”. His thesis is that deflection causes churn, while resolution drives loyalty. Salesforce's State of Service report approvingly features Smarsh's 68% call deflection as "a phenomenal win". Zendesk is apparently on the right side of a still-unsettled industry debate, and Giglio's anecdote made the case more vividly than any product slide could.

The orchestration position is right. It just needs one more slide

Zendesk's Chief Product Officer Shashi Upadhyay was deliberately precise when I asked about orchestration. Zendesk wants to orchestrate every service interaction, they close the learning loop on every service interaction, and they do not pretend to orchestrate sales or marketing or the rest of the company. That is the honest answer. Salesforce, ServiceNow, SAP, Microsoft and Adobe are all pitching cross-system orchestration, with Google Cloud now positioning on top of them. Zendesk wisely declines that fight, interestingly using the same argument that SAP does against ServiceNow: You cannot govern what you cannot understand.

This strategic position is correct. What the messaging needs is one additional slide saying *we orchestrate service interactions; we hand off to your meta-orchestrator at these named integration points*. This single piece of clarity would turn a defensible boundary into an attractive value proposition. CIO buyers who currently hear "platform" and wonder whether to default to the suite would have a clear reason to choose the specialist for service while keeping their meta-orchestrator for everything else. The position is built. The slide is the missing piece.

The autonomy framing has room to grow into the brand

Salesforce measures 40% autonomous resolution today. Gartner optimistically projected 80% by 2029. The trajectory points exactly where Zendesk has bet. Independent analysis suggests today's genuine autonomy figure across the industry is closer to 20-30%, because much of what is marketed as agentic is nothing more than rebranded chatbot functionality. Zendesk's actual product reality of supervised agentic, with humans correcting, retraining and approving, is materially better than that field average, and is also the design that operationally safe service AI requires today.

This is a real strength, and it deserves equally real framing. "Supervised agentic resolution" or "agentic service workforce" would probably describe the product more accurately and would shift the conversation away from the autonomy bar to the supervised-agentic bar, which is a bar Zendesk easily clears. It is one of those cases where I think that a slightly more conservative brand line might be both more credible and more competitive.

The learning loop is the next big story

In the analyst one-on-ones I asked how Zendesk ensures the Resolution Learning Loop is learning in the right direction. If the system optimizes for what counts as a verified resolution under the current rubric, what stops it drifting toward easy-to-verify outcomes at the expense of harder ones? What stops the rubric from being gamed?

The answer covered the basics: multi-LLM grading, customer dispute mechanism, "a little conservative" on what counts as resolved. That is a solid, customer friendly foundation. What would turn it into a competitive advantage is a public, documented governance posture covering drift detection methodology, rubric versioning, human review cadence, adversarial test cases, audit visibility. Once that exists, the Resolution Learning Loop stops being a feature and becomes a moat that nobody else in the field is anywhere near ready to match. This is the most under-told story in Zendesk's deck.

My point of view

Three bets are working, three twelve-month refinements are available. The refinements: one more orchestration-boundary slide, a slightly more accurate autonomy line, and a public learning-loop governance posture, are all communication and documentation projects, not architecture ones. The strengths are outcome pricing years ahead of the field, a real data moat, an integrated platform, and partner ecosystem leverage, are durable, defensible, and can get stronger.

For buyers, the practical lessons are important, regardless of which vendor wins your shortlist.

Fix your data foundation before going agentic! Every successful customer at Relate 2026 did this first.

Demand outcome-priced contracts and negotiate flexibility into them. Design for supervised agentic, not autonomous. Stress-test demos on the hard cases.

Treat change management as a primary project. The 5-10% edge cases determine real-world performance. And the customers who built for those cases are the ones now reporting the strongest results.

Zendesk has built something real. The next twelve months are about telling that story as clearly as the customers are already telling it.

Kudos to Zendesk!

The AI Content Trap: Multiplying Mediocrity at Scale

Marketing has always suffered from a volume addiction; however, the advent of generative AI has turned a bad habit into a terminal condition. In the recent discussion with Volker Hildebrand in our CRMKonvo, we explored the uncomfortable reality that while AI has made marketing faster and cheaper, it has largely failed to make it better. The cynical view, which I happen to hold is that marketers frequently confuse the amount of content produced with the actual impact on the customer. We are now in an era where everyone has the same tools to flood the market with what in the words of Volker just “multiplies mediocrity” – or in mine creates instant mediocrity.

The core problem is that generative AI multiplies mediocrity by definition. It ingests existing data and spits out an average of what is already there; consequently, when every startup uses these tools to build their websites and social posts, they all end up saying the same. If you look at the CRM space today, the messaging is often nearly indistinguishable. Everyone promises "revolutionary" efficiency and "seamless" integration. As Volker noted, this is a trap for startups; if they cannot differentiate their story, they simply will not survive the noise.

TL;DR

If you want to watch the full CRMKonvo, please go ahead here (optimized for smartphones) or here (optimized for tablets/computers).

Else, be my guest and continue to read.

Or do both …

The Productivity Mirage

Vendors love to sell AI based on productivity gains. They promise you can save 20 percent of your time on content creation. But as we discussed, productivity is a hollow metric if you do not have a plan for that saved time. If you save 20 percent of your time just to produce 20 percent more "slop" or low-quality content, you have solved nothing, nor have you saved anything. You have actually made the problem worse by increasing the background noise for your customers. The real question for any marketing leader hence is how that saved time can be reinvested into understanding and resolving the customer's actual pain points.

Product Marketing: The Center of the Universe

Volker makes a compelling case for Product Marketing as the organizational "center of the universe". In a tech landscape where products are increasingly complex, the role that sits between engineering, sales, and the customer is the only one capable of maintaining narrative integrity. He argues that this role should report directly to the CEO. This is because the items product marketing owns: pricing, packaging, roadmap strategy, and win-rate optimization: are the literal lifeblood of the company.

If you bury this function under a traditional marketing silo, it becomes a "content factory" for sales decks and brochures. When it reports to the top, it becomes a strategic filter. In the age of AI, this filter is more necessary than ever. AI can draft a battle card, but it cannot understand the nuanced political reality of a specific enterprise buying center.

The "center of the universe" concept is about architectural integrity. Product Marketing must ensure that the technology actually solves a business problem rather than just serving as a shiny new feature to mention in a press release. If the messaging does not address what keeps the customer up at night, then all the generative AI in the world will not improve your win rate.

From Personalization to Individualization

We have been chasing "personalization" since the 1990s; Volker’s PhD thesis touched on it back in the 90s. Yet, most of what passes for personalization today is still just "segmented mass marketing". The real shift happens when we move toward true individualization. This could be the death of the "campaign" as we know it. After all, a campaign is, by its nature, a scattergun approach that is irrelevant to most people in the target group.

True individualization, powered by a combination of predictive and generative AI, means the customer journey is unique to the person. If Thomas visits a site, he sees the architectural whitepaper because the predictive engine knows he’s an analyst. If a procurement officer visits, they see the ROI calculator. This isn't just swapping a name in an email: it's a dynamic reconstruction of the entire engagement layer.

The Rise of the Agentic Customer

Perhaps the most significant strategic shift on the horizon is the rise of the "agentic" customer, the shift from B2B (Business to Business) to B2A (Business to Agent). We are rapidly approaching a time when the initial 80 percent of a purchase journey isn't conducted by a human researcher, but by an AI agent. When 80 percent of the interaction is bot-to-bot, traditional marketing fluff becomes useless. How do you market to a bot? You can't appeal to its emotions with a fancy hero image or a catchy slogan. You have to provide structured, high-quality, verifiable data that the agent can ingest. The bot cares about structured data, proof points, and reliability. This will force a radical return to "the fundamentals" Volker repeatedly mentioned: reliability, relevance, and proof points. Marketing leaders must prepare for a reality where their "customer" is no longer a person, but an agent looking for the most rigorous solution to a defined problem.

A Pragmatist’s Guide to Avoiding the AI Slop-Pocalypse

If you are an enterprise leader looking to "AI-enable" your customer experience, stop listening to the vendor slide decks for a moment. Take a breath. You might be about to make a very expensive mistake if you don’t follow three simple rules.

Here is the pragmatist's guide to not making that mistake.

Prioritize Predictive Over Generative

Currently, everyone is obsessed with the "Gen" in GenAI, but for CX, the "Predictive" side is often more valuable. Don’t just buy tools that just help you write faster. Instead, use AI to identify patterns: which customers are about to churn, which leads are actually ready to buy, and what content actually helps close deals. As Volker noted, tools that track actual consumption or customer journeys (did they stop at the pricing page?) provide infinitely better data than "clicks". Use AI to find the needle; don't just use it to make a bigger haystack.

Kill the "Auto-Pilot" Content

If your marketing team is using AI to generate content and pushes it directly to customers without a rigorous human-in-the-loop review, you are actively eroding your brand equity. AI-generated content is, by definition, an average of everything that already exists on the internet – it’s instant mediocrity. It cannot innovate; it can only regurgitate. Use AI for drafts, for brainstorming, and for reformatting (e.g., turning a long webinar into short clips, or a blog), but never for the final "voice". Authenticity is about to become your scarce resource.

The Training Gap is a Strategic Risk

You cannot simply buy a subscription for a tool and expect "transformation". The most common failure point is the "dump and run" approach. If you aren't investing in training your people on how to prompt, how to critique AI output, and how to integrate these tools into a unified RevOps workflow, you are just buying shelfware, or worse, something counter-productive. AI is a skill, not just a software category. If your team doesn't understand the "human-in-the-loop" necessity and how to work with AI, they will eventually be replaced by the very mediocrity they are producing.

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.

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

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

Something shifted in April 2026.

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

Different products. Different audiences. The same structural move.

All three titans just walked one layer down the stack.

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

The Pattern Nobody Is Naming

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

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

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

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

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

Salesforce: The Interface and Intent Layer

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

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

However!

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

This part is new.

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

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

SAP: The Data and Process-of-Record Layer

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

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

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

Not a plug-in. A layer.

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

ServiceNow: The Governance and Decision Layer

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

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

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

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

The Two Battlegrounds

I look at all these titan moves through two lenses.

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

This set of announcements maps cleanly on either lens.

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

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

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

The Titans Who Skipped This Quarter

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

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

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

What Buyers Should Actually Do

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

Stop evaluating AI features in isolation

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

Ask the pricing question now, not later

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

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

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

Do not let vendors map you to their product pages.

Three Things to Watch

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

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

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

The Question That Matters

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

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

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