On April 27, 2026, Microsoft announced that Azure Local now scales to thousands of nodes within a single sovereign private-cloud boundary. The blog post framed it as a regulated-industries moment — national infrastructure, mission-critical workloads, the kind of compute that cannot leave the perimeter. I read it twice. Then I went and looked at the agent-framework release cadence sitting next to that announcement, because the same problem sits underneath both.
I've spent the last year building governance instrumentation for agentic systems — the supervisory layer that fences an agent's authority and records the answer when somebody asks who authorized a given decision. The pattern I keep walking into is this. Every cloud has shipped an agent framework. They give you tracing and guardrails — none gives you a governance contract: who authorized an action, under what policy, with evidence you could hand a regulator. The infrastructure for agentic AI arrived. The governance surface did not arrive with it.
The framework cycle (again)
Microsoft shipped the Microsoft Agent Framework (MAF — the first-party agent framework, v1.0 GA in April 2026). OpenAI shipped the OpenAI Agents SDK (the April 2026 "next evolution" release added a sandbox and harness). NVIDIA shipped the NeMo Agent Toolkit (v1.7 current). Google shipped the Agent Development Kit (ADK Java 1.0 in March 2026; ADK 2.0 in May). AWS shipped Bedrock AgentCore alongside Bedrock Managed Agents.
| Cloud | Framework | Cycle |
|---|---|---|
| Microsoft | Microsoft Agent Framework | v1.0 GA Apr 2026 |
| OpenAI | OpenAI Agents SDK | "Next evolution" Apr 2026 |
| NVIDIA | NeMo Agent Toolkit | v1.7 current |
| Agent Development Kit | v1.0 Mar 2026, 2.0 May | |
| AWS | Bedrock AgentCore | Apr–May 2026 |
Five frameworks in one quarter. Every one of them is a competent piece of engineering — graph orchestration, tool calling, conversation memory, sandbox primitives, observability hooks. Every one of them lets a competent developer ship an agent into production. None of the five, as publicly documented, tells you, in normative terms, what an agent's authority surface should look like — much less who has to sign across it before a regulator will accept the record.
Gap: The frameworks let you build agents. A spec tells you how to govern them. Different artifact, different authoring discipline. The gap between them is where the trouble lives.
What a governance spec actually answers
Ask the four questions. An auditor will ask them. A regulator will ask them louder. So will whoever's on the pager after an agentic system does something wrong. A framework — any of the five named above — answers none of them, because answering them isn't the framework's job.
| Question | Answered by |
|---|---|
| What did the agent do? | Witness Layer (immutable audit record) |
| What was the agent allowed to do? | Policy Bundle (signed, versioned, substrate-tagged enforcement) |
| Who authorized this action, and can we prove it? | Bridge-of-Trust Executor (attestation across the cryptographic boundary) |
| How does substrate telemetry become audit evidence? | Event Promotion Gateway (substrate telemetry promoted via OTLP into the audit ledger) |
Those four primitives (Witness, Policy Bundle, Bridge-of-Trust, Event Promotion Gateway, per XSI-AIMS™ §6, §3.89, §3.66, §3.82) together constitute a governance envelope. They are the load-bearing surfaces in XSI-AIMS — the Agent Instrumentation and Management Specification, a horizontal supervisory-agent governance specification authored at Extended Systems Intelligence Corporation (XSI) and published openly as XSI's contribution to the AI-safety community. XSI-AIMS is substrate-agnostic by design — the spec text never names a particular framework, model family, or deployment topology as load-bearing. Pick any of the five frameworks named above and the spec targets the same governance surface against it.
The Witness Layer is the substrate-agnostic record of what an agent actually did (an immutable audit mechanism per the spec glossary; cryptographically segmented at the internal, external, and bridge boundaries). Policy Bundles are signed, versioned artifacts that carry enforcement metadata (Ed25519, optionally hybrid Ed25519+ML-DSA-65 for a post-quantum hedge). They carry a substrate-tag — this is the move that makes the spec portable — so a policy author writes the bundle once and the right variant lands in whichever runtime the buyer chose.
The Bridge-of-Trust Executor is the attestation primitive that operationalizes the cryptographic-boundary crossing — the place where framework authority and external authority meet, and the place where a regulator will eventually want to see a signature. The Event Promotion Gateway is how observable substrate telemetry becomes XSI-AIMS-grade audit evidence: Prometheus-class inputs walked across an OTLP boundary (OpenTelemetry Protocol) and written into the Witness Layer with the metadata a forensic investigator needs.
That's the spec in five paragraphs. The full body is normative text organized by component; the blog post gets the surface.
Why "spec" and not "library"
A governance library is a tool. A governance spec is a contract. A library binds you to its author's substrate; a spec lets the next framework cycle ship into the same surface without rewriting the governance layer underneath. The constraint is architectural, not advisory. The Policy Bundle is the enforcement surface. The Bridge-of-Trust Executor is the attestation across the cryptographic boundary. The Witness Layer is the immutable record those two write into — and the Event Promotion Gateway is how substrate telemetry walks into the same record without losing forensic fidelity. The enforcement model is published openly, so anyone who has to live with it — an implementer, a regulator, the next framework author downstream — reads the same source.
The 2025 / 2026 cycle of framework launches is the moment to land this. The frameworks are arriving faster than the governance posture around them (Gartner projected in mid-2025 that more than 40% of agentic AI projects would be canceled by the end of 2027 — the gap they were measuring is the gap a spec closes), and every framework cycle of the modern agentic era has relitigated the same governance gaps — observability, authority, policy distribution, retroactive audit — without anybody writing the spec the framework could have shipped into. None of that pattern is new. What's new is the moment to break it.
XSI published XSI-AIMS openly on June 12, 2026 (public-ratification target Q3 2026) because a governance spec without a reference implementation is an academic exercise, and a reference implementation without an open spec is a vendor lock-in trap. XSI-AIMS is both — an open spec with conformant runtimes building against it — XSI's today, others as the ecosystem develops. The standard is the artifact. The runtimes are how it gets used in practice.
What you can do with this
If you build on any of the five frameworks above, the questions in the four-question table will land on your desk eventually. Procurement asks first — they ask everyone. The regulator question lands harder, usually after the first incident retrospective when somebody on your own team has already asked it internally and not gotten an answer they liked. The four XSI-AIMS primitives are how to answer those questions without re-instrumenting the agent definitions you already shipped. The substrate-tag is part of every Policy Bundle's contract — one logical bundle, retagged at each binding, shipping against whichever framework the agent runs on.
If you contribute to AI-safety or governance standards work, the spec is in your hands — read it, fork it, send a pull request when something breaks. The full text is roughly two megabytes across its normative sections, with the operational frame organized around four layers (L-Intent / L-Plan / L-Form / L-Exec) and three modes (M-Generative / M-Constraining / M-Integrative), with SOVEREIGN exercising AUTHORITY as a posture orthogonal to those three. That's the spec body. The framework summary at the project root is the shorter entry-point.
Gap: XSI-AIMS specifies governance surfaces; it does not specify which substrate to choose, which model to call, or which deployment topology to land on. Those are framework decisions. The spec is silent on them by design (substrate-neutrality is the trade), and the silence is the part most readers will want to interrogate first.
XSI-AIMS publishes openly ahead of the Q3 2026 public-ratification target. If you are sitting on an agent rollout for a regulated buyer — on any substrate — the procurement-language artifact you can hand to legal is one of the things that ships with it. Read the spec. The conformant runtimes follow.
Q&A with Rhyan
Extended questions from the argument above — answered at length.
It means the normative text describes the governance surface — what a Policy Bundle must contain, what a Witness record must capture, what a Bridge-of-Trust attestation must sign — without prescribing which framework, which model, or which deployment topology runs underneath. The Policy Bundle Format carries a substrate-tag (§3.89) so the same logical bundle can ship in MAF-flavored and NeMo Agent Toolkit-flavored and ADK-flavored variants without the policy author re-authoring the policy. The enforcement contract is the constant; the substrate-specific binding is the variable.
Practically, this means a regulated-industries buyer can write a procurement clause that names XSI-AIMS conformance without having to commit to a single cloud or a single framework vendor. That portability is the point of an open spec versus a library.
XSI-AIMS is the open specification. The five frameworks named above — Microsoft Agent Framework, OpenAI Agents SDK, NeMo Agent Toolkit, Google ADK, AWS Bedrock AgentCore — are substrates the spec targets uniformly. The relationship is layered, not adversarial. The frameworks give you the engineering — orchestration, tool calling, observability hooks. XSI-AIMS gives you the governance surface — the Witness Layer, the Policy Bundle, the Bridge-of-Trust, the Event Promotion Gateway — that sits above whichever framework you chose and binds the agent's authority to the record of every decision it made, including the ones a regulator will eventually want to verify.
The shape of the binding is the same in every direction. A substrate-tag on the Policy Bundle resolves to a runtime adapter for that framework, the runtime adapter binds the bundle's enforcement metadata into the framework-native enforcement surface, and the agent definitions on top of the framework do not change. The framework keeps doing its job. The spec layer does its job above it. The substrate-tag handles the framework-specific seam.
April 27 was Microsoft committing publicly to running regulated workloads at thousands-of-nodes scale on Azure Local — a sovereign private-cloud boundary that cannot, by procurement contract, leak to a hyperscale tenant. The demand signal landed on April 27. The governance surface has to land before the workloads do. Sovereign workloads do not get audited "later" — they get audited as a condition of admission.
The framework launches stacked up in the same window — five clouds, five frameworks, one quarter. The governance posture around them did not stack up at the same rate. The moment to land an open spec is the moment after the frameworks have arrived but before the second-order procurement language is locked in by the largest buyers. We are in that window now.
No. XSI-AIMS is a governance specification at a layer above any single framework. NeMo Agent Toolkit and the OpenAI Agents SDK are frameworks at the substrate layer. XSI-AIMS is silent on which substrate to choose — that's a procurement and architecture decision the spec deliberately does not make for you (see the Gap callout in the article above). What XSI-AIMS does is define what your governance envelope must contain regardless of which substrate you pick.
If your team standardizes on NeMo Agent Toolkit for one workload and OpenAI Agents SDK for another, the same logical Policy Bundle can ship to both, retagged. A buyer reading your procurement language sees the same governance posture either way, and an auditor working backwards from an incident reads the same Witness record format whichever framework produced it. That portability is what separating the spec layer from the framework layer actually buys you.
The Policy Bundle is a signed, versioned artifact carrying enforcement metadata — what tools the agent may call, what data domains it may read, what authority levels it may invoke, what fail-closed behaviors apply when a check denies. The signature is Ed25519 by default, with an optional hybrid Ed25519+ML-DSA-65 envelope for post-quantum hedge. The substrate-tag (§3.89) identifies which runtime variant of the bundle applies to a given framework target.
Each framework exposes its own extension-point category — middleware extension point in the Microsoft Agent Framework, plugin / guardrail in OpenAI Agents SDK, callback in Google ADK, agent-builder hook in NeMo Agent Toolkit, action-group / control-plane primitive in AWS Bedrock AgentCore. The bundle's substrate-tagged variant binds the enforcement metadata into whichever extension point the framework exposes. The Witness Layer records every enforcement decision the bundle drove, regardless of which framework executed it. The Bridge-of-Trust Executor signs the cryptographic boundary crossings. The agent definitions on top of the framework do not change. The governance envelope is bound to them without re-authoring the agent.
XSI-AIMS is the open specification — the normative text, the section numbers, the conformance contract. It is published openly as XSI's contribution to the AI-safety community, with a public-ratification target of Q3 2026. Anyone can read it, implement against it, or file issues on the draft RFCs. The spec is the artifact other implementers can build against on whichever substrate they choose.
XSI is one implementer. The XSI LodeStone™ appliance line is one conformant runtime, the XSI-AIMS Advisor™ for Azure Sovereign AI is another, and additional conformant runtimes are in the pipeline against the five framework substrates named above. Other implementers — across hyperscalers, ISVs, and the open-source community — are explicitly the audience the spec is written for. The spec defines the contract. The runtimes are how it gets used in practice, and the ecosystem of implementers is how the contract outlives any one company.
Common Questions About XSI-AIMS and Agentic AI Governance
Short answers to the questions buyers, developers, and safety researchers ask first.
XSI-AIMS — Agent Instrumentation and Management Specification — is a horizontal supervisory-agent governance specification authored at Extended Systems Intelligence Corporation. It is a governance specification, substrate-agnostic by design. It defines the governance primitives — Witness Layer, Policy Bundle Format, Bridge-of-Trust Executor, Event Promotion Gateway — that fence an agent's authority and record the answer when somebody asks who authorized a given decision.
The Microsoft Agent Framework (MAF) is Microsoft's first-party agent framework. Version 1.0 reached general availability in April 2026. It provides graph orchestration, tool calling, conversation memory, sandbox primitives, and observability hooks for building agentic systems on the Microsoft platform. It does not specify how those agents are governed, audited, or constrained at the policy layer — that surface is what XSI-AIMS exists to define.
Yes. XSI-AIMS is published openly as XSI's contribution to the AI-safety community. The public-ratification target is Q3 2026. The specification text and supporting materials live in the public aims repository on GitHub (github.com/Extended-Systems-Intelligence/aims), released under an open license. Conformant runtimes — XSI's and others' as the ecosystem develops — are separate implementations against the open contract.
XSI-AIMS is substrate-agnostic, so it applies to agents running on Azure Local exactly the way it applies to agents running anywhere else. The Policy Bundle is substrate-tagged, which means one logical bundle can carry Azure Local-specific enforcement metadata alongside variants for other substrates. The Witness Layer records what those agents did regardless of which sovereign boundary they ran in, and the Bridge-of-Trust Executor produces the attestation a sovereign-cloud auditor expects.
Extended Systems Intelligence Corporation (XSI) is an AI research and product development company and an Idaho C-Corp. XSI authors the open XSI-AIMS specification, builds the XSI LodeStone sovereign agentic appliance line, is bringing XSI-AIMS Advisor for Azure Sovereign AI to Microsoft AppSource, and is building conformant runtimes against the open spec.
XSI-AIMS v2.0 published June 12, 2026 — the specification text lives in the public aims repository on GitHub under an open license. The full body is normative text organized by component.