A2UI and Google ADK: When Agents Build Their Own Interfaces

A2UI lets AI agents generate interactive UI components instead of plain text responses. Paired with Google’s Agent Development Kit (ADK), your agent can return a flight comparison card, a booking form, or a data dashboard rather than chatting back and forth to collect the same information. The protocol is declarative, secure by design, and already integrated into ADK’s built-in web interface.

This matters because text-based agent interactions hit a ceiling fast. When your travel agent needs a departure date, a destination, a budget range, and a seat preference, asking for each one sequentially through chat takes eight messages. With A2UI, the agent sends a single form component with all four fields, the user fills it out, and the agent has everything it needs in one interaction. Google introduced A2UI as an open-source project in December 2025, and ADK was the first major framework to ship native support.

How A2UI Works: Declarative UI, Not Executable Code

The core design principle behind A2UI is security through declarativeness. Agents do not send HTML, JavaScript, or executable code to the client. They send structured JSON that describes which UI components to render from a pre-approved catalog.

Here is a simplified A2UI message that renders a date picker and a submit button:

{
  "surfaceUpdate": {
    "components": [
      {
        "id": "departure-date",
        "component": {
          "DateTimeInput": {
            "label": { "literalString": "Departure Date" },
            "value": { "path": "/booking/date" }
          }
        }
      },
      {
        "id": "submit-btn",
        "component": {
          "Button": {
            "label": { "literalString": "Search Flights" },
            "action": "submit"
          }
        }
      }
    ]
  }
}

The client application maintains a component catalog: a set of trusted, pre-approved UI widgets like Card, Button, TextField, DateTimeInput, and Table. The agent can only request components that exist in the catalog. If an agent tries to render something not in the catalog, the client ignores it. No arbitrary code execution, no UI injection vulnerabilities.

This is the key difference between A2UI and having an LLM generate React or HTML directly. With A2UI, the agent is constrained to safe, declarative specifications. With raw code generation, you are trusting an LLM not to produce malicious output, which is a bet no security team should take in production.

Data Binding and Streaming

A2UI components bind to a shared data model using path references. When a user fills in the departure date above, the value updates at /booking/date in the data model, and any other component referencing that path updates automatically. This reactive binding means agents can build multi-step forms where later fields depend on earlier choices.

The protocol uses JSON Lines (JSONL) streaming, so clients render components incrementally as the agent generates them. Users see the interface building in real time rather than waiting for the entire response to complete. For complex dashboards or multi-section forms, this eliminates the blank-screen wait.

Cross-Platform by Design

Because A2UI is a declarative format, the same agent response renders on any platform. Google already ships renderer implementations for Flutter, Lit (web components), and Angular. CopilotKit has built React compatibility through its AG-UI integration. One agent, multiple frontends, zero code changes.

ADK’s A2UI Integration: Native Rendering Out of the Box

Google ADK was the first major agent framework to integrate A2UI as a first-class feature. The built-in developer UI (adk web) renders A2UI components natively, which means you can test interactive agent UIs without building a custom frontend.

Here is how it works in practice. An ADK agent returns A2UI parts alongside its text response:

from google.adk.agents import LlmAgent

restaurant_agent = LlmAgent(
    model="gemini-2.0-flash",
    name="restaurant_finder",
    description="Finds restaurants and shows results as interactive cards",
    instruction="""
    When the user asks for restaurant recommendations,
    return results as A2UI Card components with name,
    rating, cuisine type, and a booking button.
    """,
    tools=[search_restaurants, get_reviews]
)

The agent’s response includes A2UI-formatted parts, and ADK Web automatically detects and renders them as native UI components. No additional configuration required. The agent can return charts instead of describing data, forms instead of asking sequential questions, and comparison tables instead of listing options in bullet points.

ADK ships with the standard A2UI v0.8 component catalog pre-loaded, which includes components for text display, user input, navigation, data visualization, and layout. You can extend this catalog with custom components specific to your application.

With ADK’s recent v2.0 alpha introducing graph-based workflows and the Task API, A2UI becomes even more powerful. A workflow can collect user input via A2UI forms, route that input through conditional logic, fan out to multiple agents, and present aggregated results as A2UI cards. The combination of structured workflows and structured UIs is where ADK’s protocol-native approach pays off.

Toolset Authentication: When Agents Need Credentials

Agents that access real-world APIs need credentials. Your calendar agent needs OAuth tokens. Your CRM agent needs API keys. Your payment agent needs service account credentials. ADK’s toolset authentication system handles this without hardcoding secrets in agent code.

The AuthCredential System

ADK supports five credential types that cover the most common API authentication patterns:

• API_KEY: Simple key-value authentication for APIs like weather services, search APIs, or webhook endpoints
• HTTP: Basic Auth or Bearer token schemes for REST APIs
• OAUTH2: Full OAuth 2.0 flows with client ID/secret and user consent, supporting identity providers like Google, Okta, and Auth0
• OPEN_ID_CONNECT: OIDC authentication layered on top of OAuth 2.0 for identity verification
• SERVICE_ACCOUNT: Google Cloud service account credentials that auto-exchange for Bearer tokens

Here is how you configure OAuth2 authentication for an OpenAPI toolset:

from google.adk.tools.openapi_tool import OpenAPIToolset
from google.adk.auth import AuthScheme, AuthCredential

auth_scheme = AuthScheme(
    auth_type="OAUTH2",
    oauth2={
        "authorization_url": "https://accounts.google.com/o/oauth2/v2/auth",
        "token_url": "https://oauth2.googleapis.com/token",
        "scopes": ["https://www.googleapis.com/auth/calendar"]
    }
)

