v0.9.1 turns agent output into declarative component requests
A2UI v0.9.1 lets an agent describe an interface as structured data. The client keeps a catalog of approved components and maps names such as a text field to its own widgets. That boundary is the main idea: model output chooses among trusted building blocks instead of becoming executable frontend code. Teams can preserve their design system and platform behavior while allowing an agent to assemble or update a screen.
The documented flow has 4 stages. An agent produces an A2UI response, a transport such as A2A or AG-UI carries it, a renderer resolves the JSON, and client code draws native components. Incremental messages can change the surface as a conversation develops. This is useful for generated forms or approval views, but the host still owns data validation, component behavior, event routing, and what actions go back to the agent.
What happened when we ran it
Our sandbox cloned commit a6a2eba into an unprivileged Debian container with 3 CPUs and 8 GB of RAM. Yarn installation succeeded in 154 seconds, adding 2,547 packages and taking 3,045 MB on disk. Before dependencies, the checkout already contained 3,084 files, roughly 247,714 source lines, and occupied 179 MB. This is a large development environment for a format described as lightweight.
The harness found no build script or target and no test script or target, so both steps were skipped. It did not produce a passing build or test result. The repository scan found 15 CI workflow files, no Dockerfile, no root tests directory, and Yarn workspaces. Upstream automation covers web, Python, Flutter, Kotlin, Swift, specifications, documentation, audits, and other areas, but our generic root run did not exercise those separate paths.
The 2,547-package install supports four maintained renderer paths
The renderer reference marks React, Lit, Angular, and Flutter stable for v0.9.1. Web teams can choose a framework-specific package, while Flutter's GenUI SDK covers mobile, desktop, and web. Each renderer must buffer messages, implement the A2UI lifecycle, map abstract components to native widgets, and return user actions. Sharing a protocol reduces duplication at the agent boundary; it does not remove framework-level implementation work.
The restaurant demo asks for Node.js 18 or newer, Corepack, uv, and a Gemini API key. Its Yarn command resolves workspaces, prepares renderer code, starts a Python agent, and opens a Lit client. A Composer can generate JSON without installation, and an AG-UI scaffold offers another entry point. Those options help evaluation, though a production host still needs a pinned protocol version, catalog policy, model path, and transport.
v1.0 is a release candidate with uneven renderer coverage
The README calls v0.9.1 the current production release and v1.0 a release candidate. It labels v0.8 legacy and warns that specifications and implementations are evolving. The maintained-renderer table lists v1.0 support for React, Lit, Angular, and Flutter as planned. SwiftUI and Jetpack Compose also have no maintained v0.9.1 implementation in that table, despite active Swift and Kotlin work in the repository.
Roadmap wording deserves restraint. The project hopes to stabilize v1.0, add more official renderers, support more transports, and cover more agent frameworks. Those are collaboration targets rather than delivery promises. If an application must ship on several platforms, freeze the exact schema and renderer packages you tested. Cross-platform intent is useful only when every target implements the same component and action semantics.
Open v0.9 issues show payload validation still needs work
Open issue 2297 says the v0.9 message processor can commit unknown component types without validating the incoming envelope against the schema. The reporter notes that the 3 current web renderers display unknown types as nothing, so the report does not claim a direct exploit in those renderers. It identifies a defense gap for consumers that read the stored component model or add new component behavior.
Open issue 2389 concerns an agent-supplied expression template with no length or part-count cap, allowing repeated expensive parsing on the client main thread. An associated pull request proposes limits, but both remained open when checked. A2UI's catalog model reduces the risk of arbitrary generated code; it does not make every declarative input cheap or valid. Treat remote agent messages as untrusted and apply size, depth, catalog, and action limits before rendering.
September 2 activity is high alongside 346 open items
GitHub recorded the last push on September 2, 2026, and showed 16,268 stars plus 346 open issues and pull requests. commit a6a2eba itself added unit coverage for basic catalog components, and later work that day connected the Swift basic catalog to a gallery client. The pace is unmistakably active. The combined open count also reflects a large specification, several SDKs, renderer implementations, samples, and ongoing v1.0 work.
GitHub's latest-release endpoint returned no release, while repository tags showed v0.9 and v0.8; the README separately names v0.9.1 as the production release. That packaging split does not prove the project is inactive, because current pushes and pull requests show the opposite. It does mean adopters should identify the package registry and version for each language rather than expecting one GitHub release asset to define the whole stack.
A2UI fits teams that already own an agent frontend
A2UI makes sense when a remote agent must express more than text and the client team wants final control over components. json-render is narrower and attractive for a React application built around Zod catalogs. CopilotKit supplies more of the frontend runtime and agent connection. A2UI is the protocol-oriented choice when several renderers or transports need to agree on one declarative surface model.
Our 3,045 MB installation is the practical warning. The repository contains working renderer and SDK areas, detailed docs, and 15 workflow files, yet our harness had no build or test target it could run. Trial v0.9.1 in one bounded surface, reject unknown components and oversized expressions, and measure the chosen renderer in your own app. Wider adoption can follow after the team has a versioning and compatibility plan.