Build vs Buy Enterprise AI Agents: What SAP Connect 2026 Reveals About Lock-In

Build custom AI agents when your competitive logic, exception handling, and business context are the differentiator. Buy a vendor-native platform when the process is standard and the vendor already owns the data and controls. Most enterprises do both: buy the transactional backbone, then build the decision and context layer that stays portable and under your control.

At SAP Connect 2026, SAP CEO Christian Klein asked the question every vendor wants CIOs to internalize: “Why would anyone build agents standalone on an LLM platform?” His argument was that a general-purpose model does not know which supplier will deliver, which controls govern a payment, or how your company handles an exception. “LLMs still have no idea how your business runs,” he said. He is right about the problem. The buyer’s mistake is assuming the only fix is to hand the whole thing to one vendor.

Why Enterprise AI Agents Need Business Context, Not Just an LLM

An LLM is a reasoning engine with no memory of your company. It cannot approve a purchase order, because it does not know your approval thresholds, your preferred suppliers, or the regulatory controls that sit around the payment. SAP is trying to close that gap with its Knowledge Graph, which Klein said maps more than 7 million fields, half a million tables, more than 50,000 APIs, and roughly 400 data products. Those are vendor-reported figures that show scope, not proven accuracy inside your environment.

The value of an enterprise agent lives in the context, not the model. If you’re a manufacturer whose margin depends on how you handle supplier substitutions, that logic is your intellectual property. Encoding it into a generic chatbot is pointless, but handing it entirely to a platform that then owns it is worse. The context is the asset worth protecting.

What SAP’s Architecture Reveals About Lock-In Risk

SAP’s design distributes what applications used to bundle: Joule Work becomes the engagement layer, assistants organize work by role, and agents execute across finance, procurement, supply chain, HR, and customer experience. If it works as intended, your people finish more work without ever opening the underlying apps. That convenience is exactly where the lock-in hides.

SAP says its gateway lets other AI experiences call its agents and lets Joule Work invoke registered third-party agents. That is connectivity, not portability. Connectivity lets you plug an agent into another environment. Portability lets you replace it without losing capability, history, or control. The distinction decides your negotiating position in three years. A planned “company memory” capability would ingest your process documents, policies, and execution history, then feed distilled context back to agents — a learning loop that gets more valuable, and more expensive to leave, every quarter.

Whoever owns the accumulated corrections, overrides, and decision traces owns the switching cost — the real lesson of this architecture, and one that applies to every vendor-native AI platform, not just SAP.

Build vs Buy: Four Questions Before You Commit to a Platform

SAP’s own framing gives CIOs a useful stress test. Run any agent decision through four questions: What kind of work intelligence should the vendor supply? Which gaps in your business context actually deserve repair? Who owns what the agents learn? And who measures value and absorbs the cost of failure?

Here is the honest comparison:

	Buy vendor-native	Build custom
Best when	Process is standard, vendor owns the data and controls	Logic is your differentiator, spans multiple systems
Speed to first value	Fast — context is pre-wired	Slower — you assemble the context
Switching cost	High; learning history may not export	Low if you own the artifacts
Who owns the learning	Often the vendor	You
Ongoing cost model	Consumption/usage metering	Your infrastructure, predictable

Don’t build when the process is genuinely commodity and the vendor already holds the authoritative data — recreating SAP’s transactional controls from scratch is a waste. SAP COO Sebastian Steinhaeuser put the warning bluntly: don’t pay “incredible token bills for something that they could have fixed at the database level,” and don’t “encode the last 5% of missing automation in your backlog into an agent and call that an innovation.” Build when the decision layer is where you compete. If you’re weighing where autonomy even belongs, the distinction between agents and simpler automation usually settles it before the build-vs-buy question does.

How Do You Connect Custom Agents to Your Existing Stack

Custom does not mean isolated. A well-designed custom agent sits on top of your SAP, CRM, and data sources through APIs and calls the vendor’s context where that context is genuinely differentiated. SAP’s gateway connectivity makes this viable — you can integrate its agents into your orchestration layer rather than living entirely inside its engagement layer.

The prerequisite most teams underestimate is data quality. Döhler reported that incomplete and duplicate master data constrained its developing no-touch sales order process. No agent, custom or bought, fixes dirty data for you. The connective work — reliable API integration and enterprise data pipelines — and the data engineering that makes your numbers trustworthy before anything runs on top are what separate a demo from production.

Who Controls the Rules When Agents Hit an Exception

The richest process knowledge shows up when standard execution breaks. A planner overrides a recommendation, a buyer picks a higher-priced supplier, a controller resolves an unusual posting. Transaction systems record the result and lose the reasoning. Agent-mediated work can capture that reasoning — and whoever stores it controls the rules.

Before production, require access to your prompts, corrections, overrides, evaluations, and the resulting memory artifacts. Define whether employee interactions improve only your agents or feed broader vendor models. Test exportability for real, because an exit right is hollow if a replacement agent has to relearn years of exceptions from zero. A Novartis procurement leader advised starting where a wrong decision is recoverable — sound guidance for any first deployment, custom or vendor-built.

A Decision Framework for CIOs Evaluating Custom AI Agent Development

Separate the value meter from the billing meter. SAP is moving premium agentic capability toward consumption pricing tied to agent actions, while customers still absorb retries, human rework, and failed execution. Define what “successful completion” means before you deploy, and insist on reproducing the value calculation independently rather than accepting the vendor’s dashboard.

Bring one candidate process, its current performance baseline, and the systems it crosses. Buy the layer where the vendor’s transactional and regulatory knowledge is genuinely ahead. Build the layer that holds your company-specific definitions, policies, and decision criteria — and keep the learning history exportable. Within two years, the enterprises that fare best will be the ones that treat vendor agents as replaceable components and keep their process knowledge in their own custom agent architecture — not the ones that surrender the orchestration layer wholesale.

FAQ

Q: Should enterprises build or buy AI agents? A: Buy when the process is standard and the vendor already owns the authoritative data and controls. Build when the decision logic is your competitive differentiator or spans multiple systems. Most large enterprises combine both — buying the transactional backbone and building a portable decision layer they fully control.

Q: What is vendor lock-in with AI agents? A: Lock-in happens when the business context, corrections, and learning history that make an agent valuable can only live inside one vendor’s platform. SAP’s gateway offers connectivity — plugging agents into other environments — but not portability, which would let you replace an agent without losing its accumulated knowledge.

Q: Do you still need custom development if you use SAP Joule? A: Often yes. SAP supplies strong transactional and regulatory context, but your company-specific policies, exception handling, and cross-system logic are assets worth keeping under your own control and exportable, rather than encoded solely inside a vendor’s walled garden.

Key Takeaways

• Treat vendor AI agents as replaceable components; keep your process knowledge, corrections, and decision history in a form you can export.
• Before signing, test exportability for real — an exit right you cannot execute is not an exit right.
• Don’t build where the vendor already owns the authoritative data; build where your decision logic is the differentiator.
• Separate the value meter from the billing meter, and define “successful completion” before deployment, not after the first invoice.
• Fix data quality first — no agent compensates for duplicate or incomplete master data.
• Book a custom AI agent architecture consultation with one candidate process, its baseline, and the systems it crosses to get a clear scale-or-stop decision.