A2UI : a more liberal positioning.

[ksridhar]

Prelude

I am sorry if this is not the right place for posting this observation. I was looking for some mailing lists but could not find one (may be my bad). i am presenting here a conversation that i had with a LLM based on a A2UI context that highlights the issue statement. I am using the output of the LLM here for a clearer articulation of my case.

This is perhaps another delineation of the phrase '...as a specialized protocol that aims to solve the specific problem of interoperable, cross-platform, generative or template-based responses' mentioned here

---

Position

A2UI need not be connected to AI or agents at all.
It is orthogonal to AI and can sit cleanly between:

• REST + HATEOAS (runtime, navigational, state-driven)
• OpenAPI (design-time, contract-driven)

AI/agents are optional consumers, not defining characteristics.

---

Why this may be conceptually correct

1. A2UI addresses a representation gap, not an intelligence gap

The core problem A2UI solves is:

APIs do not expose interaction intent in a way that UIs can reliably consume.

This exists regardless of AI:

• Human-driven UIs suffer from this gap
• Low-code tools suffer from it
• CLI and accessibility UIs suffer from it

No reasoning, planning, or autonomy is required.

So A2UI is fundamentally about exposition, not cognition.

---

A2UI fits naturally with REST + HATEOAS

In REST:

• Resources represent state
• Links represent possible transitions
• Media types define representation semantics

What REST deliberately avoids specifying:

• Widgets
• Forms
• Layouts
• Input affordances

A2UI can be layered as:

• UI affordance metadata inside or alongside representations
• Interpreted by generic clients

This is very close in spirit to:

• HTML forms
• AtomPub
• Siren / HAL-Forms / JSON Hyper-Schema

So A2UI can be seen as:

A generalization of hypermedia controls for modern UI systems.

No AI needed.

---

A2UI also fits cleanly with OpenAPI

OpenAPI is:

• Design-time
• Contract-first
• Operation-centric

A2UI can attach to:

• Schemas
• Operations
• Parameters
• Request/response bodies

In this context, A2UI enables:

• Deterministic UI generation
• Schema-driven forms and flows
• Consistency across clients

Again:

• No autonomy
• No inference
• No learning

Just structured intent → deterministic rendering.

---

The key insight: A2UI is protocol-adjacent, not AI-adjacent

A2UI may be closer to:

• Media types
• Schema vocabularies
• Interaction contracts

Than to:

• Agents
• LLMs
• Planning systems

It answers:

“How should a client present and collect interaction for this resource?”

Not:

“What should I do next?”

---

Clean conceptual placement (important)

A2UI without AI is still complete.
AI without A2UI would be 'blind'.

We can place A2UI as:

Domain semantics
    ↓
API semantics (REST / OpenAPI)
    ↓
Interaction intent (A2UI)
    ↓
Presentation realization (Web / Mobile / CLI / Voice)

AI, if present, operates across or within layers — never as the foundation.

---

Final candid comment

Associating A2UI with Agents unfortunately biases people toward thinking “AI”.

Conceptually, it is better understood as:

• API-to-Interaction
• API-to-Affordance
• API-to-Experience

A2UI is a unifying abstraction that works equally well with REST+HATEOAS and OpenAPI — with or without AI.