Three substrate vendors named their sovereignty layer in a single week.

Workday shipped the Agent System of Record to general availability — four thousand customers already running organic agents, an annualised five hundred million dollars of agentic revenue, sixteen million dollars of average annual customer saving. SAP, the same week in Madrid, launched the EU AI Cloud and codified sovereignty as a four-dimension framework: data, operational, technical, legal. Microsoft's Sovereign Cloud — announced in February, hardened through the May Agent 365 update — holds the same four-domain shape under different names: data, operational, technology, infrastructure. Two substrate vendors converged on a four-dimension framework in ninety days. The third arrived at the System-of-Record naming the same week the other two arrived at the substrate-product naming.

Around the substrate layer, one industry observer this week mapped the rest of the operating system. Nate B Jones's Control Map names seven rows — runtime, data, identity, tool access, payment, observability, kill switch — and places Cloudflare, Auth0, Okta, Snowflake, Stripe, Datadog as the vendors taking control-tier positions. Six protocols emerged. Three decide which agents survive. The vendor-side picture of agent infrastructure is now drawn at a fidelity it has not had before.

This is the moment to name what nobody else is naming. Every vendor-side label is a substrate claim. None of them answer the customer-side question.

What each vendor is rationally claiming

Read the three announcements from where each vendor stands. Each move makes structural sense.

SAP needs to monetise the substrate it controls. The EU AI Cloud, the four-dimension sovereignty framework, the Joule Studio and Business AI Platform — all of these turn SAP's existing position as the system-of-record for the world's most business-critical processes into a sovereignty product line. Christian Klein in Madrid: "My CEO, my CFO is telling me I need to deliver AI tomorrow."[^1] SAP is offering an answer in the shape SAP already owned.

Workday needs to defend its workforce system of record against the agent layer that increasingly does the work that used to require a Workday seat. The Agent System of Record — "gives customers visibility and control over all of their AI agents"[^2] — is Workday's claim to be the place where the new layer is governed, regardless of which lab built the agent. Four thousand customers in three months. Sana from Workday positioned as superintelligence for work. The defence is operating at financial scale.

Microsoft, Cloudflare, Auth0, Snowflake, Stripe, Datadog are each taking control-tier positions at the rows of Nate's map they already own. Microsoft's Sovereign Cloud captures the four-domain risk frame in the corner of the market where data location, jurisdiction, and operational control determine procurement. "The boring layer is where the power is moving,"[^3] as Nate put it. The boring layer is also the layer each of these vendors has been building toward for a decade.

None of this is wrong. None of the vendors are acting badly. The point is structural. From where each vendor stands, naming their layer is what the next twenty-four months of their business depends on.

The question vendors are answering — and the one they are not

The question the vendor announcements are answering is: where does your agent run, what controls operate on it, what data and models sit inside the perimeter, who governs the audit trail?

That is the substrate question. Substrate sovereignty is a product. You can buy it. You can specify it. SAP, Microsoft, Workday, IBM, AWS, Google Cloud are all racing to sell you a version of it that fits your jurisdiction and your risk register.

The question the vendor announcements are not answering is: which work belongs to you?

That question cannot be solved by buying a substrate-sovereignty product. It can only be answered by the capability discipline the customer installs — the discipline that decides which work is yours to own, which is yours to coordinate, which is yours to delegate, and which is yours to absorb when the vendor portfolio drifts, which it always does.

Forrester's Faram Medhora wrote this week that Claude as the anchor model in SAP's Joule architecture "creates concentration risk that becomes board-level in regulated industries within twenty-four months."[^4] His customer-side recommendation reads almost word-for-word as a discipline brief: "Commit at the architectural pattern level. Pilot at the product level. Define explicit go and no-go criteria before declaring SAP your strategic AI architecture for 2030." The vision is credible, Medhora wrote. The execution is partial. Substrate sovereignty does not close that gap. Architectural pattern commitment with explicit go/no-go criteria — that is capability sovereignty under a different name.

