A2UI 1.0 Needs Tests for Who Can Call Each Function
A2UI 1.0 adds two-way function calls to generated interfaces. Its catalog rules create a concrete testing boundary: check which callers can execute each function, preserve application permissions, and verify the renderer version actually in use.

Summary
A2UI 1.0 adds two-way function calls to generated interfaces. Its catalog rules create a concrete testing boundary: check which callers can execute each function, preserve application permissions, and verify the renderer version actually in use.
Key Updates
- A stable protocol, with uneven platform adoption. Google announced A2UI 1.0 on November 11. Agents describe screens using registered components; hosts render them. The announcement lists Jetpack Compose at 0.9.1 with 1.0 coming soon, Lynx at 0.9, and Gemini at 0.9.1. A stable specification does not establish universal 1.0 support. Announcement
- Function calls now run in both directions. The evolution guide defines agent-to-renderer and renderer-to-agent calls. Catalog functions declare allowed callers; the default is renderer-only. A renderer must reject remote calls to renderer-only or unregistered functions. These checks happen at runtime, using catalog definitions. Mixed catalogs must share a protocol version. Evolution guide
- Validate before delivering the screen. The MCP Apps guide recommends checking message arrays on the server with the Agent SDK validator. Otherwise, malformed component properties or missing child references can fail inside the client iframe. Embedding an A2UI renderer in an MCP App also introduces host sandbox and content-policy constraints. Integration guide
Why It Matters
Our engineering interpretation is that the component catalog now deserves review alongside executable application interfaces. A screen that looks correct can still expose the wrong function to the wrong caller.
Caller restrictions answer a protocol question. Application authorization must still answer whether this user may perform this operation on this record. For example, allowing an agent to request a reservation change should not establish permission to change another customer's reservation. A confirmation screen should represent the exact action the service will authorize.
The documents describe intended behavior. This review did not independently test renderer conformance, permission enforcement, performance or cross-platform parity.
Builder Takeaway
Before a rollout, use a harmless test operation in a non-production environment. Record the agent, renderer and catalog versions. Exercise an allowed call, a forbidden caller and an unknown function; inspect both the response and whether any side effect occurred. Separately submit a request for a record the test user cannot access. Keep the server's authorization result in the evidence, alongside payload-validation results and a successful UI round trip.
Related Past Coverage
API Changes Need Previews of the Tools They Generate examined reviewing generated CLI contracts before merge. A2UI adds a different review target: the execution permissions behind a generated interface. The earlier article supplies historical context, not evidence of A2UI behavior.
Sources
- A2UI 1.0 announcement — Google Developers Blog, November 11, 2026.
- A2UI 1.0 evolution guide — A2UI project, reviewed November 12, 2026.
- Render A2UI Inside an MCP App — A2UI documentation, reviewed November 12, 2026.
How strong is this signal for builders?
Signal feedback is stored anonymously and used to improve Tech Radar editorial quality.
If this was useful, we can send you the next one.
We follow changes in software, AI, and infrastructure—and explain what they mean for people building and running systems.
Sent by uniQubit · 1407 - 177 Nonquon Rd., Oshawa, ON L1G 3S2, Canada · info@uniqubit.ca
Privacy policy · Your confirmation email includes the controls to unsubscribe or change tracking.
Want more operational technology signals?
Follow uniQubit Tech Radar or contact uniQubit about a product, partnership, or operational software need.