A2UI es uno de los proyectos de protocolos más interesantes del stack actual de agentes porque aborda un problema con el que la mayoría de los equipos se encuentra casi de inmediato: el chat por sí solo es una pésima interfaz para formularios, aprobaciones, flujos de revisión, artefactos editables y procesos paso a paso.
Ya hablé brevemente de A2UI en “Del chat a la interfaz de agente”. Este artículo profundiza en el tema y se centra en la implementación: qué es realmente A2UI, dónde se utiliza ya y cómo construir con él, desde un prototipo mínimo en React hasta la integración a nivel de transporte.
En resumen
- A2UI es un protocolo declarativo de interfaces, no un framework frontend. Tu agente envía JSON que describe la interfaz. Tu cliente renderiza ese JSON usando componentes nativos de confianza.
- Su valor principal es simple: seguro como los datos, expresivo como el código. El agente no envía HTML ni JavaScript a tu aplicación.
- Al April 6, 2026, la documentación de A2UI indica que React es estable para v0.8, mientras que Lit, Angular y Flutter tienen cobertura para más versiones. Si buscas un punto de partida práctico con React hoy, usa la estructura del renderer estable de v0.8.
- A2UI ya aparece en productos oficiales de Google y sus socios: Opal, Gemini Enterprise, Flutter GenUI SDK, Google ADK y ejemplos oficiales de código abierto como Restaurant Finder, Contact Lookup y la demo Personalized Learning.
- La ruta de aprendizaje adecuada es:
- renderizar una superficie estática de forma local
- agregar vinculación de datos y acciones del usuario
- trasladar la generación de mensajes a un backend
- conectar A2UI a un transporte real como A2A, AG-UI o MCP
- Elige A2UI cuando el agente y la interfaz estén separados por un límite de confianza, cuando necesites renderizar la misma respuesta del agente en varias plataformas o cuando tu flujo dependa de formularios, tarjetas, listas, selectores y superficies de aprobación en lugar de interminables intercambios de texto.
Qué aprenderás aquí
- Qué es A2UI y qué no es
- Cómo se relaciona A2UI con A2A, AG-UI y MCP
- Dónde se utiliza ya A2UI en sistemas reales
- Cómo renderizar tu primera superficie A2UI en React
- Cómo funcionan la vinculación de datos y las acciones del usuario
- Cómo pasar de una demo local a una aplicación controlada por el servidor
- Cómo abordar patrones avanzados como la integración con MCP, la negociación de catálogos y el versionado
Qué es realmente A2UI
La definición actual más clara viene de la documentación oficial: A2UI es un protocolo declarativo de interfaces para aplicaciones impulsadas por agentes. En lugar de enviar código ejecutable para la interfaz, el agente envía mensajes JSON que describen superficies, componentes, vinculaciones de datos y acciones.
Esto importa porque muchos sistemas de agentes usados en entornos reales no son aplicaciones locales de un solo proceso. El agente puede:
- ejecutarse de forma remota
- pertenecer a otro servicio o equipo
- actualizar la interfaz de forma asíncrona
- atender a varios clientes en web, dispositivos móviles y escritorio
Si ese agente envía HTML o JavaScript sin procesar, heredas de inmediato problemas de seguridad, portabilidad y estilo.
A2UI toma otro camino:
- el agente elige la estructura de la interfaz
- el cliente controla la renderización
- el catálogo define qué componentes están permitidos
- el transporte está separado del protocolo de interfaz
Esto te da un modelo más seguro y portable.
Por qué existe este problema
La documentación oficial de A2UI usa un flujo de reserva para ilustrar el problema, y es un buen ejemplo.
Esta es la mala versión:
User: Book a table for 2 tomorrow at 7pm.
Agent: Sure. Which day?
User: Tomorrow.
Agent: What time?
User: 7pm.
Agent: Indoor or outdoor?
User: Outdoor.Esta es la versión mejorada:
User: Book a table for 2 tomorrow at 7pm.
Agent:
-> renders a date/time picker
-> pre-fills party size
-> shows an outdoor seating checkbox
-> attaches a confirm buttonEse es el cambio que A2UI busca estandarizar.
Ejemplos reales de A2UI
Algo que me gusta de A2UI en este momento es que el proyecto no es solo un repositorio de especificaciones. La documentación oficial ya muestra dónde se está utilizando.
1. Google Opal
La página oficial «A2UI en el mundo» dice que Opal usa A2UI para impulsar el sistema de interfaz dinámica y generativa de sus miniaplicaciones de IA. Lo interesante no es solo que «la IA crea widgets». Es que A2UI le permite a Opal dejar que la IA defina la estructura de la interfaz sin tratar al frontend como un sandbox para ejecutar código arbitrario.
2. Gemini Enterprise
La misma página oficial dice que Gemini Enterprise está integrando A2UI para:
- formularios de captura de datos
- paneles de aprobación
- automatización de flujos de trabajo
- interfaces empresariales para tareas específicas
Ese es precisamente el tipo de flujo en el que usar solo el chat se vuelve incómodo.
3. Flutter GenUI SDK
Según la documentación oficial, Flutter GenUI SDK usa A2UI internamente. Es una señal clara de que A2UI no es solo una curiosidad limitada a la web. Ya se utiliza como una capa multiplataforma de interfaces controladas por el servidor.
4. Google ADK
La documentación también dice que la interfaz para desarrolladores de Google ADK renderiza A2UI de forma nativa y gestiona la conversión de A2UI a A2A. Esto es importante porque muestra que A2UI no es un experimento aislado. Se está convirtiendo en parte de un conjunto más amplio de herramientas para desarrollar agentes.
5. Ejemplos oficiales de código abierto
La documentación y el repositorio de A2UI señalan varios ejemplos concretos:
- Restaurant Finder para formularios dinámicos de reservas
- Contact Lookup para búsquedas con resultados estructurados
- Personalized Learning para tarjetas de estudio, cuestionarios y contenido educativo fundamentado en fuentes
El ejemplo Personalized Learning es especialmente útil porque es un ejemplo full-stack, no solo una galería de componentes. Combina:
- un renderer frontend
- un agente remoto
- contexto personalizado del estudiante
- recuperación de contenido de libros de texto
- tarjetas de estudio y cuestionarios generados con A2UI
Es una referencia sólida del mundo real porque muestra cómo se usa A2UI para crear artefactos de aprendizaje estructurados, no solo tarjetas genéricas.
Un mejor modelo mental
La forma más sencilla de pensar en A2UI es esta:
Agent decides WHAT surface should exist
Client decides HOW that surface is rendered
Transport decides HOW messages move between themEn la práctica, el stack suele verse así:
User
-> frontend app
-> transport layer (A2A / AG-UI / MCP / SSE / WebSocket)
-> agent backend
-> A2UI messages
-> renderer
-> native UI components
-> user action
-> backend againEsto también ayuda a distinguir A2UI de protocolos relacionados:
- A2UI: payloads declarativos de interfaz
- A2A: transporte y coordinación entre agentes
- AG-UI: protocolo de interacción de alto ancho de banda entre agentes y frontends
- MCP: conectividad de herramientas, recursos y datos para modelos y agentes
La documentación de AG-UI lo resume bien: A2UI es una especificación de interfaces generativas, mientras que AG-UI es el protocolo de interacción entre el agente y el usuario. Son capas complementarias, no competidoras.
Las versiones importan más de lo que crees
Este es el primer detalle práctico que me habría gustado conocer antes de empezar.
Al April 6, 2026:
- v0.8 es la versión estable del protocolo A2UI
- v0.9 es un borrador
- v0.10 existe en el repositorio, pero sigue en desarrollo
- el renderer de React oficial es estable para v0.8
Esto significa que la forma más inteligente de aprender A2UI hoy es:
- usar mensajes con la estructura de v0.8 para ejemplos de React ejecutables
- entender que las especificaciones más recientes están aplanando y simplificando el modelo de mensajes
- evitar mezclar estructuras de distintas versiones en la misma aplicación
Eso es exactamente lo que haré a continuación: los ejemplos ejecutables de React usan v0.8, y la sección de transporte avanzado señalará las diferencias con las especificaciones más recientes.
Paso 1: Construye la aplicación A2UI más pequeña posible
Si solo quieres entender la estructura del protocolo, el camino más rápido es una aplicación sencilla de React con el renderer oficial.
Instalación
npm create vite@latest a2ui-hello -- --template react-ts
cd a2ui-hello
npm install
npm install @a2ui/reactsrc/App.tsx
Este es el ejemplo útil más pequeño que conozco que aun así muestra la idea completa.
import { A2UIViewer, injectStyles } from "@a2ui/react";
import type { Types } from "@a2ui/react";
injectStyles();
const messages: Types.ServerToClientMessage[] = [
{
surfaceUpdate: {
surfaceId: "main",
components: [
{
id: "title",
component: {
Text: {
text: { literalString: "Book Your Table" },
usageHint: "h1",
},
},
},
{
id: "body",
component: {
Text: {
text: {
literalString:
"The agent did not send HTML. It sent structured UI data.",
},
usageHint: "body",
},
},
},
{
id: "cta-label",
component: {
Text: {
text: { literalString: "Start booking" },
usageHint: "body",
},
},
},
{
id: "cta-button",
component: {
Button: {
child: "cta-label",
action: {
name: "start_booking",
context: [
{
key: "flow",
value: { literalString: "restaurant" },
},
],
},
},
},
},
{
id: "root",
component: {
Column: {
children: {
explicitList: ["title", "body", "cta-button"],
},
distribution: "start",
alignment: "stretch",
},
},
},
],
},
},
{
beginRendering: {
surfaceId: "main",
root: "root",
},
},
];
export default function App() {
return (
<main style={{ maxWidth: 720, margin: "48px auto", padding: 24 }}>
<A2UIViewer
messages={messages}
onAction={(event) => {
console.log("A2UI action:", event.userAction);
}}
/>
</main>
);
}Ese único archivo enseña las ideas más importantes de A2UI:
- una superficie es el destino de renderización
- la interfaz es una lista plana de componentes
- las relaciones se expresan mediante IDs
- la renderización comienza cuando el cliente recibe
beginRendering - un
Buttonemite una acción del usuario
No has construido un «widget de chatbot». Has construido una pequeña superficie de interfaz impulsada por un agente.
Paso 2: Agrega estado real de formulario y acciones del usuario
Lo siguiente que necesitas es la vinculación de datos. Aquí es donde A2UI empieza a sentirse diferente de un renderer estático de JSON.
En A2UI, los campos de entrada pueden vincularse a un modelo de datos. Cuando el usuario cambia un campo, el cliente actualiza el estado local. Cuando hace clic en un botón, la acción puede incluir valores obtenidos de ese modelo de datos.
Esto significa que el agente puede renderizar un formulario sin programar cada interacción de forma explícita en el frontend.
src/reservationMessages.ts
import type { Types } from "@a2ui/react";
export const reservationMessages: Types.ServerToClientMessage[] = [
{
dataModelUpdate: {
surfaceId: "booking",
path: "/",
contents: [
{
key: "booking",
valueMap: [
{ key: "name", valueString: "" },
{ key: "partySize", valueString: "2" },
{ key: "when", valueString: "2026-04-12T19:00:00Z" },
{ key: "outdoor", valueBoolean: false },
],
},
],
},
},
{
surfaceUpdate: {
surfaceId: "booking",
components: [
{
id: "title",
component: {
Text: {
text: { literalString: "Restaurant Reservation" },
usageHint: "h2",
},
},
},
{
id: "nameField",
component: {
TextField: {
label: { literalString: "Name" },
text: { path: "booking.name" },
},
},
},
{
id: "partyField",
component: {
TextField: {
label: { literalString: "Party size" },
text: { path: "booking.partySize" },
},
},
},
{
id: "whenField",
component: {
DateTimeInput: {
value: { path: "booking.when" },
enableDate: true,
enableTime: true,
},
},
},
{
id: "outdoorField",
component: {
CheckBox: {
label: { literalString: "Outdoor seating" },
value: { path: "booking.outdoor" },
},
},
},
{
id: "submitLabel",
component: {
Text: {
text: { literalString: "Confirm reservation" },
usageHint: "body",
},
},
},
{
id: "submitButton",
component: {
Button: {
child: "submitLabel",
action: {
name: "confirm_reservation",
context: [
{ key: "name", value: { path: "booking.name" } },
{ key: "partySize", value: { path: "booking.partySize" } },
{ key: "when", value: { path: "booking.when" } },
{ key: "outdoor", value: { path: "booking.outdoor" } },
],
},
},
},
},
{
id: "root",
component: {
Column: {
children: {
explicitList: [
"title",
"nameField",
"partyField",
"whenField",
"outdoorField",
"submitButton",
],
},
distribution: "start",
alignment: "stretch",
},
},
},
],
},
},
{
beginRendering: {
surfaceId: "booking",
root: "root",
},
},
];src/App.tsx
import { useEffect } from "react";
import {
A2UIProvider,
A2UIRenderer,
injectStyles,
useA2UIActions,
} from "@a2ui/react";
import type { Types } from "@a2ui/react";
import { reservationMessages } from "./reservationMessages";
injectStyles();
function BookingSurface() {
const { processMessages, clearSurfaces } = useA2UIActions();
useEffect(() => {
clearSurfaces();
processMessages(reservationMessages);
}, [clearSurfaces, processMessages]);
return <A2UIRenderer surfaceId="booking" />;
}
export default function App() {
return (
<A2UIProvider
onAction={(event: Types.A2UIClientEventMessage) => {
console.log("Send this to your backend:", event.userAction);
alert(JSON.stringify(event.userAction, null, 2));
}}
>
<main style={{ maxWidth: 720, margin: "48px auto", padding: 24 }}>
<BookingSurface />
</main>
</A2UIProvider>
);
}Este es el primer punto en el que A2UI se vuelve realmente útil.
Observa lo que el frontend no está haciendo:
- no conecta manualmente cada campo de entrada al estado local de React
- no construye manualmente un payload
confirm_reservation - no define de forma rígida qué superficie mostrar a continuación
El frontend actúa principalmente como:
- renderer
- entorno de ejecución local para la vinculación de datos
- despachador de acciones
Es una distribución de responsabilidades muy distinta a la de una aplicación de formularios convencional.
Paso 3: Haz que el servidor controle la interfaz
Una vez que entiendes el flujo local, el siguiente paso es trasladar la generación de mensajes al backend.
Ahí es donde A2UI se vuelve interesante para sistemas reales, porque ahora el agente puede decidir:
- si el siguiente paso debe ser texto plano o una interfaz estructurada
- qué superficie mostrar
- qué campos rellenar previamente
- qué acciones deben regresar al servidor
Aquí tienes un ejemplo de Node deliberadamente pequeño.
server.ts
import express from "express";
import { reservationMessages } from "./src/reservationMessages";
const app = express();
app.use(express.json());
app.post("/api/agent", (req, res) => {
const input = req.body.message;
// Initial prompt from the user.
if (typeof input === "string") {
return res.json(reservationMessages);
}
// Action emitted by A2UI after the user clicks Confirm reservation.
if (input?.userAction?.name === "confirm_reservation") {
const context = input.userAction.context ?? {};
const outdoorText = context.outdoor ? "outdoor" : "indoor";
return res.json([
{
surfaceUpdate: {
surfaceId: "booking",
components: [
{
id: "doneTitle",
component: {
Text: {
text: {
literalString: `Reservation created for ${context.name || "guest"}`,
},
usageHint: "h2",
},
},
},
{
id: "doneBody",
component: {
Text: {
text: {
literalString: `${context.partySize || "2"} guests on ${context.when}. Seating: ${outdoorText}.`,
},
usageHint: "body",
},
},
},
{
id: "root",
component: {
Column: {
children: {
explicitList: ["doneTitle", "doneBody"],
},
distribution: "start",
alignment: "stretch",
},
},
},
],
},
},
{
beginRendering: {
surfaceId: "booking",
root: "root",
},
},
]);
}
return res.status(400).json({ error: "Unknown message type" });
});
app.listen(3001, () => {
console.log("Agent server listening on http://localhost:3001");
});src/App.tsx
import { useEffect, useState } from "react";
import { A2UIViewer, injectStyles } from "@a2ui/react";
import type { Types } from "@a2ui/react";
injectStyles();
export default function App() {
const [messages, setMessages] = useState<Types.ServerToClientMessage[]>([]);
async function roundTrip(message: string | Types.A2UIClientEventMessage) {
const response = await fetch("/api/agent", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ message }),
});
const nextMessages: Types.ServerToClientMessage[] = await response.json();
setMessages(nextMessages);
}
useEffect(() => {
void roundTrip("Book a table for two tomorrow at 7pm");
}, []);
return (
<main style={{ maxWidth: 720, margin: "48px auto", padding: 24 }}>
<A2UIViewer messages={messages} onAction={roundTrip} />
</main>
);
}Esta es la primera arquitectura que ya se asemeja a una de producción:
user prompt
-> backend decides UI
-> backend sends A2UI messages
-> client renders them
-> user acts on native UI
-> client sends action back
-> backend returns the next surfaceEs una base clara para:
- aprobaciones
- configuración guiada
- resultados de búsqueda y filtrado
- flujos de reserva
- resolución estructurada de problemas
- revisión de artefactos
Patrón de ejemplo real: Personalized Learning
Vale la pena estudiar la demo oficial de A2UI Personalized Learning porque muestra dónde este enfoque ofrece mucho más que una «interfaz a partir de JSON».
El ejemplo combina:
- un contenedor de chat
- un agente remoto
- recuperación de contenido de OpenStax
- contexto específico del estudiante
- componentes A2UI personalizados como Flashcard y QuizCard
El flujo general se ve así:
Student prompt
-> API server
-> remote agent
-> content retrieval + learner profile
-> A2UI flashcards / quiz cards
-> frontend rendererEse patrón es más importante que el ámbito educativo en sí.
Puedes reutilizar la misma arquitectura para:
- listas de verificación de incorporación
- tarjetas de revisión de contratos
- paneles de aprobación de compras
- runbooks de respuesta a incidentes
- flujos de capacitación interna
Esta es una inferencia mía a partir de los ejemplos oficiales y las notas de implementación, pero es bastante razonable: A2UI destaca cuando la «respuesta» debería ser en realidad una superficie de trabajo funcional.
Patrón avanzado 1: Múltiples superficies y renderización progresiva
Una de las ideas más sólidas del protocolo A2UI es que la estructura y los datos están separados. Esto significa que puedes:
- crear una superficie desde el inicio
- renderizar un esqueleto de inmediato
- actualizar los datos más tarde
- intercambiar o eliminar superficies cuando cambie el flujo de trabajo
Esto es ideal para flujos de agentes que toman tiempo.
Por ejemplo:
1. Agent creates a "review" surface with heading + loading state
2. Agent streams tool work in the background
3. Agent updates the data model with fetched results
4. Agent swaps the CTA from "Loading..." to "Approve deployment"Esto es mucho mejor que obligar al usuario a esperar una única respuesta final enorme.
Patrón avanzado 2: A2UI sobre MCP
La documentación oficial de A2UI ahora incluye una guía para A2UI sobre MCP, y es uno de los ejemplos más claros de por qué el protocolo es útil más allá de una sola aplicación.
La idea es:
- una herramienta MCP devuelve texto normal junto con un recurso incrustado
- el recurso incrustado usa
application/json+a2ui - el cliente dirige ese recurso a su renderer de A2UI
Esto permite que la respuesta de una herramienta se convierta en una interfaz real en lugar de un bloque de JSON.
Ejemplo mínimo de MCP en Python
import json
import mcp.types as types
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("a2ui-demo")
@mcp.tool()
def get_training_plan_ui():
a2ui_payload = [
{
"version": "v0.10",
"createSurface": {
"surfaceId": "default",
"catalogId": "https://a2ui.org/specification/v0_10/basic_catalog.json",
},
},
{
"version": "v0.10",
"updateComponents": {
"surfaceId": "default",
"components": [
{
"id": "root",
"component": "Text",
"text": "Hello from A2UI over MCP!",
}
],
},
},
]
a2ui_resource = types.EmbeddedResource(
type="resource",
resource=types.TextResourceContents(
uri="a2ui://training-plan",
mimeType="application/json+a2ui",
text=json.dumps(a2ui_payload),
),
)
return types.CallToolResult(
content=[
types.TextContent(
type="text",
text="Here is your generated training plan summary.",
),
a2ui_resource,
]
)Es un patrón muy potente porque ahora la herramienta puede devolver:
- texto narrativo normal del asistente
- un artefacto estructurado de interfaz
- una vía para devolver acciones del usuario al servidor
La guía de A2UI sobre MCP también destaca la negociación de catálogos, que es fácil pasar por alto, pero extremadamente importante. Antes de que un servidor envíe A2UI, el cliente y el servidor deben ponerse de acuerdo sobre:
- la versión del protocolo compatible
- los IDs de catálogo compatibles
- si se permiten catálogos personalizados o en línea
Ese acuerdo es lo que mantiene la interfaz segura y predecible.
Patrón avanzado 3: Entiende el cambio de versión
Si lees las especificaciones más recientes, notarás que las versiones nuevas aplanan el modelo de mensajes.
En la versión estable v0.8, verás con frecuencia:
surfaceUpdatedataModelUpdatebeginRendering
En las versiones más recientes, eso evoluciona hacia:
createSurfaceupdateComponentsupdateDataModeldeleteSurfaceactionResponse
Esto no es solo un cambio superficial. Hace que el ciclo de vida sea más explícito y que las integraciones de transporte sean más claras.
Mi consejo práctico es:
- construye hoy sobre la versión estable del renderer que realmente puedas ejecutar
- mantén la generación de mensajes del servidor aislada detrás de un pequeño adaptador
- no disperses la estructura del protocolo sin procesar por toda tu aplicación
Así, pasar de una versión de A2UI a otra se convierte en un asunto del backend en lugar de exigir una reescritura del producto.
Cuándo es A2UI la elección correcta
Elige A2UI cuando:
- el agente sea remoto o no sea de confianza
- la misma interfaz deba renderizarse en web, dispositivos móviles y escritorio
- quieras que el agente genere formularios, tarjetas, listas, listas de verificación, pestañas, selectores o superficies de revisión
- te importe la renderización nativa más que el aislamiento al estilo de un iframe
- tu equipo quiera que el cliente conserve el control sobre estilos, accesibilidad y seguridad
No elijas A2UI cuando:
- la interfaz sea principalmente una interfaz de producto estática que ya controlas
- no haya una necesidad real de superficies de interacción controladas por el servidor o generadas por un agente
- solo necesites una burbuja de chat con markdown ocasional
- intentes reemplazar toda tu arquitectura frontend con un protocolo para un único flujo de trabajo específico
Errores comunes
1. Tratar A2UI como un sistema de diseño
A2UI no es tu sistema de diseño. Es el protocolo entre el agente y el renderer. Tu sistema de diseño sigue siendo responsabilidad del cliente.
2. Mezclar versiones del protocolo sin cuidado
Esta es la forma más fácil de confundirte. Elige una versión y úsala de manera consistente dentro de cada aplicación.
3. Implementar superficies enormes antes de probar el ciclo completo
Empieza con:
- una superficie
- uno o dos componentes
- una acción
- un intercambio completo con el backend
Eso basta para validar la arquitectura.
4. Olvidar los límites de confianza
La idea central de A2UI es que el cliente controla la renderización. No vuelvas a introducir los mismos problemas de seguridad permitiendo que el servidor incorpore comportamientos inseguros a través de componentes personalizados.
5. Usar A2UI en exceso para cosas que React ya resuelve
Si la interfaz pertenece por completo a tu aplicación y esta ya sabe exactamente qué debe renderizar, el código frontend normal suele ser más simple. A2UI aporta valor cuando el agente realmente necesita decidir qué superficie mostrar.
La ruta práctica de adopción que recomiendo
Si tuviera que introducir A2UI en un producto real este trimestre, lo haría en este orden:
- Construir un prototipo local de React con
A2UIViewer - Pasar a
A2UIProvider+A2UIRenderery agregar una acción significativa - Poner la generación de mensajes detrás de un endpoint de backend
- Mantener el versionado del protocolo aislado en un adaptador del lado del servidor
- Agregar componentes personalizados solo después de que funcione el flujo principal
- Integrar un transporte como A2A, AG-UI o MCP una vez validado el flujo de trabajo del producto
Esa secuencia te da confianza rápidamente sin convertir el primer experimento en un proyecto de infraestructura.
Reflexión final
A2UI no es interesante porque «la IA puede generar widgets». Es interesante porque nos da un contrato claro para algo que la industria necesita con urgencia: agentes que puedan devolver superficies de trabajo reales, con una experiencia nativa, en lugar de solo párrafos.
Para mí, la señal más sólida no es el protocolo por sí solo. Es la combinación de:
- notas oficiales sobre su uso en producción
- aplicaciones de ejemplo oficiales
- bibliotecas de renderización que puedes ejecutar ahora
- guías de transporte para A2A, AG-UI y MCP
Eso es lo que hace que valga la pena aprender A2UI ahora, en lugar de verlo como algo «interesante para algún día».
Si solo recuerdas una cosa de este artículo, que sea esta:
Usa el chat para expresar la intención. Usa A2UI cuando la respuesta deba ser una interfaz.