DSAG's Jens Hungershausen, speaking for sixty thousand SAP customers across the German-speaking region, said it more sharply at the end of April. The SAP API Policy creates "massive uncertainty" and "risks freezing customer AI innovation in its tracks."[^5] That is not a complaint about substrate. That is a complaint about a customer-side capability question that the customer cannot answer on the vendor's timeline.

The signature distinction

Substrate sovereignty is what vendors sell. Capability sovereignty is what customers have to own.

Substrate sovereignty answers four dimensions. Where does the data sit. Who operates the runtime. Which models are admitted. What jurisdiction holds the legal frame. SAP and Microsoft have now converged on this four-shape in ninety days. IBM Sovereign Core ships a four-pillar version of the same idea. The dimensions are real. The product category is real. None of this is illusion.

Capability sovereignty answers a different question. Which work belongs to you? Which workflows are yours to own as a defensible Signature capability — the work that gives your organisation its competitive shape and cannot be safely delegated to a substrate vendor whose product portfolio drifts on its own roadmap. Which workflows are Core but Standardised — necessary work that should be coordinated against the cheapest reliable vendor of the moment. Which workflows are Context — work where vendor-owned solutions are precisely correct because the work is undifferentiated. And critically: which workflows have you misclassified, putting your defensible work inside a vendor's substrate and your standardised work inside a custom build?

Substrate sovereignty is a purchase. Capability sovereignty is a discipline. They live at different altitudes of the same question.

The risk in this week's vendor naming race is that customers read the four-dimension product and conclude that sovereignty is handled — that buying EU AI Cloud, or Sovereign Cloud, or Agent System of Record completes the sovereignty obligation. It does not. It cannot. The four-dimension framework specifies the substrate. The capability question — which work belongs to you — sits upstream of the substrate purchase. No substrate vendor will answer it for you. None of them are built to. Each of them is structurally incented to answer it in the way that maximises their own substrate footprint.

The vendor naming race makes capability sovereignty more important, not less. The clearer the substrate offerings, the more obvious it becomes that the customer-side question is the one nobody else is going to ask.

This is the lane the BusinessGPS thesis has been holding since the original Frozen Middle paper. Transformation Capability Management names it as a discipline. The Five-Layer Activity Model classifies the work. The Core / Context / Signature taxonomy decides what belongs where. The Three-Tier Sovereignty Stack — substrate, authority, engagement — separates the layers that have to be governed differently. The Capability Reclassification Matrix decides when work moves from one tier to another and how the move is staged. The category vocabulary exists. The discipline exists. What is new this week is that the substrate vendors named their layer first.

What capability sovereignty actually requires

The discipline has shape. Three things, not three slogans.

First, an honest workflow inventory mapped against the seven rows of the control layer. Take your top twenty AI-touched workflows. For each row of Nate's map — runtime, data, identity, tool access, payment, observability, kill switch — name the vendor that currently holds the control point and the named owner inside your organisation who answers when that vendor's posture changes. Most organisations have at least one row per workflow that already hits a vendor-side control point. Most rows do not have a named owner. The honest version of this exercise is uncomfortable.

Second, a Core / Context / Signature classification on each workflow. Not by gut. By the test: if a substrate vendor builds this capability into their product line in eighteen months, does the workflow remain defensible? Workflows that survive vendor commoditisation are Signature. Workflows that should be commoditised but currently sit in a bespoke build are Core misclassified upward. Workflows the organisation insists on owning that have no defensible reason to be inside the perimeter are Context misclassified downward. Misclassification in either direction is what makes consulting spend grow faster than revenue.

Third, a reversibility test on every substrate-sovereignty purchase under consideration. EU AI Cloud, Sovereign Cloud, Agent System of Record, IBM Sovereign Core — each of these is a substantial commitment. The test is not can we exit. The test is if we exit, what capability remains inside the organisation that would let us route the same workflow through a different substrate? If the answer is "the vendor's playbook, configured by the vendor's partner ecosystem," you have bought substrate sovereignty without capability sovereignty. The substrate is real. The sovereignty is not.

