In my previous article, I argued that the real bottleneck for AI agents is the User Interface (UI). We are stapling rocket engines to bicycles by forcing advanced agents to communicate through basic markdown chatbots. Since then, I’ve been on a journey to find the solution. I didn’t want just a theoretical answer; I wanted to build it. I explored everything from “AI-Orchestrated Development” to Python wrappers, up to new AI protocols, searching for a scalable way to give Agents a native, rich, and dynamic interface. I dedicated time to building a concrete implementation to verify my hypotheses. Here is what I found, what failed, and why I believe A2UI is the protocol we’ve been waiting for to solve this problem. A2UI A2UI The Exploration: A Graveyard of “Almost” Solutions My goal was simple: Build a custom frontend for an agent application without spending weeks on boilerplate. I tried multiple approaches, and most of them hit a wall. Build a custom frontend for an agent application without spending weeks on boilerplate. 1. The “Heavy” Approach: Angular & Flutter My first instinct was to build a real app. I tried both Angular and Flutter. These are standards for enterprise application development, offering robust ecosystems and pixel-perfect control. Angular Flutter The Result: It works, but at what cost? In 2026, setting up a full frontend project is still painful. You have to configure build tools, set up linters, manage complex state stores (Redux, Bloc), and synchronize data models with your backend. This overhead is acceptable for a static, long-term product like a banking dashboard, but for a dynamic Agent? It’s overkill. The Result: It’s overkill Agents need to be able to transmit their UI and adapt on the fly. Hardcoding a heavy client defeats the purpose of an autonomous agent. If every new agent capability requires a sprint of frontend changes, the agent isn’t truly autonomous. It’s just a backend API with a very expensive chat interface. 2. “AI-Orchestrated Development” (AI-Generated UIs) I tried what I call “AI-Orchestrated Development”: a more structured approach where the AI is front and center in generating application code, popularized in early 2026 by tools like GitHub Spec Kit, Gemini Conductor, or Antigravity. This is distinct from “vibe coding” (using AI intuitively without understanding the output). AI-Orchestrated Development aims for a systematic process where AI handles implementation under developer guidance. AI-Orchestrated Development GitHub Spec Kit Gemini Conductor Antigravity The Verdict: While promising long-term, it still generates lots of code. Code that you have to maintain, test, and debug. And I’m not confident in either maintaining AI-generated codebases or letting AI be the sole responsible party for production systems. The Verdict: lots We already spend more time on application maintenance than building. AI-Orchestrated Development risks accelerating this accumulation. We need to reduce the amount of specific code generated, not increase it. 3. HTMX: The Backend-Driven UI I went back to my roots (PHP/AJAX) and tried HTMX. It’s a productive methodology that keeps logic in one place by streaming HTML fragments from the server. HTMX The Problem: HTMX couples the agent too tightly to a specific visual implementation. If you want to render the same agent response on a mobile app, a web dashboard, and a desktop client, you can’t reuse the HTML stream — you’re locked into one presentation layer. The Problem: More fundamentally, HTML is too low-level for an agent to reason about. An agent shouldn’t be worrying about CSS classes, DOM nesting, or accessibility attributes. It should focus on intent and logic, not pixels. Sending declarative data is more efficient, more universal, and can be consumed by different types of clients. intent logic 4. Python Wrappers (Streamlit, Gradio, Chainlit) These are great for prototypes. Tools like Streamlit, Gradio, and Chainlit offer a small code surface and instant deployment. Streamlit Gradio Chainlit The Flaw: The “Glue Code” Hell. You inevitably hit a wall where the library doesn’t support the specific interaction or component you need. Maybe you need a custom drag-and-drop interface or a specific data visualization. You lose control over style, and you end up writing hacky workarounds (custom HTML injection, iframe bridges) to connect the agent’s state to the UI components. The Flaw: They are also not truly dynamic — they are rigid templates filled with data, not fluid interfaces generated by the agent’s needs. You are still building a form; you are just doing it in Python instead of React. 5. Chat Extensions (Slack/Teams/Workspace) Building into existing workflows seems smart. Why build a new UI when you can just deploy a bot to Slack or Google Chat? The Limit: It doesn’t scale. You end up building a specific adapter for Slack, another for Teams, another for Google Chat. Each platform has its own proprietary UI kit (Block Kit, Adaptive Cards) with different limitations. The Limit: You want to build your agent once and have it project its UI anywhere, not rewrite the presentation layer for every host app. This fragmentation increases the maintenance burden and prevents you from creating a consistent user experience across platforms. once The Epiphany: Separation of Concerns I realized something fundamental during this process: Everything is disposable. Everything is disposable. We shouldn’t be precious about the UI code. We should focus on the declarative side. Just as humans use HTML not because we love drawing pixels, but because we want to say “Here is a link” or “Here is an image,” agents need a high-level language to describe what needs to be shown, not how to draw it. declarative what how The Agent should be responsible for the Data and the Logic. The Client should be responsible for the Style and the Rendering. Data Logic Style Rendering This separation allows the agent to be “brain-heavy” and “UI-light,” deferring the complex rendering logic to the client, which is what clients are best at. The Solution: A2UI (Agent-to-User Interface) Enter A2UI. A2UI A2UI I built a demo app using this protocol, and I was genuinely impressed by its elegance. A2UI is a JSONL-based declarative protocol that creates a standard contract between the AI and the user interface. JSONL-based declarative protocol How it works Instead of streaming markdown tokens like a traditional LLM, the agent streams structured JSON objects representing UI components. Why it wins Production-Ready at Google: A2UI isn’t vaporware — it’s already integrated into Google products like Opal, Gemini Enterprise, and the Flutter GenUI SDK.Transport Agnostic: It works over HTTP (via the A2A protocol), WebSockets, or carrier pigeons. The protocol doesn’t care how the JSON gets there.Progressive Rendering: The UI appears as the agent “thinks” it. Components stream in one by one, making the interface feel alive and responsive, much like text streaming but for rich UI elements.Framework Agnostic: The client implementation (React, Angular, Lit) decides how a “Card” looks. The agent just says “I need a Card”. This means you can have a “Material Design” client and an “iOS Cupertino” client rendering the exact same agent response natively.Secure: No arbitrary JavaScript execution. It’s just declarative data, mitigating injection risks. This is critical for enterprise adoption where security reviews block “dynamic code generation.”LLM-Friendly: Flat, streaming JSON structure designed for easy generation. LLMs can build UIs incrementally without perfect JSON in one shot. Production-Ready at Google: A2UI isn’t vaporware — it’s already integrated into Google products like Opal, Gemini Enterprise, and the Flutter GenUI SDK. Production-Ready at Google: Opal Gemini Enterprise Flutter GenUI SDK Transport Agnostic: It works over HTTP (via the A2A protocol), WebSockets, or carrier pigeons. The protocol doesn’t care how the JSON gets there. Transport Agnostic: A2A protocol Progressive Rendering: The UI appears as the agent “thinks” it. Components stream in one by one, making the interface feel alive and responsive, much like text streaming but for rich UI elements. Progressive Rendering: Framework Agnostic: The client implementation (React, Angular, Lit) decides how a “Card” looks. The agent just says “I need a Card”. This means you can have a “Material Design” client and an “iOS Cupertino” client rendering the exact same agent response natively. Framework Agnostic: Secure: No arbitrary JavaScript execution. It’s just declarative data, mitigating injection risks. This is critical for enterprise adoption where security reviews block “dynamic code generation.” Secure: LLM-Friendly: Flat, streaming JSON structure designed for easy generation. LLMs can build UIs incrementally without perfect JSON in one shot. LLM-Friendly: Note: A2UI is currently at v0.8 and still in active development. The protocol has some rough edges, and for production use. The best approach is to wait for native integration in tools like Gemini Enterprise or the Agent Development Kit (ADK). Note: v0.8 Gemini Enterprise Agent Development Kit (ADK) A2UI vs AG-UI: Two Philosophies I also looked at AG-UI, another emerging standard in this space. AG-UI AG-UI AG-UI aims to blend the frontend and backend deeply, creating “AI-First” apps from the ground up with a focus on real-time event loops. It’s powerful but requires you to rethink your entire application architecture regarding state synchronization and event handling.A2UI focuses on extending the capabilities of chat-based interaction to be richer. It’s a bridge that lets agents “speak UI” using standard components. It feels more like an evolution of the chat interface into a command center rather than a complete replacement of the application stack. AG-UI aims to blend the frontend and backend deeply, creating “AI-First” apps from the ground up with a focus on real-time event loops. It’s powerful but requires you to rethink your entire application architecture regarding state synchronization and event handling. AG-UI A2UI focuses on extending the capabilities of chat-based interaction to be richer. It’s a bridge that lets agents “speak UI” using standard components. It feels more like an evolution of the chat interface into a command center rather than a complete replacement of the application stack. A2UI extending I believe A2UI is the scalable path forward for most agent implementations. It respects the separation of concerns and integrates seamlessly with existing systems via protocols like A2A (Agent-to-Agent). A2UI Conclusion: The 2026 Shift We are moving towards a schism in frontend technology, and it’s happening faster than we think: Static Apps (the stock): Dashboards, retail sites, and specialized tools. These will still be built with efficient frameworks for speed, precise control, and specific user journeys where the path is known. They represent the bulk of existing applications.Dynamic Agent Interfaces (the flow): Powered by new protocols like A2UI. These will replace the “Chatbot” with something far more powerful — interactive, component-based, and generated on the fly. This is where the new growth is happening. These interfaces will emerge when the user’s intent is ambiguous or highly variable, like in Agentic Commerce. Static Apps (the stock): Dashboards, retail sites, and specialized tools. These will still be built with efficient frameworks for speed, precise control, and specific user journeys where the path is known. They represent the bulk of existing applications. Static Apps (the stock): Dynamic Agent Interfaces (the flow): Powered by new protocols like A2UI. These will replace the “Chatbot” with something far more powerful — interactive, component-based, and generated on the fly. This is where the new growth is happening. These interfaces will emerge when the user’s intent is ambiguous or highly variable, like in Agentic Commerce. Dynamic Agent Interfaces (the flow): A2UI Agentic Commerce I am convinced that 2026 is the year we stop building UIs for agents and start letting agents project their UIs to us. We shouldn’t spend too much time on UI. Let it be personalized by the agent so we can focus on what truly matters: integration and instruction. for project In the next article, I will share the source code and a full demo of the application I built using A2UI. Stay tuned! In the next article, I will share the source code and a full demo of the application I built using A2UI. Stay tuned!

Dash

Render

Google

Chat Is a Terrible Interface for Agents—and 2026 Will Prove It

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

How I Built a Personal Assistant Using Google Cloud and Vertex AI: mAIdAI

How to Build an AI Generated Calculator Without Custom JavaScript

How to Extend the Expressiveness of AI Agents: Building With A2UI

The Noonification: Use This 7-Step McKinsey Framework to Solve Any Problem (1/10/2023)

The Noonification: A Taxonomy of Inclusiveness (1/11/2024)

The Noonification: What is the InfiniteNature-Zero AI Model? (11/19/2022)

How I Built a Personal Assistant Using Google Cloud and Vertex AI: mAIdAI

How to Build an AI Generated Calculator Without Custom JavaScript

How to Extend the Expressiveness of AI Agents: Building With A2UI

The Noonification: Use This 7-Step McKinsey Framework to Solve Any Problem (1/10/2023)

The Noonification: A Taxonomy of Inclusiveness (1/11/2024)

The Noonification: What is the InfiniteNature-Zero AI Model? (11/19/2022)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps