The AI and AR Interoperability Standards Gap

This is general information about technology standards and adoption decisions. It is not legal or procurement advice, and standards bodies revise their work, so check the current status of any specification before relying on it.

Two layers, two different maturities

The hardware and rendering layer is settled enough to build on. OpenXR gives cross-platform access to headset and tracking hardware, so you write once instead of per device. WebXR does the equivalent for browsers. glTF and GLB are the de facto formats for moving 3D assets between tools. None of that is speculative.

The layer above it is not settled. There is no widely adopted standard for how an AI agent inside one AR experience communicates with an agent in another, discovers what it can do, or carries context across an application boundary. FIPA defined agent messaging long before this generation of AI and sees little use in it. Newer efforts exist and are early.

So a headset from one vendor runs an experience built with another vendor's tools, and the intelligent parts inside those experiences cannot talk. That is the actual gap, and it sits one level above where most standards conversations stop.

Why the top layer is harder than the one below it

Hardware abstraction is a tractable problem. There is a finite set of devices with a finite set of capabilities, and the interface describes a pose, a surface, an input. Everyone agrees what a hand position is.

Agent interoperability requires agreement on meaning, and meaning is where standards go to die. Two systems have to share not just a message format but a vocabulary: what counts as an object, what a request implies, what happens on refusal, who is accountable when acting on another system's assertion produces a bad outcome.

That last one is why this is slower than it looks. It is not a technical gap waiting on committee time. It is an unresolved question about trust between systems owned by different companies, and no schema settles it.

What this means if you are building

• Adopt the settled layer without hesitation. OpenXR, WebXR and glTF are safe bets. Building on proprietary equivalents now buys nothing and costs portability.
• Treat cross-app agent behavior as custom work. If your experience needs to interoperate with somebody else's intelligence, that is an integration you negotiate and maintain, not a standard you adopt. Budget it as ongoing work.
• Keep the AI layer separable. The interfaces here will change. An architecture where the agent logic is swappable survives that. One where it is welded into rendering does not.
• Discount roadmap promises. A vendor citing an emerging specification is describing intent. Ask what ships today and what a migration would cost, since that is the number that lands on you.

The complication

The obvious conclusion is to wait for the standards to settle, and for most teams that is right. It is also how you end up permanently late.

Standards mostly get written by people already building, and they codify what worked in practice. The teams shipping custom integrations now are the ones whose approaches get standardized, and they carry that advantage into the settled era. Waiting is safe and it forfeits that.

The distinction that matters is not early against late. It is whether early work is recoverable. A custom integration you can rip out because the agent layer was kept separable is a survivable bet. The same integration threaded through your rendering pipeline is a rewrite when the standard lands, and standards always land differently from the guess.

Decide this as a pilot, not a platform choice

The question is rarely whether the technology works. It is whether this particular use case earns continued investment given that the interoperability layer underneath it will change.

That is a judgment most teams make on enthusiasm and revisit only when the budget is already spent. Our AI Pilot Proof-of-Value Scale-or-Kill Verdict ($79) forces it into the open, on readable criteria, and it will tell you to kill a pilot. That is the half most review processes quietly lack.

Frequently Asked Questions

Which AR standards are mature enough to build on?

The hardware and rendering layer. OpenXR provides cross-platform access to headset and tracking hardware, WebXR does the same for browsers, and glTF with GLB are the practical formats for exchanging 3D assets between tools. Adopting these instead of proprietary equivalents costs nothing today and preserves portability later.

What exactly is missing?

A widely adopted standard for how an AI agent in one AR experience communicates with an agent in another, discovers capabilities, or carries context across an application boundary. FIPA defined agent messaging before this generation of AI and sees little use in it. Newer efforts exist but are early.

Why is agent interoperability slower to standardize than hardware?

Hardware abstraction needs agreement on a finite set of capabilities, and everyone agrees what a hand position is. Agent interoperability needs agreement on meaning: what counts as an object, what a request implies, what a refusal means, and who is accountable when acting on another system's assertion goes wrong. That last question is unresolved, and no schema settles it.

Should I wait for the standards to settle?

For most teams, yes, but waiting has a cost. Standards are usually written by people already building and codify what worked in practice, so teams shipping custom integrations now often see their approaches standardized. The better question is whether early work is recoverable, which depends on keeping the agent layer separable from rendering.

How should I evaluate a vendor citing emerging standards?

Treat a roadmap reference as a statement of intent, not a capability. Ask what ships today, what is proprietary, and what a migration would cost if the specification lands differently from their implementation. That migration cost falls on you, so it belongs in the evaluation, not in a later surprise.