These three are not the whole discipline. They are the entry point. The fuller architecture — how Signature work is instrumented as a Standing Capability inside the organisation rather than as a programme; how the engagement contract is written so that capability transfer is the deliverable rather than the residue; how reversibility is governed at the portfolio level rather than the project level — sits inside the TCM body of work and inside the work BusinessGPS does with customers directly.

The substrate vendors are not pretending to do this. They are not in this business. SAP is in the business of selling SAP. Workday is in the business of selling Workday. Microsoft is in the business of selling Microsoft. Each of them will sell you sovereignty at the layer they own and quietly assume you will figure out the upstream question yourself. The vendors are honest about what they are. The risk is in mistaking their substrate product for the discipline that has to sit above it.

The customer's discipline, this week

There is a thing to do on Monday.

Pick one workflow in your AI portfolio. Not the most automated. The one you would describe to an investor as the most differentiated.

Walk it through the seven rows. For each row, write two names — the vendor that holds the control point today, and the person inside your organisation who answers when that vendor's posture changes. If the second column has more empty cells than the first, you have found the shape of your capability sovereignty gap on a single workflow. Multiply that gap by the count of workflows in your AI estate and you have the size of the discipline question your organisation has not yet asked.

The reading of the week is straightforward. Workday named the Agent System of Record. SAP named the four sovereignty dimensions. Microsoft named the four risk domains. None of them named the discipline that has to sit upstream of the products they sell. That discipline is not theirs to name. It is yours to own.

The full structural reading of this week — the three vendor moves, the seven-row control map, the four-dimension substrate convergence, the customer-side capability questions that follow — lives in The Capability Brief — Edition 9.

Your Waypoint

One workflow. Seven rows. Two columns. Ninety minutes.

Take the one workflow in your AI estate that you would describe as your most differentiated. Lay it across the seven rows of the control layer — where does the agent run, what can it know, who is it acting for, what can it change, what can it spend or commit, how do you know what happened, how do you stop it. For each row, write the vendor currently holding that control point in the left column. Write the named owner inside your organisation in the right column. If the named-owner column has more blanks than the vendor column, you have not yet found your capability sovereignty gap — you have found that you do not yet measure for it.

The fix is not to fill in names. The fix is to decide which rows are Signature work that belongs inside your perimeter as a Standing Capability, which rows are Core work that should be coordinated against the cheapest reliable substrate, and which rows are Context work where the vendor's product is precisely correct. The blanks are not the problem. The unmade classification decision is the problem.

Whichever row has no owner and no classification is the row where your sovereignty fails first. That is true regardless of which substrate-sovereignty product you buy this quarter.

References

[^1]: Diginomica / Stuart Lauchlan, "SAP Sapphire 2026 — why SAP CEO Christian Klein sees the need for speed when it comes to AI value realization", 18 May 2026.

[^2]: Workday Q1 FY27 Earnings Release and Conference Call, 21 May 2026. Workday SEC 8-K, fiscal Q1 ending 30 April 2026.

[^3]: Jones, N. B., "Seven questions decide whether your AI agent ships", Substack, 20 May 2026. The Control Map (runtime / data / identity / tool access / payment / observability / kill switch) is Nate's framework, used here with attribution.

[^4]: Forrester, Faram Medhora, "SAP Sapphire 2026: The Autonomous Enterprise Is Credible, But It Comes With Concentration Risk", May 2026.

[^5]: DSAG (German-speaking SAP User Group) / Jens Hungershausen on the SAP API Policy. Coverage: CIO.com, 29 April 2026; The Register, 30 April 2026.

The Way Pointer is published by BusinessGPS — the transformation capability platform helping organisations make strategic choices about what they build, what they buy, and what they own.