SAP NorthStar AI Architecture: Context Moat, HANA's Elevation, and the Gatekeeping Problem

Based on a page-by-page read of SAP's “AI-Native North Star Architecture” paper (May 2026, Public), plus what Sapphire 2026 and the analyst community added around it.

SAP published its AI-Native North Star Architecture paper in May 2026, a 37-page document signed off by CTO Philipp Herzig and the Office of the CTO, with forewords from DSAG and ASUG. It landed alongside Sapphire 2026's “Autonomous Enterprise” launch — Joule Work, the AI Agent Hub, SAP-RPT-1 shipping, the Claude partnership, and an agent runtime that's free until December 31, 2026.

I read the whole thing, page by page. The short version: the direction is right, and parts of it are genuinely well-architected. But several doors that should be open are gatekeeped, and the paper is conspicuously silent about them. This is a breakdown of both halves.

One framing note the paper itself insists on: this is not a roadmap, specification, or delivery commitment. It is a target reference architecture, hosted on the SAP Architecture Center, updated quarterly, evolving “GitHub-style” with community input. Judge it as a direction statement — but direction statements from a vendor carrying ~80% of the world's commercial transactions deserve hard scrutiny.

01The central bet: context is the moat — and they're right

The paper's core thesis is the strongest thing in it. Enterprise software has spent five decades being a system of record: it stores what happened, enforces rules, reports facts. What it never captured is why — which alternatives were considered, which escalation paths worked, which settlement patterns actually reduced DSO. That reasoning lived in human heads and died between interactions.

SAP's argument: frontier models are commoditizing. Every vendor can call the same Claude, the same GPT, the same Gemini. What cannot be replicated is the context those models reason over — five decades of business processes, master data semantics, and domain knowledge. The paper says it in one line, and it's the most quotable line in the deck:

“Data was the moat of the last decade. Context is the moat of the next.”

Anyone who has used frontier models seriously in an SAP landscape knows this is empirically true, because we've all lived the asymmetry. The same model that can scaffold a full-stack application in an afternoon, or get a non-trivial ML pipeline right on the first pass, falls flat on enterprise-niche tasks:

• Ask it to build an MCP server for ABAP and it will confidently invent SDK methods, hallucinate ICF handler signatures, and produce something that compiles in its imagination only.
• Ask it to wire an OAuth flow against SAP — XSUAA service instances, destination service propagation, principal propagation across a BTP subaccount — and it will conflate three generations of SAP auth mechanisms into one plausible-looking, non-functional mess.
• The same pattern repeats everywhere SAP-specific knowledge is sparse in public training data: BAPI parameter conventions, pricing procedure determination in SD, fiscal year variants, IDoc segment structures, the actual behavior of COMMIT WORK AND WAIT, CDS view authorizations. The model's general capability is astonishing; its enterprise context is missing.

That gap is exactly what the paper means by context. General reasoning is the baseline; semantic grounding is what makes it usable. The architecture's answer is the SAP Knowledge Graph: federated metadata knowledge graphs per line of business (S/4HANA KG, SuccessFactors KG, Procurement KG, Datasphere KG) running on the HANA Cloud KG engine, linking natural language to tens of thousands of APIs, data models, and business entities. When a user asks “show me overdue orders,” the KG discovers the right API, identifies filter parameters, and constructs the query — accuracy that model-only approaches structurally cannot reach.

Layered on top is context engineering: assembling the right authorized slice of enterprise information per interaction, and persisting decision traces — what was known, considered, chosen, and what resulted — so each human correction becomes a structured learning signal. A system of record shows two customers got different discounts; a system of context knows why. That compounding loop is the actual product here.

This part feels personal too. I first saw SAP HANA almost a decade ago as an in-memory columnar database. Today, I work close to one of the largest HANA scale-out landscapes while also helping enable AI-led operations through MCP and agentic workflows. That gives HANA's elevation in this architecture a different weight for me. It is no longer just the performance layer under SAP workloads; it is becoming part of the semantic, knowledge graph, and vector foundation that agents will reason over.

