Agentic ERP is an API problem, not an AI problem
In May 2026, SAP stood on the Sapphire stage in Madrid and announced 224 agents and 51 assistants. Two months earlier, at SuiteConnect in São Paulo, Oracle announced one connector. The connector will matter more.
Both vendors are selling the same story: an ERP that runs itself, driven by AI agents instead of humans clicking through screens. Both have shipped keynotes, model partnerships, and a conversational front door. The demos look similar enough that a buyer could be forgiven for treating this as a feature race between two comparable roadmaps. It is not a feature race. The question that decides agentic ERP is not whose AI is smarter. It is whose backend an agent can actually operate, and on whose terms.
The demo layer and the operating layer are different products
Every ERP vendor now has an agentic demo. A user types “close the books for Q2” or “flag overdue invoices and email the owners,” and something happens. That is the demo layer, and at the demo layer SAP and NetSuite look interchangeable.
The operating layer is where they diverge. For an agent to do real work in an ERP, it has to discover the available operations, call them, read the results, handle errors, and chain the next call, all under an identity the system can authorize and audit. That is not an AI capability. It is an API capability. The model is interchangeable, and both vendors have partnered with Anthropic to prove it: Claude is a foundation model inside SAP’s Business AI Platform and a supported client for NetSuite’s connector. When the intelligence is the same commodity model on both sides, the differentiator moves down the stack, to the interface the agent talks to.
Agent-readiness in ERP is decided at the API layer, not the AI layer. Once you accept that, the two announcements stop looking similar.
NetSuite made the ERP an MCP server
Oracle’s move is architectural, and it is small enough to miss. The NetSuite AI Connector Service is a Model Context Protocol implementation, shipped as the MCP Standard Tools SuiteApp, with the option to build custom tools that expose your own records and workflows. In plain terms, NetSuite turned the ERP itself into an MCP server. An external AI client speaks MCP, discovers the available tools, and operates NetSuite data directly, inside NetSuite’s existing permission and governance model.
The client is not fixed to Oracle’s own AI. NetSuite’s expanded MCP support lets customers connect ChatGPT and Claude to the ERP, taking full advantage of NetSuite’s permissions and controls rather than routing around them. Yoto’s CFO described report generation dropping from three to four hours to minutes by pointing Claude at the connector. The intelligence lives outside NetSuite; the authorization and the data stay inside it. That is the correct headless shape: an open API surface the machine consumes, with the vendor governing access, not the choice of brain.
On top of that surface sits the human-facing part, “Ask Oracle,” the natural-language interface, and SuiteAgents for multi-step workflows, shipping with the NetSuite Next platform overhaul through late 2026. It matters which way the layers are stacked here. Ask Oracle is a client of the same tool surface that external agents use. The conversational UI is one consumer of the API, not the gate every other consumer has to pass through. The UI is optional, which is the whole point of building headless in the first place.
The governance detail is worth dwelling on, because it is where most agent-in-ERP projects break. An agent that can read and write ledger entries is a security problem long before it is a productivity win. NetSuite’s answer is to bind the agent to the same role-based permissions a human user carries, so the connector cannot do anything the calling identity is not already allowed to do. That is not a novel idea; it is the boring, correct one. The permission model already existed, the audit trail already existed, and the MCP layer inherits both instead of inventing a parallel authorization scheme that has to be secured from scratch. Headless done right reuses the controls you already trust rather than asking you to trust a new mediating brain with the keys.
SAP made the assistant the API
SAP’s Autonomous Enterprise is a more ambitious announcement and a more centralized architecture. The pieces are real: a Business AI Platform unifying BTP, Business Data Cloud, and Business AI; an SAP Knowledge Graph that maps business entities and relationships for agents to reason over; Joule Studio to build agents; and an Autonomous Suite of 50-plus Joule Assistants coordinating more than 200 agents across finance, supply chain, procurement, and HR. The interface is Joule Work, where a user describes an outcome and Joule orchestrates the workflows underneath.
Read that architecture as a machine consumer, not as a buyer watching a keynote. The path to SAP’s business logic runs through Joule. Joule Work is the interface, Joule Assistants do the coordinating, Joule Agents do the executing, and the Knowledge Graph is what gives them context. SAP frames this as openness: Joule Studio can manage third-party agents, and the platform supports agent-to-agent interoperability with Google and Microsoft frameworks. But agent-to-agent interoperability is not the same thing as API access. It means your agent may talk to SAP’s agent. It does not mean your agent may talk to SAP’s backend.
That distinction is the entire argument. NetSuite exposes the ERP and lets any compliant client drive it. SAP exposes an assistant and asks every client to negotiate with it. One is a platform you build on. The other is a mediator you go through.
The API surface underneath is the tell
The architectures look like choices. They are also constraints, and SAP’s is heavier than the keynote lets on.
SAP’s API surface is not one surface. It is decades of accumulated protocols layered on top of each other: RFC and BAPI calls into the classic core, IDocs for document exchange, SOAP services, OData for newer entities, and REST where S/4HANA and BTP reach. Much of it is synchronous and built for human-paced, batch-oriented work, not for an agent firing hundreds of planned calls a minute. Exposing that surface to a large language model safely is not a thin adapter. It is a middleware project: normalize the protocols, map the entities, enforce identity, meter the traffic, catch the errors an agent will generate at machine speed.
Seen that way, Joule is not only a product. It is the middleware SAP had to build to make its own backend agent-safe, then promoted to the mandatory front door. NetSuite, a younger and more uniform platform, could expose its records through one protocol and call it a connector. SAP had to wrap its estate in an assistant. The Knowledge Graph exists because, as SAP itself argues, agents are only as good as their context, and SAP’s fragmented surface does not hand an agent that context for free. Constellation Research, reviewing Sapphire, asked the question buyers should ask: whether enterprises want to remain tethered to one core platform in the agentic era. That question only arises because the architecture tethers them.
When architecture becomes policy
An architecture that mediates every agent through one layer invites a policy that requires it. SAP wrote that policy. In June 2026, SAP shipped an API policy update that technically blocks third-party AI agents from planning and executing sequences of SAP API calls except through SAP-endorsed pathways, chief among them Joule. I covered the mechanics in the piece on SAP’s API lockdown, and the short version is that the gate stopped being architectural and became contractual.
The policy is the natural conclusion of the architecture, not a break from it. If your business logic already routes through Joule by design, forbidding the routes that go around Joule costs you nothing to enforce and everything to monetize. SAP’s Digital Access licensing already meters non-human document activity, so the mediated path is also the metered path. Forrester called the Autonomous Enterprise credible but flagged its concentration risk, noting most of the 224 agents and 51 assistants are in mixed GA, early-adopter, and preview status. The vision ships. The dependency is the product.
NetSuite’s posture is different in a way that shows up in the licensing. It kept its seat-based model and did not move to consumption pricing for the connector. An open API surface plus flat licensing does not create the same incentive to police the gate, because the gate is not where the money is. This is not a claim that Oracle is more virtuous. It is a claim that Oracle’s architecture does not require gatekeeping to work, and SAP’s increasingly does.
What a buyer is actually choosing
Strip away the agent counts and the keynote language, and the choice between these two ERPs is a choice between two answers to one question: who decides what your agents can do next year.
With an MCP-native, API-first ERP, the answer is you. You point whatever model you trust at a documented tool surface, govern it with the ERP’s own permissions, and swap the model when a better one ships without renegotiating access to your own data. The vendor competes on the quality of the API and the governance around it.
With an assistant-mediated ERP, the answer is the vendor. The vendor decides which agents are endorsed, which pathways are sanctioned, what the fair-use thresholds are, and how the traffic is priced, and it can change those terms in a patch. The intelligence you bring is only as free as the interface will let it be.
The cost of that difference is not obvious on day one, when both systems demo cleanly. It shows up on the day you want to switch models, or run an agent the vendor has not blessed, or move a workflow to a framework the vendor does not sell. On an open API surface, those are configuration changes. On a mediated one, they are negotiations, and some of them are simply not permitted. A backend you can only reach through the vendor’s assistant is a backend you rent access to, even when you own the data inside it. That is the quiet cost of buying the AI layer instead of the API layer: the intelligence is portable, the plumbing is not, and the plumbing is what your business actually runs on.
This is why the “composable ERP” and “autonomous enterprise” labels are close to useless for a buyer trying to tell the two apart. Both vendors use both phrases. Composability is not a marketing claim; it is a property you can test. Can an external agent, running a model you chose, operate the system through a documented, open interface under your identity and controls? If yes, the system is composable. If every path runs through the vendor’s own assistant, it is a suite wearing composable language.
The layer that decides the decade
The agentic ERP race will be scored on adoption numbers, agent catalogs, and demo polish, and on those metrics SAP will often look ahead. Those are the wrong metrics. The metric that compounds is whether your ERP is a backend an agent can operate or a mediator an agent must ask.
NetSuite made a smaller announcement and a larger architectural bet: expose the ERP, let the machines in, govern with permissions, and treat the UI as one client among many. SAP made a larger announcement and a more defensive bet: build the assistant that everything routes through, then write the policy that keeps it that way. One bet ages into a platform. The other ages into a toll booth.
The vendors that win the agentic era will be the ones whose systems an agent can drive without permission from the vendor’s own agent. That property is decided at the API layer, and it is visible today, before a single agent count is audited. You can see which ERPs pass by reading the connector, not the keynote, which is the same test we run across every category in The Headless Index. The AI layer is a commodity. The API layer is the moat, and right now only one of these two vendors is building a platform on it instead of a wall.