Leveraging A2UI message parts for layout-first, progressive rendering (without spec or transport changes)

[Dodolist]

Context

A2UI is designed to be LLM-friendly and incrementally updateable, enabling progressive rendering through
beginRendering, surfaceUpdate, and dataModelUpdate.

While running the Lit sample (Restaurant Finder) locally and inspecting the A2UI responses,
I observed that each interaction waits for a fully composed UI state before rendering,
resulting in a blocking loading spinner even though the protocol is designed to support incremental updates.

This issue is not about adding new features or transports, but about better leveraging
existing A2UI capabilities to improve perceived responsiveness.

---

Observed Behavior (from running the sample)

In the current flow, each agent response delivers a single HTTP response containing:

• beginRendering
• surfaceUpdate (full component tree)
• dataModelUpdate (full data model)

Although these parts are conceptually ordered to support incremental rendering,
they are delivered together as a fully composed UI state.
As a result:

• The renderer waits until all parts are available
• A loading spinner is shown
• The UI appears only once everything is ready

This same pattern occurs both on the initial render and on subsequent user actions
(e.g. clicking “Book Now”).

---

Capability vs. Usage Gap

At the protocol level, A2UI already supports:

• Stable component IDs
• Independent surfaceUpdate and dataModelUpdate
• Message structures that represent incremental rendering stages
• Incremental application of updates by the renderer

However, the current samples and usage patterns do not take advantage of this design.
In practice, UI structure and data are always delivered and rendered together.

---

Proposed Interaction Pattern (Layout-first, Progressive Rendering)

This issue proposes a recommended usage pattern, not a spec change:

1. Process beginRendering and surfaceUpdate as soon as they are available

   • Render the UI structure immediately
   • Data bindings may be empty or unresolved at this stage
   • This naturally results in a skeleton / placeholder-like UI

2. Apply dataModelUpdate incrementally

   • Populate the existing component tree as data becomes available
   • Preserve component IDs throughout
   • Avoid full regeneration or blocking loading states

This could be achieved either by:

• Splitting agent output into multiple responses, or
• Delivering surfaceUpdate and dataModelUpdate separately within a progressive delivery model

No protocol, spec, or transport changes are required.

---

Scope Clarification

This proposal:

• ❌ Does not introduce new message types
• ❌ Does not require SSE, WebSockets, or new transports
• ❌ Does not mandate a specific UX
• ✅ Focuses on renderer-side handling and recommended interaction patterns
• ✅ Builds on existing A2UI design and roadmap foundations

---

Why This Matters

A2UI’s architecture is explicitly designed to enable incremental rendering, but current samples
demonstrate a fully blocking interaction model.
Adopting and documenting a layout-first pattern could:

• Improve perceived responsiveness
• Better demonstrate A2UI’s incremental design
• Serve as a stronger reference for upcoming renderers (e.g. React)

---

Open Questions

• Would this pattern be appropriate to demonstrate in samples or renderer examples?
• Are there renderer-level constraints that currently prevent early rendering of surfaceUpdate without data?
• Would maintainers be open to documenting this as a recommended interaction pattern?

I’m happy to help prototype or document this further if it aligns with the project’s direction.