That shift matters because AI in SAP will not be won only by calling better models. It will be won by grounding those models in business context, authorization, process semantics, and operational reality. HANA's evolution from in-memory database to context engine is one of the most important architectural moves inside NorthStar.

Verdict on the thesis: buy it. This is the most honest articulation any ERP vendor has produced of why owning the models doesn't matter and owning the semantics does.

02The four layers, briefly and critically

The architecture reorganizes everything SAP sells into four layers. Here's what's real versus rebranded.

User Experience Layer. Joule becomes the primary entry point — not an assistant bolted onto Fiori, but the engagement layer that assembles experiences dynamically from intent. Five experience modes (Discover, Conversations, Spaces, Jobs, Develop), a generative UI built on semantically described components, voice and “physical AI” on the horizon. The honest implication, which DSAG's own foreword states more bluntly than SAP does: Fiori apps lose significance. Forrester reads this as screen-by-screen ERP design becoming obsolete within 36 months. That's a UX strategy earthquake for every customer with a Fiori launchpad governance board, and the paper undersells the change management cost.

Process Layer. The most consequential reframing: applications are demoted to capability providers — stable APIs, events, and data that agents discover and invoke. Agents are organized by business domain, not by system: a procurement agent orchestrates across ERP, sourcing, supplier management, and third-party systems as one domain-aware participant. Two creation paths (pro-code SDK and prompt-driven Joule Studio) both compile to code as the canonical artifact — portable, version-controlled, auditable. That design choice is correct and underappreciated; it's the difference between agents you can govern and low-code swamps. Hold that thought for the CI/CD section, where the same claim runs into SAP's own tooling history.

Foundation Layer. Data and AI converge here: the generative AI hub (SAP models plus frontier and open-source third-party models behind one governed interface), SAP-RPT-1 (the relational pretrained transformer for tabular business data — classification and regression via in-context learning, no fine-tuning, shipped at Sapphire), Business Data Cloud with data products as the governed interface to everything, the Knowledge Graph, and vector/memory services. The agentic orchestration model — Joule decomposing tasks to assistants, agents, skills, and subagents with reflection loops and self-verification — is a reasonable distillation of the current state of the art. The Goodhart's Law-aware evaluation section (multi-objective optimization over resolution time and retention and quality, with business KPIs as feedback) is more sophisticated than most vendor papers bother with.

Platform Layer. BTP becomes the “AI-native operating platform”: a managed agent runtime with harness capabilities enabled automatically — sandboxing, tenant isolation, persistent memory, identity, observability via OpenTelemetry. The paper's best engineering sentence: “The model reasons. The harness governs.” Research backs the claim that the harness, not the model, determines the ceiling. Multi-cloud delivery across AWS, Azure, GCP, Alibaba, and SAP Sovereign Cloud, including on-site sovereign deployment.

The trust stack deserves its own mention because it's the most differentiated part of the paper. Agents become first-class IAM principals: own identities, scoped authorizations, bounded subsets of user permissions for unattended execution, token exchange across trust boundaries, cryptographically verifiable credentials. A three-tier defense architecture (foundation: zero-trust auth, prompt-injection detection; supervision: deterministic control agents that monitor and sanitize other agents; automation: AI agents running security operations). Explicit EU AI Act and US AI Action Plan alignment, risk classification of every use case, and an ethics escalation path that can reach the SAP SE Executive Board. Whatever you think of the rest, this section is ahead of what most of the agent-platform market has put in writing.

So far, so good. Now for the doors that don't open.

03The data lake reality check — does “AI-native” mean “SAP-native”?

Here's the test every realistic enterprise will apply. You already run a data lake — BigQuery, Snowflake, Databricks, an S3 lakehouse — because analytics, data science, and half your product teams live there. It predates SAP's AI ambitions and it isn't going away.

So: to become AI-native per NorthStar, does everything have to move into the SAP ecosystem?

