You are here. See how this question connects to other ideas.
Select a node to open its page · Expand to read within the map
One question
How should generative UI approaches be compared?
Compare responsibilities, addresses, state and interaction contracts.
Similar names do not imply identical responsibilities. Here, a contract means agreed message formats, operation meanings and capability boundaries. Compare the layer, then its contracts, then possible combinations. This is an architectural reading of public documentation and Arc implementation, not a benchmark or ranking.
What is being compared?
| Project or concept | Main subject | Learning entry |
|---|---|---|
| AFS / AFS-UI | Operational context and interface projections | Context · Interfaces |
| AUP | Nodes, data connections, events and capabilities | AUP |
| A2UI | Declarative interfaces and data-model updates | A2UI |
| MCP Apps | Interactive tool UIs and their host contract | MCP Apps |
| MCP-UI | MCP Apps tooling and legacy compatibility | MCP-UI |
| AG-UI | Agent–application event exchange | AG-UI |
| Flutter GenUI SDK | Flutter implementation and orchestration | Flutter GenUI |
| Stitch | Interface design and iteration | Stitch |
These rows are not mutually exclusive. A2UI and AG-UI can complement each other; Flutter GenUI uses A2UI; MCP-UI tooling implements MCP Apps. Avoid counting a protocol and its SDK as independent camps.
Where are structure, state and actions?
| Boundary | AUP / AFS-UI | A2UI |
|---|---|---|
| Structure | Nodes with identifiable IDs, types, props and children (not user identities) | Component descriptions and relationships |
| Data | Read resources, write input back, or update node properties from resources; see bindings | Component bindings to a UI data model |
| Interaction | Events bound to explicit AFS operation targets | User actions returned and handled under the protocol |
| Rendering | Target renderers and capability contracts | Client implementations of available catalogs |
| Further question | How are scope, identity, permissions and state ownership configured? | How does the data model connect to business resources? |
For AUP, see nodes and connections. For A2UI, see components, data flow and actions. The final row poses evaluation questions; it does not assert missing features.
| Question | MCP Apps | AG-UI |
|---|---|---|
| Main connection | Tool, UI resource and host | Agent backend and user-facing application |
| Interface focus | Host-contained HTML UI | Event channel; applications and integrations supply concrete UI |
| Data and interaction | UI–host messages, including tool-call requests | Message, tool-call and state events |
| Boundary to verify | Host support, sandbox and capability policy | Supported events and state handling at both ends |
Sources: MCP App construction · AG-UI events.
Where should the AFS-UI argument land?
This topic asks whether interfaces, resources and operations can stay connected through an explicitly addressable context. People use rendered projections; agents use corresponding structures and operation entries within authorized scope. When a view changes, examine which business addresses and operation contracts survive.
The argument is not that others have only pictures. A2UI has structure and path bindings; MCP Apps has resource and tool contracts; AG-UI has state events. Compare where their address and state boundaries lie, what adapters crossings require, and how to verify that a display change preserves an operation.
Work through one example: one poll, two views
This is a hypothetical application design, with illustrative addresses—not an implemented cross-project demonstration.
A presenter asks which foundation should remain stable: resource addresses or operation meanings. The results first appear as a bar chart, then as a table. Changing the view should preserve the votes already cast.
An AFS-UI design could assign responsibilities as follows:
| Object | Example arrangement | When the view becomes a table |
|---|---|---|
| Results | A business Provider exposes /example/poll/results; a Provider adapts resources and their operations to AFS | Read the same resource through a different visual type |
| Voting action | /example/poll/vote accepts the chosen option as an executable operation | Keep the action target; do not directly edit the totals |
| Rules and authority | The execution side checks the participant, whether voting is open and repeat-vote rules | Both views remain subject to these checks |
| Displays | Presenter and audience views read permitted results, with supported subscriptions or refresh wired by the application | Both receive updated results; each may choose its own presentation |
Shared state here means that the business resource owns votes and results. Scrolling or the preferred visual type may remain local to each display. A node ID identifies a chart, table or button; it is distinct from the participant’s identity.
With A2UI, a chart or table can bind to /poll/results in its UI data model. A business service still holds the votes. Application integration sends updated results into that model and connects voting actions to the service. The protocol describes interface updates; persistence, voting rules and shared-poll coordination still need application integration. See the official data flow.
With MCP Apps, an HTML UI can be associated with a tool. The UI asks its host to call a voting tool; the business service handles the request and returns results. Host messaging and capabilities participate in this route. Coordinating fresh results across two hosts still needs an application design. See the official build guide.
Now the comparison is concrete: after replacing the chart, do we still read the same results, call the same action and apply the same rules? AFS-UI places resources and actions within a common addressable working environment. The other approaches can connect to the same business service through their protocol–application boundaries. Whether either design reduces integration effort requires implementation and measurement. It does not follow from this illustration alone.
Sources reviewed on 2026-09-26. Consult current versioned documentation before adopting a specific API.
Check your understanding
What should a useful comparison establish first?
The layer and common scenario, followed by contracts, implementation boundaries and verifiable questions.
Continue along a learning path
- Understand neighboring approachesStep 1 of 8