Agent-Era Frontend: AG-UI, A2UI & MCP Apps Integration Patterns

AG-UI × A2UI: Embedding UI Descriptions in Events

The article continues from Part 1, which introduced three standards for the Agent era: AG-UI handles runtime interaction, A2UI describes UI, and MCP Apps let tools carry interactive UI. In practice, they can coexist in one application — for example, a refund card widget (A2UI) streamed to the frontend via AG-UI events, with the card embedding a logistics tool panel (MCP Apps).

Division of Labor

AG-UI manages communication and state synchronization; A2UI describes which UI components and data to render. Both can be used simultaneously: keep AG-UI's event channel while wrapping A2UI descriptions inside AG-UI events. When the backend retrieves an order, it emits both task status and the refund card's component description with order data. The frontend receives the event stream via AG-UI, routes task status to progress updates, and passes A2UI messages to the renderer.

Implementation

The AG-UI project provides an A2UIMiddleware that detects A2UI content in tool outputs, wraps it into AG-UI events, and forwards them alongside text and status messages. The outer layer indicates message type; the inner payload retains the concrete UI description. The frontend extracts the payload by its identifier and hands it to the A2UI renderer.

{
  "type": "ACTIVITY_SNAPSHOT",
  "messageId": "a2ui-refund",
  "activityType": "a2ui-surface",
  "content": {
    "a2ui_operations": [
      {
        "version": "v0.9",
        "createSurface": {
          "surfaceId": "refund",
          "catalogId": "https://refund-demo.local/catalog/v1"
        }
      },
      {
        "version": "v0.9",
        "updateComponents": {
          "surfaceId": "refund",
          "components": [
            {
              "id": "root",
              "component": "Column",
              "children": ["product", "confirm"]
            },
            ...
          ]
        }
      }
    ]
  },
  "replace": true
}

Here the outer event is AG-UI's ACTIVITY_SNAPSHOT; activityType: "a2ui-surface" flags the payload as A2UI. This lets A2UI-described UI flow continuously to the frontend alongside other AG-UI events (status updates, tool calls).

A2UI × MCP: Three Combination Patterns

Both A2UI and MCP Apps deliver dynamic UI — A2UI by sending JSON descriptions for the host to render, MCP Apps by providing interactive HTML pages loaded in isolated iframes. Google outlines three ways to combine them, distinguished by where the A2UI renderer lives and where the MCP App runs.

1. A2UI over MCP: MCP Transports A2UI

Use case: Enterprise has a unified UI component system and renderer, and wants MCP tools (order, inventory, approval) to return consistent UI.

Mechanism: MCP Tools return A2UI JSON descriptions; the host (e.g., Agent app) receives the description and renders it with its own renderer. MCP does not return independent web pages; no iframe is needed. Only base MCP tool and resource capabilities are required — MCP Apps is not required . Prerequisite: host application supports A2UI (frontend can render UI components).

Server-side implementation:

Provide A2UI UI templates via MCP Resource.

Provide data and updates via MCP Tool.

The tool's metadata ( _meta.ui) must define an A2UI resource descriptor and type:

"_meta": {
  "ui": {
    "resourceUri": "a2ui://recipe-card",
    "mimeType": "application/a2ui+json"
  }
}

When the host calls the MCP Tool, it gets data plus _meta; it then calls resources/read to fetch the A2UI template, enabling final UI rendering and data display. In the demo, the order query tool embeds the full UI description in an application/a2ui+json resource; the frontend draws the refund card. After an action (e.g., clicking "Confirm Refund"), the host invokes the MCP Tool again, sends data to the MCP Server, and receives an updated A2UI result.

2. MCP Apps in A2UI: Embedding MCP App inside A2UI

Use case: Your Agent system uses A2UI for dynamic frontend UI, but you need to embed external MCP App interfaces (e.g., a logistics provider's time-slot picker, map, validation logic) without rewriting them.

Mechanism: The outer UI is still organized by A2UI, but the component catalog adds an "MCP App Container" component type. When the renderer encounters it, it loads the associated MCP Apps HTML resource and runs it in an iframe. The enterprise maintains the outer UI; the tool team maintains the inner interaction; both communicate via messaging.

In the refund demo, the outer order details and amount are rendered by A2UI, while the purple pickup panel is an independent MCP App (assumed provided by logistics). Conceptually, MCP Apps becomes a component type ( MCPApp) in the A2UI catalog, similar to a Form.

3. A2UI in MCP Apps: Packing A2UI Renderer into MCP App

Use case: You develop a tool for integration into someone else's platform; you cannot modify the host app. The host supports MCP Apps but lacks an A2UI renderer.

Mechanism: Bundle the renderer, component catalog, and business code into the MCP App. The host loads the MCP App; the App itself renders A2UI inside its isolated iframe. The host need not understand the A2UI description; UI component versions and visual effects are maintained by the MCP App.

Difference from Pattern 1: Here the MCP App renders the A2UI payload, not the host frontend — the renderer moves from the host into the isolated MCP App .

Protocol Selection Guide

The four collaboration scenarios can be chosen based on the problem; they need not all be adopted at once. For instance, if an existing frontend only lacks Agent progress and feedback, just add AG-UI; if MCP Tools need fixed pages, use MCP Apps without A2UI. All three protocols can even appear simultaneously. In the refund demo:

AG-UI continuously streams Agent replies and processing progress.

A2UI describes the outer order card, amount, and confirm button.

MCP Apps hosts the logistics pickup panel inside the card.

The user sees a single workspace, but the UI is composed from different parts. Multi-protocol fusion makes interaction more complex: e.g., when the pickup panel saves a new time, the outer order card and Agent must be notified — updates must be wired manually, not automatic.

Demo Interaction Flow

User selects pickup slot and clicks save; the App invokes MCP Tool via host.

MCP Server validates and persists arrangement; result returns via host; pickup panel updates.

Host confirms MCP panel save success, then sends new request to Agent.

Agent reads latest arrangement, returns reply, progress, and A2UI updates wrapped in AG-UI events; frontend refreshes outer A2UI card per new A2UI message.

User clicks "Confirm Refund"; another Agent request continues the task and updates UI.

Refer to A2UI official documentation for interaction details and SDKs.

Conclusion

Agent era does not eliminate frontend UI. Natural language suits task expression, but forms, cards, and buttons retain inherent interaction advantages — enabling users to view information, supply conditions, and confirm actions more conveniently. The difference is that UI appearance timing and content must now revolve around tasks. Understanding each protocol's motivation, scenarios, and principles helps make optimal architectural and design choices; concrete development can be delegated to AI coding.

Demo repository: https://github.com/pingcy/agent-ui-lab