Chat is a fine starting point; however, it is a poor finish line for serious work.

I have a simple test for any Agent product.

Can it help me finish a real task without making me feel like I am arguing with a support bot from 2020?

Too often, the answer is no.

We ask an Agent to book a flight, configure a service, review an invoice, or triage a customer issue. It starts with confidence; however, the entire process eventually degrades into a slow interview. What date? Which option? Confirm this. Re-enter that. Pick one from a list the Agent describes in prose.

That is not intelligence; rather, that is a web form trapped inside a chat bubble.

This is why Google's A2UI (Agent-to-User Interface) caught my attention. A recent MarkTechPost summary explains it well: A2UI lets Agents generate rich, interactive user interfaces using structured JSON instead of throwing more text at the User.

Google's own post, Introducing A2UI: An open project for agent-driven interfaces, describes the bigger idea. The Agent does not need to respond with another paragraph; instead, it can respond with a small, task-specific interface.

If this pattern matures, I believe it will change how we think about Design Systems, Frontend Architecture, and Agent safety. This is not because A2UI magically solves everything. It does however point to a healthier model: Agents should compose from trusted building blocks, not improvise their way through your User Interface.

How A2UI Works

A2UI lets the Agent order from the menu, not wander into the kitchen.

At its core, A2UI is a contract between an Agent and a host application.

The A2UI Protocol - A2UI defines a structured, streaming JSON format. The Agent sends that JSON to a Client. The Client then renders the interface using components it already trusts.

That distinction matters.

The Agent is not sending HTML. It is not sending CSS. It is not sending JavaScript. It is sending a description of what it wants the interface to contain.

Think of it like a restaurant.

The Agent can order from the menu. Text field. Date picker. Button. Card. It cannot walk into the kitchen, grab a knife, change the gas line, and invent a new recipe. The kitchen is your Frontend runtime. The menu is your Component Catalog.

That is a sane boundary.

A2UI uses a flat adjacency list of components with ID references. That sounds dry; however, the User impact is useful. The interface can render progressively as the Agent produces the response. Instead of waiting for a full User Interface payload, the host can show pieces as they arrive.

Here is a simplified v0.9.1-style example for a booking surface:

{
  "version": "v0.9.1",
  "createSurface": {
    "surfaceId": "booking",
    "catalogId": "https://a2ui.org/specification/v0_9_1/catalogs/basic/catalog.json"
  }
}
{
  "version": "v0.9.1",
  "updateComponents": {
    "surfaceId": "booking",
    "components": [
      {
        "id": "title",
        "component": "Text",
        "text": "Book Your Table",
        "variant": "h1"
      },
      {
        "id": "datetime",
        "component": "DateTimeInput",
        "value": { "path": "/booking/date" },
        "enableDate": true
      },
      {
        "id": "submit-text",
        "component": "Text",
        "text": "Confirm"
      },
      {
        "id": "submit-btn",
        "component": "Button",
        "child": "submit-text",
        "variant": "primary",
        "action": {
          "event": { "name": "confirm_booking" }
        }
      }
    ]
  }
}

Nothing here executes arbitrary code. That is the point.

The renderer owns the real User Interface. The Agent describes intent. The host decides what that intent is allowed to become on screen.

This is also why, in my opinion, I do not see A2UI as a replacement for REST, GraphQL, WebSockets, or Frontend frameworks. It sits above those concerns. It is a semantic User Interface layer for Agent-driven interaction.

The Agent stack is starting to look like lasagna. Some layers are useful. Some will be scraped off later. A2UI has a decent shot because it deals with a real challenge: chat is too narrow for many workflows.

The Security Promise

Declarative User Interface reduces the blast radius; however, it does not remove Judgment from the system.

The strongest argument for A2UI is not visual polish. It is security.

A2UI makes a clear bet: if Agents can only choose from approved declarative components, we can avoid a large class of challenges caused by Agents returning arbitrary HTML or JavaScript.

That includes many Cross-Site Scripting risks. Good. I like boring security wins.

Giving an Agent raw DOM power is like giving a toddler a welding torch because they said they wanted to build a chair. In my opinion, perhaps they will surprise you; however, it is far more likely that someone will lose an eyebrow!

A2UI gives the toddler LEGO bricks instead.

Still, we should not pretend LEGO bricks make the room safe by default. A malicious or confused Agent can still assemble something misleading.

What A2UI reduces:

• Arbitrary code execution through Agent-generated JavaScript
• Direct remote DOM manipulation
• Untrusted HTML injection
• Some classes of renderer abuse, if the renderer is strict and well-tested

What remains:

• User Interface impersonation and phishing
• A safe TextField can still ask for a bank password.
• A safe Button can still say "Verify Identity."
• Over-permissive component catalogs
• If a custom component can trigger powerful side effects, that component becomes part of the attack surface.
• Renderer bugs
• The security model depends heavily on the renderer doing the right thing every time.
• Prompt injection through catalog descriptions
• If component descriptions are fed into an Agent prompt, those descriptions need the same suspicion you would apply to any other prompt input.

This is where Teams need to slow down.

A2UI can help remove a dangerous class of challenges. It cannot protect a poorly designed product workflow. It cannot decide whether a User should be asked for a secret. It cannot fix weak authorization.

Security professionals already know this pattern: Move the boundary. Shrink the blast radius. Validate inputs. Audit side effects.

A2UI gives us a better boundary. We still have to do the adult work.

A2UI and MCP Are Not Enemies

The smart Architecture is native where possible and sandboxed where necessary.

The Agent protocol space is busy.

We have A2A, MCP, AG-UI, A2UI, tool protocols, app SDKs, and a growing pile of naming debates that could power a small conference panel forever.

