Your ERP Vendor Refused to Build Its Own Model. Take the Hint.

In the last eighteen months every major ERP vendor made the same decision about artificial intelligence, made it in public, and made it the same way. Not one of them built a frontier model. They rented one, and the discipline behind that choice is sound. It is also the exact discipline they are now asking their customers to abandon one layer higher up the stack.

This is not a post about whether to trust SAP or Oracle. It is a post about a make and buy test that two of the largest software companies in the world ran on themselves, published the result of, and then stopped applying at precisely the point where their commercial interest changed. The test is good. You should run it. You will not like where it lands.

What they actually did

Start with the record.

At Sapphire on May 12, 2026, SAP announced that Anthropic's Claude would serve as the primary reasoning and agentic capability across its AI-enabled portfolio, powered by Joule and Joule agents. The integration reaches S/4HANA, SuccessFactors, Ariba and third party systems through the Model Context Protocol. At the same event SAP named Mistral AI and Cohere as sovereign model options and described its own posture as an open ecosystem approach to supporting any model.

Oracle took a different route to the same place. Fusion agents run on OCI Generative AI, which hosts Cohere and Meta's Llama, while Oracle Integration Cloud brokers connections out to third party models including OpenAI and Anthropic. Oracle has taken to describing itself as the Switzerland of large language models. More than 600 prebuilt agents now ship inside Fusion Cloud at no additional license cost, alongside a marketplace of certified partner agents.

NetSuite, sitting on Oracle's stack, shipped the most revealing artifact of the three. The NetSuite AI Connector Service is an MCP server, and its stated purpose is to let customers connect their own AI to NetSuite.

Three vendors, three framings, one identical decision. The reasoning layer is rented.

That is worth sitting with. These are companies with the balance sheets, the research budgets and every strategic incentive to own the most discussed technology of the decade. SAP could have funded a model. Oracle certainly could have. Neither did, and neither is embarrassed about it. They put it in the keynote.

So the interesting question is not why they rented. It is what rule they were following, because the rule is the reusable part.

The rule: rent what improves, own what accumulates

Here is the rule. Once you see it, you will see it running underneath every one of these announcements.

Rent the layers that improve on someone else's cadence. Own the layers where value accumulates on yours.

Frontier models improve on a release schedule no ERP vendor controls and none can match. A model SAP shipped in 2024 would be a liability by 2026. Owning it would mean carrying a depreciating asset and competing permanently on a dimension where SAP's differentiation does not live. So SAP rented, and structured the arrangement to keep switching open, which is why the announcement language stresses an open ecosystem rather than an exclusive one.

Now look at what they kept.

SAP kept Joule Studio, the process graph, the agent memory and the AI Unit meter. Oracle kept the agent state, the marketplace and its own metering. Neither vendor rented those and neither ever will, because those are the layers where a customer's history piles up. Every month a customer runs Joule agents, more of that customer's specific behavior sits inside SAP's representation of it. That is not a criticism. It is a correctly identified moat, built by people who understand their own business very well.

Then notice that SAP applied the same rule one layer up and reached a conclusion almost nobody has commented on. Rather than build agent orchestration from scratch, SAP took a stake in n8n, investing roughly 60 million dollars for just under 1.3 percent of the company at a 5.2 billion dollar valuation, and is embedding the n8n platform into Joule Studio with general availability expected in Q3 2026.

Read that slowly. When SAP judged that a specialist had built a better orchestration engine than SAP would build itself, SAP did not insist on building it. It bought access and composed it in.

That is the argument of this post, and SAP made it first. The company's own operating view is that an orchestration engine is something you can source from a specialist and compose into your stack rather than build inside your platform. SAP holds that view about its own architecture. It sells its customers the opposite.

Now run the test on yourself

The rule is portable. Run it layer by layer, not on AI as a single object. The most common failure in enterprise AI governance right now is a steering committee issuing one verdict for a stack that has at least seven distinct layers and seven different correct answers.

Three questions per layer.

Question one: does this layer improve faster than we could improve it?

If yes, rent it. Renting is not a concession, it is how you avoid owning something that depreciates while you hold it. This is the question SAP answered about frontier models, and SAP answered it correctly.

For most enterprises the honest answer is yes for models, yes for connector tooling into a vendor's own system, and no for nearly everything that encodes your specific business.

Question two: does this layer have to hold true across more than one system of record?

If yes, no single ERP vendor can own it. This is not a trust judgment and it is not a knock on anyone's engineering. It is a structural conflict. SAP cannot be the neutral arbiter of a workflow that crosses SAP, a Workday instance, and a Salesforce org you inherited in an acquisition. Neither can Oracle. Neither would you, in their position, and you should not expect them to volunteer for it.

Gartner projects that the average Fortune 500 enterprise will run more than 150,000 agents by 2028, up from fewer than fifteen in 2025. Argue with the number if you like. The direction is not in dispute, and coordinating anything at that scale is a cross-system problem by definition.

Question three: when this fails, whose name is on the letter?

If the answer is yours, you must own the artifact that proves it worked.

Accountability does not transfer with a subscription. SAP will not sign your SOX attestation. Oracle will not answer your regulator's questions about an automated decision under Quebec's Law 25 or the EU AI Act. Your external auditor will not accept "our vendor handles that" as a control narrative, because it does not describe a control.

This question settles the policy layer and the evaluation layer, and it settles them without any appeal to architectural taste.

The slope test

The three questions tell you what to own. This one tells you when, and it is the half that moves a CFO.

For each layer, estimate the reconstruction cost: the person months required to rebuild the artifact somewhere else, plus the months of accumulated behavior that cannot be replayed. Then estimate the same figure for eighteen months out and thirty six months out.

The absolute number is not the answer. The slope is the answer.

A flat slope means the cost to rebuild in three years is roughly what it is today. Connectors behave this way. If you swap an integration platform you rewrite integrations once, and that cost does not compound while you wait. Rent freely and stop worrying about it.

A rising slope means every month of delay makes the decision more expensive and less reversible. Agent memory behaves this way, and so does anything a sales deck describes with the phrase "learns your business." That phrase is entirely accurate. It is also a switching cost claim wearing a feature claim's clothes.

The practical consequence is the part most committees miss. For any layer with a rising reconstruction curve, "we will decide at renewal" is not a deferral. It is a decision, made in favor of the incumbent, at the worst price you will ever be offered.

The layer ledger

Here is the artifact. One page, seven rows, four columns. Fill it in for a single business process rather than for the company as a whole.

The columns are the layer, whether it improves or accumulates, the verdict, and who owns it today.

Model and reasoning. Improves, quickly. Rent. Never let a specific model be named in a contract without a matching clause on change notification and swap rights. Worth noting here: SAP named Claude as Joule's primary reasoning engine and did not publicly name a tier, while both Opus 4.6 and Sonnet 4.6 became available through AI Foundation's generative AI hub in the Q1 2026 release. Which one runs your close is not currently a fact you can look up.

Execution and connectors. Improves, and it is vendor specific. Buy it from the ERP vendor. It is their API surface, their object model and their upgrade path. They will always be better at this than you are, and building your own buys you a decade of maintenance in exchange for nothing.

Grounding and retrieval. Both. Buy the vendor's version inside the vendor's own data, where it is genuinely excellent. Own it the moment a question needs context from two systems at once.

Orchestration. Accumulates. Own it. This is the contested layer and the one every vendor is competing hardest to claim.

Agent memory and state. Accumulates, and compounds. Own the schema and the export path even where the vendor hosts the data. If you cannot describe in writing what leaves with you on the day you exit, you do not own it.

Policy and controls. Accumulates. Own it. You sign the attestation.

Evaluation and regression. Accumulates. Own it. Nobody will sell you this, which is itself the tell. A layer no vendor wants to supply is a layer whose absence costs the vendor nothing and costs you everything.

The fourth column is the one that does the work. Most organizations that fill this in honestly end up writing "the vendor" or "nobody" in every row marked own. That is not a hypothetical exposure. It is an accurate description of the architecture you are running right now, arrived at by default rather than by decision.

Then add one line per owned row on what its absence costs today. No evaluation suite means you cannot detect a model change, which means your answer to the auditor is that you do not know. No portable memory means your third year renewal is not an arm's length negotiation. No cross-system policy layer means your controls stop at the boundary of one vendor's console while your processes carry on past it.

When the vendor's orchestrator is the right answer

A framework that can only return one answer is a position wearing a framework's clothes. So here is the case against everything above, stated as precisely as I can make it.

The unit of analysis is the process, not the company. "How many ERPs do you run" is the wrong question, and it flatters the wrong conclusion in both directions.

Take one process end to end. Procure to pay, order to cash, the monthly close. Ask whether it completes without leaving the system of record, and count every step honestly, including the ones nobody documented. The approval that happens over email. The exception worked in a spreadsheet on somebody's desktop. The supplier confirmation that arrives through a portal. The bank file. The one person who eyeballs a number before it posts.

Where a process genuinely completes inside the system of record, the vendor's orchestrator is not merely acceptable, it is better than anything you would assemble yourself. It sits closer to the data, it upgrades with the platform, and it costs you no integration surface at all. Buy it without hesitation and spend your attention elsewhere.

The honest observation is only that very few real processes survive the count. And the same company can legitimately land on the vendor's orchestrator for one process while needing something above it for another. Run the test per process and you will get a mixed answer, which is usually the sign that a framework is describing reality rather than selling one.

The question for your next vendor meeting

There is a version of this argument you can hand to a vendor directly, and it has the useful property that it cannot be answered badly without conceding the point.

"You did not build your own model. Walk me through the test you ran. Then let us run that same test on your orchestration layer."

A good account team will engage with it seriously, because the answer is genuinely interesting and in some cases it favors them. A team that deflects has just told you which layer the margin lives in.

The vendors are not doing anything wrong here. They ran a rigorous make and buy analysis, reached the right conclusion for their own architecture, and are pursuing their commercial interest at the next layer up. That is what companies do, and pretending otherwise is not strategy, it is sulking. The mistake would be assuming their interest and yours point the same direction at every layer, when they have already demonstrated in public that they do not.

Rent what improves. Own what accumulates. They wrote the rule. Use it.

If you want the layer ledger as a working template, with the seven rows, the reconstruction cost columns and the process level test written out so you can run it with your own team, email me at tripathis@qubittron.com and I will send it across. No form and no follow up sequence, just the file.

Shubhendu Tripathi is an AI and ERP strategy consultant based in Toronto, and the host of The Integration Layer, a podcast on AI, enterprise systems, and the work of making them fit together. Connect on LinkedIn or reach out at tripathis@qubittron.com.