Agent governance is treated as a policy question — frameworks, principles, the well-reviewed PDF. It is an architecture question. The agents that matter now don't answer questions — they take actions (filing a report, moving money, changing a record, calling a system that calls three more) on someone's behalf, with real consequences when they're wrong. We spent two years making agents capable. We spent almost none building the layer that supervises them.
The missing middle
There are two layers that already exist, and a gap between them. At the top, policy governance — valuable, but pitched at the altitude of intentions, not runtime. At the bottom, vendor guardrails — the safety features baked into one model or one cloud, which stop at the edge of that vendor's world. Between them sits the layer that is mostly missing: a runtime supervisor (the thing that watches an agent while it acts, not after) that governs what an agent is allowed to intend, plan, and do — regardless of which model is underneath or whose cloud, if any, it runs on.
For a large part of the market, "governance that lives in someone else's cloud" is a non-starter. A bank, a hospital, a defense contractor, a national government — they can't put their agents, or the oversight of those agents, inside infrastructure they don't control. Sovereignty isn't positioning for them — it's a procurement requirement. And when the only oversight on offer is bolted to a hyperscaler, those organizations end up with the agents and not the supervision. That's exactly backwards.
The supervision has to travel with the agent
So the principle is easy to state and hard to build: the supervision has to travel with the agent. The same governance on a frontier model or an open one you host yourself. The same governance in the cloud or air-gapped in a basement (no internet, by design). The standard describes how an agent is supervised — not which vendor you bought. Substrate-agnostic, model-agnostic, deployment-agnostic. That isn't a feature list — it's the design constraint everything else follows from.
Plainly, then. XSI-AIMS is a specification — it bounds what an agent is allowed to intend and plan before any of it becomes an action, and it keeps every action supervised and reversible in flight. It sits around the model, not inside it. It doesn't retrain anything, and it doesn't ask you to swap your model — it governs the agent through the three surfaces you already control (its instructions, its memory, its permissions). You can adopt it without betting your safety story on one model staying frozen forever.
Why we're giving it away
We could have kept it. A governance standard the rest of the industry licenses from you is, on paper, a fine business. We're not doing that, for two reasons. First — a standard one company owns isn't a standard, it's a product wearing the word. The whole value of a governance spec is that many parties can read it, implement it, argue with it, and trust it without having to trust us. Make it proprietary and it loses the one property that made it worth having.
Second — and this is the one I actually care about — safety infrastructure shouldn't be a moat. If the layer that keeps autonomous agents accountable only exists where someone can charge rent for it, the organizations that can't pay (or can't touch a cloud at all) run their agents ungoverned. I don't want to build a company on that gap.
Gap: This isn't the first work on agent oversight, and we haven't solved it — people at labs, universities, and standards bodies are building different pieces of this, and the field is better for it. XSI-AIMS doesn't do everything either: it specifies how an agent is supervised, not how your model is trained, and it assumes you bring the deployment it runs on. What it adds is the part the conversation is short on — a concrete, implementable specification you can run, not just nod along to.
A word on who's saying this
Extended Systems Intelligence is 90 days old — small, new, self-funded. That's relevant to the argument, not a disclaimer: if a company this size can specify and ship a working supervisory layer in a quarter, the reason the agentic world doesn't already have one isn't difficulty. The incentives pointed everywhere except here. We'd rather change the incentive than wait for someone larger to get to it.
The ask
So here's the ask, and it isn't a marketing one. The specification is open. Read it. Try to break it. If you run agents somewhere no cloud reaches, see whether it holds. If we got the model wrong, say so in public — that's what an open process is for. We'll be wrong about some of it, and the fastest way to be less wrong is to have the people who do this for a living looking over our shoulder. The agentic era doesn't need our permission to arrive. The layer that governs it still has to be built — and we'd rather build it in the open.
XSI-AIMS is published openly at github.com/Extended-Systems-Intelligence/aims. Read it, fork it, and send a pull request when something breaks.
Q&A with Rhyan
Extended questions from the argument above — answered at length.
It means the governance is described as a property of the agent, not of the platform underneath it. The same contract applies whether the agent runs on a frontier model or an open one you host, in a hyperscale cloud or air-gapped with no internet at all. Substrate-agnostic, model-agnostic, deployment-agnostic — that's the design constraint, not a feature list.
Practically, a regulated buyer can write "XSI-AIMS-conformant" into a procurement clause without committing to one cloud or one framework vendor. The enforcement contract is the constant; the binding to a particular runtime is the variable.
Guardrails live inside one model or one cloud and stop at the edge of that vendor's world. They're useful, and they're not a governance contract. A guardrail keeps an agent from doing a bad thing in the moment; it doesn't record who authorized an action, under what policy, with evidence you could hand a regulator. XSI-AIMS is that record and that policy surface — the Witness Layer, the Policy Bundle, the Bridge-of-Trust Executor — sitting around the model rather than inside it.
The test is the question an auditor asks after an incident: not "did a guardrail fire," but "show me what the agent was allowed to do, what it did, and who signed for it." That's the gap.
Two reasons. A standard one company owns isn't a standard — it's a product wearing the word; its value is that many parties can read it and trust it without trusting us, and proprietary licensing destroys exactly that. And more bluntly: safety infrastructure shouldn't be a moat. If the only accountable-agent layer is one you pay rent for, the organizations that can't pay — or can't touch a cloud at all — run their agents ungoverned.
XSI makes its money on conformant runtimes and products built against the open spec, not on the spec itself. The standard is the contribution; the runtimes are the business.
It specifies how an agent is supervised, not how a model is trained — it sits around the model and never touches the weights. It assumes you bring the deployment it runs on; it doesn't pick your substrate, your model, or your topology. And it isn't finished: it's published openly ahead of a Q3 2026 ratification target precisely so governance and security teams can read it adversarially and tell us where it breaks.
Naming the limits is part of the credibility. A governance spec that claimed to do everything would be the first thing an auditor distrusted.
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 governance contract is a property of the agent, not the platform. The same XSI-AIMS contract applies whether an agent runs on a frontier model or an open one you host yourself, in a hyperscale cloud or fully air-gapped with no internet. Substrate-agnostic, model-agnostic, and deployment-agnostic are the design constraint — so a regulated buyer can require conformance without committing to one cloud or one framework vendor.
No. Guardrails live inside one model or one cloud and stop at the edge of that vendor's world. A guardrail keeps an agent from doing a bad thing in the moment; it does not record who authorized an action, under what policy, with evidence a regulator would accept. XSI-AIMS is that record and that policy surface — the Witness Layer, the Policy Bundle, the Bridge-of-Trust Executor — sitting around the model rather than inside it.
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.
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 (github.com/Extended-Systems-Intelligence/aims) under an open license. The full body is normative text organized by component.