SAP Is Blocking AI Agents. Salesforce Is Welcoming Them. One of These Strategies Will Win.
SAP is actively blocking agents from its platform. Salesforce is going headless and MCP-first. Here's why one of these enterprise strategies will dominate.
Two Enterprise Giants, One Existential Bet
SAP is blocking AI agents from using its products. Salesforce is doing the opposite — going headless, MCP-first, and actively welcoming agents as first-class users of its platform. These are not minor tactical differences. They represent fundamentally incompatible theories about what enterprise software is for in 2026.
You need to understand which theory is correct, because if you’re building agents that touch enterprise data — CRM, ERP, procurement, finance — this strategic divergence will determine whether your agents work smoothly or spend their time scraping UIs like it’s 2019.
The SAP-blocking-agents-vs-Salesforce-going-headless split is the clearest real-world test of a deeper question: does enterprise software exist to serve the humans who sit in front of it, or to own the data and workflows that run through it? The answer to that question determines everything about how you should architect your agents today.
What’s Actually at Stake in This Divergence
Before comparing the two strategies, it’s worth being precise about what “blocking agents” and “going headless” actually mean in practice.
SAP blocking agents isn’t a technical limitation. It’s a deliberate policy choice. SAP has products — S/4HANA, SuccessFactors, Ariba — that sit at the center of enormous enterprise workflows. Procurement decisions, HR records, financial reporting. The data is there. The APIs exist. SAP is choosing not to expose them in ways that agents can reliably use, and in some cases actively working to prevent agent access.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
Salesforce going headless means something specific: they’re building their platform so that agents can operate against Salesforce data and workflows through MCP and APIs, without a human needing to be in the loop to navigate the UI. The CRM becomes a system of record that agents can read from, write to, and act against — not just a dashboard that humans click through.
The stakes are high because enterprise software companies derive their moat from being the authoritative record of business state. If an agent can read and write that state directly, the question becomes: who does the agent work for? The software vendor, or the business?
The Dimensions That Actually Matter
Three things determine whether an enterprise software strategy survives the agent era.
Semantic legibility. Can an agent understand what it’s touching? Not just technically access a field, but understand that “issuing a refund from Stripe” and “issuing a refund from a connected Shopify store” are different actions with different consequences? There’s a documented case of a real production system being deleted because an agent couldn’t distinguish between staging and production environments. That’s not a model failure. That’s a semantic failure — the system didn’t make the meaning of its objects legible to the agent. Enterprise software that exposes rich semantic context through MCPs and typed APIs gives agents the meaning layer they need. Software that forces agents to navigate UIs gives them nothing but pixels.
Authority architecture. Enterprise work isn’t just about reading data — it’s about permissioned actions. A refund, a payment authorization, a compliance exception, a contract approval. These aren’t equivalent to clicking a button. They carry obligations, audit trails, and downstream consequences. The question is whether the software exposes these as semantically meaningful units of work with appropriate permission structures, or whether it treats all actions as equivalent form submissions. The five-rung permission ladder — read, suggest, draft, act with confirmation, autonomous — only works if the underlying system can tell the difference between rungs.
System-of-record stickiness. This is the strategic crux. Enterprise software companies are terrified of becoming dumb infrastructure. If agents can operate against your data through any interface, what’s the value of your UI? What’s the value of your UX? The answer, if you’re Salesforce, is that the data itself is the moat — not the interface. If you’re SAP, apparently the answer is that the interface is the moat, which is a losing bet.
The SAP Strategy: A Controlled Burn That Becomes a Wildfire
SAP’s logic isn’t irrational on its face. They have enormous installed bases. Their customers have spent years and millions of dollars implementing SAP systems. The switching costs are real. If you can prevent agents from operating against your platform, you force human operators to stay in the loop, which means your UI stays relevant, your training programs stay relevant, your consulting ecosystem stays relevant.
The problem is that this strategy only works if you can actually prevent agent access — and you can’t, not permanently.
How Remy works. You talk. Remy ships.
Computer use is the universal adapter. Agents with screen access can navigate SAP’s UI the same way a human can. It’s slower, more brittle, and semantically impoverished — the agent sees pixels, not meaning — but it works well enough to do the job. SAP blocking official API access doesn’t prevent agents from operating against SAP. It just forces agents to use the worst possible interface for it.
This creates a specific failure mode. When an agent navigates SAP through computer use rather than a proper semantic interface, it’s operating without the meaning layer. It doesn’t know whether the procurement action it’s taking requires a second approval. It doesn’t know whether the vendor it’s selecting has a compliance hold. It doesn’t know whether the budget line it’s touching is already committed. It’s clicking buttons. And as anyone who has watched agents click buttons in complex enterprise software knows, that goes wrong in ways that are expensive to fix.
SAP’s blocking strategy doesn’t protect its customers from agent errors. It makes agent errors more likely, while also making it harder to build the guardrails that would prevent them.
The deeper problem is competitive. Salesforce is actively building the semantic layer that makes agents useful. SAP is not. Over time, agents will route around SAP where they can and operate clumsily through it where they can’t. The businesses that depend on SAP will start to notice that their agent workflows work beautifully against Salesforce data and awkwardly against SAP data. That’s a slow-motion platform erosion, not a defense.
Calling this “sticking your head in the sand” is generous. It’s more like building a wall on one side of your property while the other three sides are open.
The Salesforce Strategy: Bet the System of Record
Salesforce’s move is the opposite in every dimension. They’re not just tolerating agents — they’re architecting for them. Going headless and MCP-first means Salesforce is explicitly building the semantic layer that makes agents useful: typed objects, permissioned actions, structured workflows that agents can read and act against without needing to navigate a UI.
The strategic logic is clear. Salesforce’s moat has always been the data, not the interface. Salesforce CRM is valuable because it’s where the customer record lives — the account history, the opportunity pipeline, the support tickets, the contract terms. If agents can operate against that data directly, Salesforce becomes more valuable, not less. Every agent that uses Salesforce as its system of record is an agent that reinforces Salesforce’s position as the authoritative source of customer truth.
This is why the MCP-first strategy is specifically smart for a CRM. When an agent needs to check whether a customer has an open support ticket before issuing a refund, or whether an account has a pending renewal before scheduling a call, it needs to read from a system of record. If Salesforce is the most semantically rich, most agent-accessible system of record available, agents will route through it by default.
The headless play also solves the authority problem. Salesforce can expose permissioned actions — create opportunity, update account, log activity, trigger workflow — as first-class semantic primitives that agents can use with appropriate authorization. An agent operating through Salesforce’s MCP interface knows what it’s touching and what permissions it needs. An agent operating through a scraped UI knows neither.
Not a coding agent. A product manager.
Remy doesn't type the next file. Remy runs the project — manages the agents, coordinates the layers, ships the app.
Platforms like MindStudio that connect to 1,000+ integrations including Salesforce are already building on this assumption — that the enterprise data layer will be agent-accessible through structured interfaces, not scraped through UIs. The Salesforce bet makes that assumption safer to build on.
There’s a risk in the Salesforce strategy, though. Going headless means accepting that your interface is no longer the product. That’s a significant cultural and business model shift for a company that has spent decades building one of the most elaborate SaaS UIs in enterprise software. If agents become the primary interface to Salesforce data, what happens to the Salesforce UI? What happens to the Salesforce admin ecosystem? These aren’t rhetorical questions — they’re real business model questions that Salesforce is implicitly answering by going MCP-first.
The answer Salesforce seems to be betting on: the system of record is stickier than the interface. Data gravity wins. If your data lives in Salesforce, your agents will use Salesforce, regardless of what the UI looks like.
That’s probably right. But it requires Salesforce to execute on the semantic layer — to actually make their objects and actions legible enough that agents can use them reliably. Announcing MCP support is not the same as building a rich semantic interface. The proof will be in whether agents operating against Salesforce data actually understand what they’re doing, or whether they’re just getting slightly better API access to the same opaque fields.
For builders thinking about how to expose their own domain semantics to agents, the architecture question is the same one Salesforce is wrestling with. Remy takes a related approach at the application layer: you write an annotated markdown spec describing your application’s intent and structure, and it compiles into a complete TypeScript app — backend, database, auth, and deployment — with the spec remaining the authoritative source of truth. The principle maps directly onto what Salesforce is attempting: make the meaning explicit and machine-readable from the start, rather than burying it in UI conventions that agents have to reverse-engineer.
Who Should Use Which Platform (And What Builders Should Take From This)
If you’re building agents that need to act against CRM data — customer records, pipeline management, support workflows — Salesforce’s MCP-first strategy makes it the better substrate right now. The semantic layer is being built. The permissioned actions are being exposed. Your agents will have meaning to work with, not just pixels. The AI agents that marketing teams are deploying in 2026 are already assuming this kind of structured CRM access — and the ones built on Salesforce’s headless layer are outperforming the ones scraping UIs.
If you’re building agents that need to touch ERP workflows — procurement, financial reporting, HR records — you’re in harder territory. SAP’s blocking strategy means you’re either waiting for SAP to reverse course, building brittle computer-use wrappers around SAP UIs, or finding ways to route around SAP entirely. None of these are good options. The multi-agent system architecture decisions you make now will determine how painful this gets.
Remy doesn't build the plumbing. It inherits it.
Other agents wire up auth, databases, models, and integrations from scratch every time you ask them to build something.
Remy ships with all of it from MindStudio — so every cycle goes into the app you actually want.
If you’re evaluating enterprise software for a new implementation and agent workflows are part of your roadmap — and they should be — the SAP vs. Salesforce divergence is a procurement criterion. Software that actively blocks agents is software that will require human operators to stay in the loop indefinitely. That’s a cost that compounds.
If you’re a builder thinking about your own platform strategy, the lesson from this comparison is stark. The companies that will own the agent era are the ones that make their domain semantics legible. Not just technically accessible — semantically legible. An agent needs to know what a “compliance exception” means in your system, not just that there’s a field called compliance_exception_flag. The three different bets on AI agent strategy being made at the model layer all assume that the application layer will eventually expose this kind of semantic richness. Salesforce is building toward that assumption. SAP is betting against it.
The coding world figured this out first, and not by accident. Software development has unusually rich semantic feedback built in — tests pass or fail, compilers throw errors, linters flag problems, git history shows what changed and when. That’s why coding agents arrived before enterprise workflow agents. The semantic layer was already there. For enterprise software to support the same quality of agent work, it needs to build an equivalent semantic layer. Salesforce is trying. SAP is refusing.
The comparison between leading agentic coding models illustrates exactly this point: the models that perform best in agentic coding benchmarks aren’t just smarter — they’re operating against richer semantic infrastructure. The same dynamic will play out in enterprise software. Agents operating against Salesforce’s typed, permissioned, MCP-exposed data layer will outperform agents navigating SAP’s locked-down UI, not because the underlying models are different, but because the semantic substrate is.
The Verdict
SAP’s strategy will not hold. The agents are coming regardless of what SAP’s policy says, and the agents that arrive through computer use rather than semantic interfaces will be worse — more error-prone, less auditable, less capable of understanding the consequences of their actions. SAP’s customers will bear those costs.
Salesforce’s strategy is the right one for a system-of-record business in the agent era. The data is the moat. The interface is not. Going headless and MCP-first is how you stay relevant when agents become the primary interface to enterprise data.
The broader lesson for anyone building in this space: the fight is not over which company gets to be the interface. The fight is over which layer owns the meaning of work. Salesforce understands that. SAP, apparently, does not.
