A draft RFC proposing four protocol additions to A2UI v1.0: pending state for unresolved bindings, a streaming lifecycle flag on updateDataModel, an append patch op for efficient text streaming, and write bindings + origin tracking so components can mutate the data model client-side and the agent automatically sees what the user changed (instead of all-or-nothing sendDataModel).
Each proposal has its own stage. Rendered UI on the left, the exact A2UI wire messages on the right — poke the buttons and watch what the protocol would send.
A2UI v0.9 treats UI description as a single transaction: server says "here's the UI," client renders it. In practice, agents generate UI progressively — skeleton first, data streaming in over seconds — and the data model often holds more state than the agent should see. Today there is no standard way to:
- Render pending bindings before their data arrives (every client invents its own).
- Signal that a value is mid-stream vs. final (A2UI already streams via repeated
updateDataModel; what's missing is the lifecycle flag so renderers can show typewriter cursors, disable incomplete actions, announce a11y updates). - Append to long streamed text without re-sending the whole accumulated value each delta (a 10,000-char response today takes ~500 KB; with append, ~10 KB).
- Express client-side data-model writes. Input components (TextField, Slider, etc.) write back to the data model today but it's informal. There's no protocol vocabulary for "this binding writes" on custom components, and
sendDataModelechoes either everything or nothing — not "just what the user changed." Write bindings + origin tracking formalize both: components declare writable bindings; the host tags entries by who wrote them; the agent receives client-origin entries automatically. Paginated tables, forms with PII, dashboards with sidebar widget state — all fall out naturally.
The four proposals are all backward-compatible and address these in minimal surface-area additions.
| File | What |
|---|---|
RFC.md |
The draft proposal. Wire-format examples, ASCII lifecycle diagram, migration path, non-goals. |
index.html |
Fully client-side demo — no backend, no build step. Shows each proposal's effect on a rendered surface with synchronized wire log. Hosted via GitHub Pages at the URL above. |
Just open the file. Zero dependencies, zero build step:
git clone https://github.com/vpm238/a2ui-progressive-rendering-rfc
cd a2ui-progressive-rendering-rfc
open index.html # macOS; or any static serverThis is an experience-report-style proposal: it's grounded in building one production A2UI application (a Claude-powered multi-turn consultant) and the gaps we hit integrating streaming LLM output into an A2UI surface. Intended for discussion on google/A2UI/discussions and the A2UI contributor community.
See RFC.md for the full proposal and reasoning.
MIT. See LICENSE.