The paper's official answer is no, and the mechanism is zero-copy sharing: BDC data products shared into Databricks and Snowflake “as if local,” delta share to data partners, BDC Connect for Databricks live since October 2025, Snowflake connectivity landing through H1 2026. On paper, the data product is the neutral interface and nobody copies anything.

The practical answer is murkier, and this is where the gatekeeping critique starts:

• The semantics stay home. Zero-copy gives your lake the rows. The Knowledge Graph — the thing that makes the rows mean something to an agent — lives in HANA Cloud, accessed through SAP's stack. The paper is explicit that KG is the semantic backbone of the whole architecture. You can read the data outside; you can only reason over it properly inside.
• The API policy contradiction. Three weeks before Sapphire, SAP published API policy v.4.2026a restricting third-party autonomous agents from accessing SAP data outside SAP-approved channels, with enforcement starting June 9, 2026. The North Star paper preaches “open by design,” MCP, A2A, and open standards — and never mentions the policy. Forrester's follow-up post is literally titled “SAP Is Attempting To Become The Gatekeeper Of Enterprise AI — CIOs Should Push Back.” Jon Reed's phrasing at Sapphire was “data toll roads.” Both can't be true at once: either agents discover capabilities through open protocols, or only verified agents on SAP's terms do.
• The shadow-IT consequence. Enterprises resolve this tension the way they always have. If the governed path to “AI-native” requires routing your lake-centric workloads through BDC and the SAP gateway, teams that live in BigQuery will build their own agent layer against replicated data — ungoverned, semantically impoverished, but theirs. The architecture that was supposed to end context fragmentation will have manufactured a new fork of it. SAP's best argument against shadow AI is making the governed path genuinely cheaper to use than the workaround, and the current API policy pushes in the opposite direction.

The honest framing: SAP has built a real bridge for data and kept a toll booth on context. That's a commercial strategy, not an architecture necessity — and the paper would be more credible if it said so.

04The legacy reality: ECC, clean core, and the Z-code mountain

The paper describes an architecture for the landscape SAP wishes you had. Most customers have the other one.

The numbers: even by optimistic 2026 surveys, only around 59% of ECC customers are fully or partially live on S/4HANA, and earlier Basis Technologies data put full migration at ~39% by late 2024. Mainstream ECC maintenance ends December 31, 2027 (extended to 2030 at a premium), and CIO-side research suggests nearly half of ECC customers may simply run past the deadline. This is the installed base the Autonomous Enterprise has to land on.

Three problems the paper waves at rather than answers:

