Technical Context
I took a close look at Google A2UI (Agent to UI), and I appreciate that it isn't just "another UI framework," but a protocol. The agent streams JSONL messages, and the client renders the interface natively via a predefined Component Catalog. This is critical for LLMs: the model can output the UI incrementally without needing to generate a perfect HTML structure in a "single shot."
I see three practical layers in A2UI: surfaceUpdate for structure, dataModelUpdate (or updateDataModel) for state via JSON Pointer (RFC 6901), and actions for events. Architecturally, this means the interface is deterministic based on the catalog, and the agent only manages declaration and data, without executing arbitrary code on the device.
The discussion highlighted a key alternative to the approach where an "LLM writes HTML → server renders it → image is sent to the phone." In my projects, I almost always advise against that scheme: server-side rendering to images breaks accessibility, interactivity, and event monitoring, while adding latency and infrastructure costs. A2UI removes the need for HTML generation entirely, maintaining control and security.
I was particularly intrigued by the case of running an agent locally on a phone: Termux + Linux environment + a web app in Kiosk Mode, where the UI is formed via a JSON renderer directly on the device. According to A2UI, this is feasible: the agent and renderer can communicate via localhost, turning the JSONL stream into a "UI bus" within a single device.
Business & Automation Impact
For business, the main shift is that I can design AI solutions for business where the interface becomes an extension of the agent, rather than a separate frontend project taking months. When an agent can assemble forms, buttons, statuses, task cards, and checklists on the fly, the cycle from "idea → pilot → operation" accelerates significantly.
Companies with highly variable scenarios win here: field services, audit teams, warehouses, maintenance, and sales. In these contexts, the UI changes constantly based on context, and A2UI allows streaming changes and updating only the data model without rebuilding the entire screen. Those who try to drag a full HTML/CSS generator into an agentic product lose out, eventually having to heroically fix broken layouts and injection vulnerabilities.
A local agent on mobile (Termux/Kiosk) adds another layer of value: autonomy and privacy. I can build AI automation for locations with unstable internet while minimizing data leaks. But this isn't a "install apk and forget" scenario: in real AI architecture, you need to plan for model updates, memory limits, quality degradation, and telemetry without violating compliance.
In Nahornyi AI Lab's experience, the most frequent failure point is events and state. In A2UI, the flow is unidirectional, and actions require an explicit feedback loop (POST/endpoint). If you don't design the event contract, idempotency, and retry queues (for bad networks or local glitches) at the start, the "smart UI" turns into a chaotic chat with buttons.
Strategic Vision & Deep Dive
I believe A2UI is not about UI, but about risk management in generative interfaces. The Catalog acts as a whitelist of components, serving as an architectural emergency brake against "the agent generated something executable that shouldn't be run." In corporate AI implementation, such a guardrail is more valuable than another attempt to let a model write frontend code.
My forecast: we will arrive at two product modes. The first is "cloud agent + client renderer," where the agent lives in the infrastructure, and clients on iOS/Android/Web receive a progressive UI stream. The second is "edge agent on-device" for kiosks, industrial tablets, and field devices, where A2UI works as a local protocol between the agent and the shell.
In Nahornyi AI Lab projects, I would implement A2UI as a presentation layer over the domain model, not as a demo toy. I lock the Catalog with versioning, describe dataModel schemas, introduce contract tests on surfaceUpdate, and implement observability: which components break most often, where the agent tries to "push" a non-existent widget, and which actions fail to deliver.
If you need practical artificial intelligence integration into a mobile environment, I recommend starting not with model selection, but with the choice of UI protocol and security perimeters. A2UI sets a discipline here that you would otherwise have to invent yourself.
This analysis was prepared by Vadim Nahornyi — Lead Expert at Nahornyi AI Lab in AI architecture, AI implementation, and AI automation in the real sector. I get involved from architecture to production stages: UI protocols (A2UI/alternatives), on-device perimeters, observability, security, and economics. Write to me, and together we will break down your case into components and assemble an implementation plan with measurable SLAs.