Agent interfaces · A2UI · InteroperabilityOctober 31, 2026

Google A2UI and CopilotKit bring interactive UIs to AI agents

Google and CopilotKit show how agents can deliver forms, choices and actions inside applications rather than long chat replies. The approach separates declarative UI from the agent runtime—but trust boundaries and protocol maturity still matter.

KEY TAKEAWAY

A2UI expresses an interface as structured data, while CopilotKit connects agent frameworks, AG-UI events and renderers. Approved components constrain output but do not replace tool authorization, real-world testing or secure backend logic.

Sources and evidentiary limits

Primary source
Official Google, CopilotKit and A2UI project documentation are linked. Original post
Not independently tested
No independent implementation or security test; protocol maturity and vendor product claims are distinguished.

What Google announced on October 29

In its October 29, 2026 developer post, Google's A2UI team and CopilotKit demonstrate a new way to present agent results. Instead of six travel offers in plain paragraphs, an agent can render selectable result cards and follow-up date or preference inputs. The user acts on the interface and the agent responds to those choices.

This is a change in the agent-user interface, not a new foundation model. It could make agents more useful for multi-step tasks, but the example does not establish reliable real-world bookings, payments or permissions.

A2UI, AG-UI and CopilotKit do different jobs

A2UI specifies declarative UI content: components and data an agent wants the app to render. AG-UI carries events between the agent and its client. CopilotKit offers application integration, a runtime and UI renderers. These are distinct layers, and none of them independently decides whether a user is authorized to perform a business operation.

Google describes adapters for Google ADK, LangChain, Mastra and AWS Strands. A2UI is framework-agnostic by design, but teams still need compatible versions, approved component catalogs and tested backend integrations.

Why a trusted component catalog matters

Instead of executing arbitrary HTML or JavaScript generated by a model, the client presents the agent with a catalog of trusted components. The agent can select permitted cards, controls or inputs; the app can reject unknown components and invalid properties.

This constrains the rendering boundary, not the entire system. A perfectly valid button can still call a privileged API. Tool permissions, user authorization, prompt-injection defenses and sensitive-data checks remain separate responsibilities. A safe renderer is not equivalent to a safe autonomous agent.

How a reactive agent interface works

A2UI messages can be streamed in small parts. Inputs bind to data paths and user actions return selected values; the agent can then update the same surface. The walkthrough uses schema validation for custom components before rendering them.

That supports multi-step search, filtering and confirmation on one surface. But client-side valid input is not proof that a transaction is permitted. High-impact operations still need independent checks at the server boundary and, where appropriate, explicit user approval.

CopilotKit announces a larger catalog

In a separate announcement on the same day, CopilotKit introduced a catalog of 70 ready-made components, surfaces outside the chat interface and a Markdown mode that combines text and UI. This is a CopilotKit product capability, not a statement that the base A2UI protocol itself contains 70 required primitives.

Renderer capabilities, package versions and custom components remain relevant. Teams should test their actual supported stack rather than assume every listed widget works identically across all clients.

Protocol maturity remains a limitation

The A2UI project documentation lists v0.9.1 as the current production release and v1.0 as a candidate. The repository describes the project as early public preview. A working demonstration is therefore not the same as a permanent compatibility guarantee.

Production pilots should pin versions, record expected message schemas, reject unsupported components and include fallbacks when rendering fails. Regression tests are particularly important for action bindings and user inputs when the agent backend or renderer changes.

A measured pilot and the bigger implication

Start with a read-only research or support agent that displays results as cards and filters. Only then add a draft-creation action behind explicit approval. Track completed tasks, invalid payloads, unintended tool calls and resistance to malicious instructions in retrieved content.

The larger change is architectural: agents can suggest interactions, not just text. The app must still enforce what can happen. See AgentenCode's agent evaluation guide for test design. Editorial cutoff: October 31, 2026. No independent product benchmark was conducted.

Primary sources

Cutoff 31 October 2026. No independent product security test.

Frequently asked questions

Can A2UI run arbitrary model-generated JavaScript?

In its declarative mode, the app renders only approved components. Other integration patterns and privileged server tools require separate controls.

Are all 70 CopilotKit components part of the base A2UI specification?

No. The 70-component offering is a CopilotKit product catalog, distinct from A2UI's basic primitives.

Is A2UI fully standardized?

No. Its project documentation calls v0.9.1 the current production release and v1.0 a candidate.

← All news