A2UI

Server-driven UI for modules that need live interaction.

Democr.ai implements and extends Google's A2UI protocol, letting modules describe pages and publish effects while clients render native web or desktop interfaces. The backend remains the owner of business behavior.

Authoring model

The module declares the interface; the client renders the contract.

Democr.ai's A2UI layer builds on Google's A2UI protocol and extends it with YAML-first module pages, runtime effects, native desktop rendering, and SDK-managed server actions.

YAML pagelayout & component ids

Python renderloads YAML, seeds data via SDK

Actionserver-owned behavior

Client effectappend / replace / stream

01

YAML first

Pages declare layout, components, bindings, actions, and stable component identifiers in YAML.

02

Python render functions

A view loads the YAML, prepares minimal data, and seeds page data or stores through the SDK.

03

Runtime effects

Actions can append, replace, open drawers, navigate, and publish stream updates without rebuilding the whole page.

Live example

An agent can add interface elements while the conversation continues.

The capture shows a chat agent publishing runtime updates and inserting structured components into the same message timeline.

Democr.ai chat interface with an agent composing a server-driven UI response

Democr.ai chat timeline rendering an interactive A2UI component

Democr.ai chat interface showing streamed agent output and generated UI

Dynamic surfaces

Streaming UI matters when the agent is still working.

A2UI is designed for interactions where the final result is not the only useful UI update.

01

Chat messages

A message list can receive user turns, ephemeral agent steps, streamed text, components, and final persisted rows.

02

Progress updates

Long-running actions can publish state changes while background work continues.

03

Generated components

Tools and agents can add tables, cards, lists, charts, or other structured UI blocks to the same conversation surface.

Client contract

One protocol drives a native desktop renderer and web clients.

The strongest test of a server-driven UI protocol is whether genuinely different clients can consume it. Democr.ai runs a native desktop renderer and web renderers from the same payloads — two very different stacks, one wire format.

01

Native and web, same contract

A Qt/PySide desktop renderer and a browser renderer consume the same A2UI components and effects. If the protocol leaked rendering assumptions, two stacks this different could not share it.

02

Stable component ids

Effects address predictable targets — message lists, drawers, composers, collection-capable components — so the same update lands on every client.

03

Incremental updates

Dynamic screens append or replace focused elements instead of forcing full-page rerenders, on every renderer.

Example

YAML page excerpt

The example shows the contract shape without turning the page into implementation documentation.

YAML page excerptexcerpt

- kind: Row
  id: chat_page
  children:
    - kind: ThreadList
      id: chat_thread_list
    - kind: MessageList
      id: chat_message_list
    - kind: Composer
      id: chat_composer
      send_action:
        name: chat.submit_message

Use these pages to move from the concept to adjacent parts of the runtime.