ECC access. The original cloud-only posture (“AI when you're on RISE in the cloud”) finally cracked at Sapphire 2026: a subset of Joule assistants and agents will operate against S/4HANA on-premises and ECC for RISE customers committed to a migration path. Forrester called it the largest concession to the installed base in three years — “the DSAG pressure won.” Real progress, but note the shape of the concession: AI access remains a carrot tied to the migration contract. ECC customers who haven't signed RISE — a very large population — are architecturally invisible in this paper.

Clean core enforcement. The architecture assumes apps expose stable APIs, events, and data products that agents discover via the Knowledge Graph. That assumption is clean core. But how do you enforce clean core on a 20-year-old ECC system where business logic lives in user exits, BAdIs, and modifications? The paper's answer — agents will “accelerate code migration, data transformation, and test automation” — treats the problem as a one-time migration task, not a governance regime you have to hold against every future change request.

The Z-code mountain. Decades of custom ABAP — Z-reports, Z-tables, custom workflows, clever-and-undocumented enhancements — encode exactly the institutional context the paper celebrates. None of it is semantically described, none of it is in any knowledge graph, and much of it contradicts the standard processes the agents will be trained to assume. Customer-specific KG extensions (“custom fields, custom APIs, tenant-specific configurations layered on top of SAP's base knowledge”) are the right concept, but the paper offers no path from a million lines of Z-code to a populated customer knowledge graph. Whoever builds that extraction tooling — SAP, a partner, or an outsider — owns a serious franchise.

05The hybrid agent scenario — the test NorthStar must pass

Concrete case, because this is how it will actually go: your enterprise builds a custom CRM agent — non-SAP stack, maybe LangGraph on GKE against your own CRM — and wants it cooperating with the SAP-native procurement agent on a quote-to-contract flow. Does NorthStar accommodate that, or does it assume SAP-everything?

On paper, accommodation: the process layer has an MCP gateway and an Agent & Tool Gateway; A2A protocol support is explicit (“agents built by different teams, partners, and customers collaborate within governed boundaries”); the AI Agent Hub claims vendor-agnostic discovery, A2A-based ingestion, and integrations with Microsoft, Google, AWS, and ServiceNow; non-SAP agent platforms appear in the architecture diagrams as first-class boxes.

In practice, three asterisks:

1. Enforcement parity is unproven. Forrester's precise caveat: it remains to be shown whether “verified” status and governance workflows translate into equivalent, closed-loop controls and telemetry depth for non-SAP agent runtimes. Your CRM agent may be discoverable in the Hub but second-class in governance — and second-class in governance means first-blamed in audit.
2. The API policy again. A third-party autonomous agent calling into SAP data outside approved channels is exactly what policy v.4.2026a restricts. So your CRM agent collaborates with the procurement agent through SAP's gateway, under SAP's verification, on SAP's terms. A2A tells you the handshake is possible; the policy tells you who holds the door.
3. Identity asymmetry. SAP's agent-identity model (scoped auth, token exchange) is genuinely good — but it's defined from the SAP trust domain outward. “Third-party agents must authenticate via identity services from SAP” is the paper's wording. Workable, but it makes SAP's IdP the choke point of your multi-vendor agent mesh.

Direction: correct, and notably more open than Microsoft's equivalent moves. Execution: watch Q3 2026 (Agent Hub GA) and Q4 2026 (full A2A interop GA) before believing it. The protocols are open; the gateway is the product.

06BYO model and privacy — where BTP feels too SaaS

Next gate. Say your legal or risk function mandates a self-hosted model — your weights, your VPC, no third-party inference endpoint. In the non-SAP world this is routine: pull vLLM or TGI, deploy on your own GPUs, point your agent framework at it, done.

In NorthStar's world? The generative AI hub offers “leading third-party models including frontier LLMs and open-source alternatives” — hosted through the hub. Sovereignty is addressed as SAP-curated choices: Mistral and Cohere partnerships for sovereign options, compliant LLMs inside SAP Sovereign Cloud, sovereign on-site delivery. All real, all useful for regulated industries — and all variations of “pick from our menu, hosted our way.”

What the paper doesn't describe is the simplest case: a customer-operated inference endpoint plugged into the hub as a first-class model target, with the harness (identity, observability, guardrails) still applying. Technically there's no reason the harness couldn't govern a customer endpoint — OpenTelemetry doesn't care where the tokens come from. The omission reads commercial, not technical.

This points at a broader structural issue: BTP's center of gravity is SaaS/PaaS — opinionated, managed, lifecycle-controlled by SAP. The AI-native stack arguably needs more IaaS-like primitives: bring-your-own runtime, bring-your-own model, bring-your-own observability sink, with SAP providing the governance plane rather than the whole vertical. Kyma (managed Kubernetes) exists and is the obvious escape hatch, but the paper's managed-agent-runtime story is built around SAP operating the whole harness. For the privacy-maximalist customer, today's honest answer is: host your model elsewhere, expose it as a tool over MCP, and accept that it sits outside the “AI-native” inner loop. That's a workaround, not a design.

07CI/CD friction — the transport layer strikes back

The paper's “code as the canonical artifact” principle deserves real credit: both low-code and pro-code agent paths produce portable, version-controlled, auditable code. That is the right call, and it implies agents should flow through normal software delivery.

Now reconcile that with the ground truth of SAP delivery: CTS transports. Every enterprise that has tried to unify SAP development with its standard CI/CD has hit the same wall — the transport system is a sequential, landscape-coupled, change-number-centric mechanism from a different era, and it is load-bearing for ABAP. The community's bridges have not held the traffic: abapGit is beloved by the 5% and invisible to the rest; gCTS never achieved critical adoption; CHARM remains the enterprise reality. Meanwhile every other team in your company ships through GitLab/GitHub Actions with trunk-based development, ephemeral environments, and automated gates.

So the practical question for NorthStar: when my platform team says “agents deploy via GitLab CI like everything else we own — build, test, scan, deploy, observable in our stack” — what's the answer?

The paper is quiet. Joule Studio and the agentic SDKs deploy to the managed runtime through SAP's own provisioning and lifecycle services; CALM appears as the ops tool; the AI Golden Path guides you along SAP's paved road. Nothing in 37 pages addresses integrating with an enterprise's existing delivery platform — which, for any organization with a platform engineering team, is a non-negotiable. The risk is a familiar one: SAP artifacts once again live in a parallel delivery universe, with its own pipelines, its own approvals, its own everything — exactly the silo the architecture claims to dissolve, recreated at the tooling layer.

If agent code is truly canonical and portable, prove it: publish the contract that lets GitLab build and sign an agent artifact and hand it to the BTP runtime for execution under the harness. That single integration would do more for enterprise adoption than three experience modes.

08For consultants: your moat moved too

Read the thesis again — context is the moat — and notice it applies to people exactly as it applies to platforms.

“Fifteen years of SAP experience” as a credential is being repriced. The encyclopedic knowledge that used to command rates — transaction codes, IMG paths, table names, config sequences — is precisely the layer that Joule, the Knowledge Graph, and code-generating agents commoditize first. A model with the right grounding will navigate SPRO better than you.

What's not commoditized is the same thing that's not commoditized for SAP itself: accumulated context, and the skill of harnessing it. Knowing why the pricing procedure was built that way at this client. Knowing which “standard” process is actually a landmine in this industry. Knowing how to decompose a fuzzy business intent into an agent specification with the right guardrails — the paper itself names the new disciplines: context engineering, harness engineering, specification engineering. Those are the consulting skills of the next decade, and none of them are certifiable yet.

There is only one way to build them: build, break, and learn. Stand up Joule Studio while the runtime is free. Write an agent against the Knowledge Graph and watch where its grounding fails. Try the A2A handshake between an SAP agent and something you built outside. Break the harness, file what you learn, repeat. The consultants who do this through 2026 will spend 2027 explaining it to everyone who didn't — at rates that reflect the scarcity.

09Quantum: early, but the right kind of early

It would be easy to dismiss the quantum section as vision-paper garnish. On reflection, it's better than that — it's SAP doing the alignment work before the wave, which is the opposite of how the industry handled the GenAI wave.

The architectural framing is sober and specific: QPUs as mathematical coprocessors invoked by applications for optimization and simulation, returning classical outputs into deterministic workflows; cloud-native access through standardized APIs that abstract vendor differences; and a crisp scoping decision — quantum stays in analytical and compute-only roles (planning, forecasting, optimization) because the no-cloning theorem rules out the state replication that transactional operations require. That last point is a genuinely architectural argument, not marketing. Add postquantum cryptography preparation and a working truck-loading demo from TechEd 2025, and you have a company positioning the architecture to absorb a new computational paradigm without rebuilding. NISQ hardware isn't enterprise-ready and SAP says so plainly. Good. This is what forward alignment is supposed to look like.

10Scorecard

The North Star is a good star. SAP has correctly identified that its context — not its applications, not model access — is the asset of the decade, and it has designed a credible architecture around that insight. The same insight is also why every gate in the architecture is worth fighting over: whoever controls the context controls the decade. Right now SAP is building both the cathedral and the toll booth. The paper shows us the cathedral. Keep your eyes on the booth.