The fair question is: do we really need another protocol?

My answer is: in my opinion, perhaps, if it draws a clean boundary. A2UI and MCP Apps solve different challenges.

MCP Apps, along with similar app SDK patterns, are closer to a sandboxed iframe model. That is useful when you need a full web application, custom JavaScript, complex visualization, canvas rendering, or something that simply does not fit into a fixed Component Catalog.

A2UI is different. It favors native rendering by the host application. The Agent sends structured User Interface intent. The host renders trusted components.

Google LLC's guidance in A2UI + MCP Apps: Combining the best of declarative and custom agentic UIs - Google Developers Blog lays out three useful patterns:

A2UI over MCP

• MCP can act as the transport layer.
• The payload can be application/a2ui+json.
• This lets existing MCP tool servers return native A2UI experiences.

MCP App inside A2UI

• An A2UI surface can wrap an MCP App inside a secure, double-iframe sandbox.
• MCP Apps in A2UI - A2UI explains this isolation model.
• This fits mixed experiences, such as a native status panel around a complex embedded app.

A2UI inside an MCP App

• An MCP App can bundle an A2UI renderer.
• This gives Teams a migration path when the host does not yet support native A2UI.

That is a practical model. Use A2UI when you want safe, native, brand-aligned components. Use a sandboxed app when you need freedom and can accept the isolation cost.

One protocol to rule them all sounds nice in a slide deck. In real systems though, clean boundaries beat these grand slogans anyday!

The Real Bet Is the Catalog

Your Component Catalog is not just User Interface plumbing; it is your product language.

Here is where A2UI gets interesting.

If Teams only use the basic catalog, this whole thing may become a slightly better form generator. Helpful; however, it is not exciting. We will get endless cards, lists, forms, and buttons that all taste like airport sandwiches.

Fine in a pinch. Nobody brags about it.

The better idea is custom catalogs.

A custom catalog lets a company expose its own trusted components to Agents. Not just generic building blocks like Card, Table, and TextField, but domain-specific concepts that carry product meaning.

For example:

• InvoiceSummary
• RiskBadge
• CustomerHealthScore
• PolicyExceptionPanel
• ClaimsTimeline
• DeploymentReadinessCard
• SubscriptionRenewalView

Now the Agent is not guessing how to assemble a screen from low-level parts. It can request a meaningful product component and provide the right data.

That changes the role of the Design System.

For years, many organizations treated Design Systems as internal User Interface kits. Useful for consistency. Good for velocity. Sometimes loved, often neglected, occasionally turned into a Governance swamp.

With A2UI, a Design System can become machine-addressable.

If your Agents can compose workflows using approved product components, then your Frontend Team keeps control over accessibility, interaction patterns, branding, validation, and visual quality. The Agent works at the level of intent; however, the host application handles rendering discipline.

This is the part leaders should pay attention to.

A weak catalog will produce weak Agent experiences. A rich, well-governed catalog could become a strategic interface layer between Artificial Intelligence systems and Users.

The Angular community has already started showing how this can work in practice. Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs - ANGULARarchitects and Demystifying A2UI: How to Make AI Agents "Speak UI" in Your App are both worth reading if you want a more concrete view.

The hard part will not be writing JSON schemas.

The hard part will be deciding which components deserve to become part of your Agent-facing product language. That requires product judgment, design maturity, Engineering discipline, and security review.

What I Would Watch Next

The winner will not be the Team with the most components; however, it will be the Team with the clearest boundaries.

I would watch A2UI through three lenses.

First, adoption.

Protocols need gravity. Google's support helps; however, it is not enough. Hosts, frameworks, tool vendors, and Design System Teams need to see enough value to implement and maintain renderers.

Second, catalog quality.

A giant catalog with vague components will confuse Agents and frustrate Users. A smaller catalog with clear semantics may perform much better. In my opinion, this is one of those places where restraint wins.

Third, Governance.

Who approves a component for Agent use? Who reviews the actions it can trigger? Who owns the schema? Who handles versioning? What happens when a component changes behavior?

These questions sound boring until they break production. Then they become very interesting.

A2UI will also need strong patterns around permissions, validation, observability, and audit logs. If an Agent composes an interface that leads a User to approve a financial transaction, someone will eventually ask: what did the Agent show, what did the User click, and why?

You want that answer before the incident review.

Closing Thought

Agents should not just talk better. They should help Users act better.

A2UI is one of the more credible attempts I have observed to make Agent-driven interfaces safer and more useful.

It is not a Frontend Engineer replacement. It is not a REST replacement. It is not a magic shield against bad product design. And it is definitely not a reason to let Agents generate whatever User Interface they feel like producing.

Its real value is narrower and stronger than that.

A2UI gives Agents a way to describe interfaces using trusted, brand-aligned components. If Teams invest in high-quality custom catalogs, the protocol becomes more than a rendering trick. It becomes a product-language layer for Agent-composed software.

That is the idea worth taking seriously.

For Engineering leaders, architects, and product Teams, I would start with one question:

Is your component library only built for developers, or is it ready to become an API for intelligent Agents?

The answer may shape the next generation of User Experience.

Citations and Further Reading

Good Architecture starts with reading the source material, not repeating the headline.

• Introducing A2UI: An open project for agent-driven interfaces
• A2UI Official Project Home Page
• A2UI on GitHub
• A2UI v0.9.1 Specification
• A2UI + MCP Apps: Combining the best of declarative and custom agentic UIs - Google Developers Blog
• MCP Apps in A2UI - A2UI
• Announcing the Agent2Agent Protocol (A2A)
• Demystifying A2UI: How to Make AI Agents "Speak UI" in Your App
• Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs - ANGULARarchitects