auth_credential = AuthCredential(
    auth_type="OAUTH2",
    oauth2={"client_id": "YOUR_CLIENT_ID", "client_secret": "YOUR_CLIENT_SECRET"}
)

calendar_tools = OpenAPIToolset(
    spec_url="https://www.googleapis.com/discovery/v1/apis/calendar/v3/rest",
    auth_scheme=auth_scheme,
    auth_credential=auth_credential
)

The framework handles the token exchange flow automatically. When the agent makes an API call that requires authentication, ADK detects the need, initiates the OAuth flow, handles the redirect, stores the token, and retries the original call with a valid credential.

MCP Authentication

The same authentication system extends to MCP toolsets. When connecting to an MCP server that requires authentication, you pass the same auth_scheme and auth_credential to the MCPToolset:

from google.adk.tools.mcp import MCPToolset

github_tools = MCPToolset.from_server(
    connection_params=StdioServerParameters(
        command="npx",
        args=["-y", "@modelcontextprotocol/server-github"]
    ),
    auth_scheme=github_auth_scheme,
    auth_credential=github_auth_credential
)

This unifies authentication across built-in tools, OpenAPI tools, and MCP tools. One credential system, three tool types. For multi-agent architectures where parent agents delegate to sub-agents with different tool requirements, authentication tokens can be passed through the agent hierarchy.

Production Credential Security

ADK’s documentation is explicit about what not to do: never store raw access tokens in InMemorySessionService in production. The recommended approach is encrypting tokens before database storage or using a dedicated secret manager like Google Cloud Secret Manager or HashiCorp Vault.

For teams building agents that handle payment processing or access financial data, this is not optional. The framework provides the authentication plumbing, but production-grade secret management is your responsibility.

A2UI in the Wild: Where It Actually Matters

A2UI is most valuable in scenarios where text-based interaction creates friction.

Enterprise dashboards. An analytics agent that queries your data warehouse and returns an A2UI chart beats one that describes the chart in words. Gemini Enterprise already uses A2UI for custom agent UIs that render KPI cards, comparison tables, and trend visualizations inside Google Workspace.

Multi-step workflows. Booking a restaurant through a chat agent takes 6-8 messages (cuisine? location? party size? date? time? budget?). With A2UI, the agent sends a single form with all fields, the user submits once, done. Google’s own restaurant finder sample demonstrates this pattern with ADK.

Agent marketplaces. When agents from different vendors need to present UIs to users, A2UI provides a common format. Agent A returns a flight card, Agent B returns a hotel card, Agent C returns a car rental card. The client renders all three consistently because they share the same component catalog.

The protocol is at v0.8 and heading toward a stable v1.0. OpenClaw has integrated A2UI, CopilotKit supports it through AG-UI, and Flutter’s GenUI SDK uses it for multi-platform generative interfaces. The ecosystem is still early, but the adoption pattern mirrors where MCP was 12 months ago: a few key integrations building momentum before the wave.

Getting Started: From Text Agent to A2UI Agent

If you are building with ADK and want to try A2UI, here is the fastest path:

# Clone the A2UI repo with sample agents
git clone https://github.com/google/A2UI.git
export GEMINI_API_KEY="your_key_here"

# Start the ADK restaurant finder agent
cd A2UI/samples/agent/adk/restaurant_finder && uv run .

# In a separate terminal, start the Lit web client
cd A2UI/samples/client/lit/shell && npm install && npm run dev

This gives you a working A2UI agent with card-based restaurant results in under five minutes. From there, you can modify the agent’s instructions to generate different component types, extend the component catalog, or swap in your own ADK agent.

For teams already running ADK agents, adding A2UI support is additive. Existing text responses still work. A2UI components are an optional enhancement, and you can introduce them gradually, one agent at a time, without rewriting your entire application.

Frequently Asked Questions

What is A2UI and how does it work?

A2UI (Agent-to-User Interface) is a declarative protocol that lets AI agents generate interactive UI components like buttons, cards, forms, and charts instead of plain text. The agent sends structured JSON describing which components to render from a pre-approved component catalog, and the client application renders them natively. It is secure by design because agents cannot send executable code.

How does Google ADK integrate with A2UI?

Google ADK integrates the A2UI v0.8 standard component library and renders A2UI components natively in its built-in web UI (adk web). ADK agents can return A2UI-formatted parts alongside text responses, and the framework automatically detects and renders them as interactive components without additional configuration.

What authentication methods does Google ADK support for agent tools?

ADK supports five credential types: API keys, HTTP Basic/Bearer tokens, OAuth 2.0, OpenID Connect, and Google Cloud service accounts. These work across built-in tools, OpenAPI toolsets, and MCP toolsets. The framework handles token exchange flows automatically and supports credential passthrough in multi-agent hierarchies.

What is the difference between A2UI and AG-UI?

A2UI is Google’s declarative protocol for agent-generated UIs, focused on a component catalog model where agents request pre-approved components. AG-UI is CopilotKit’s protocol for agent-UI communication. The two are compatible: CopilotKit supports A2UI rendering through its AG-UI integration, allowing agents to use either or both protocols.

Is A2UI ready for production use?

A2UI is at v0.8 (pre-1.0) and actively moving toward a stable release. Google, CopilotKit, OpenClaw, and Gemini Enterprise already use it. For production systems, evaluate whether the available component catalog covers your use case and ensure you have a renderer for your target platform. Renderers exist for Flutter, Lit, and Angular, with React support via CopilotKit’s AG-UI bridge.