Ingeniería de IA
A2UI de Google: el agente compone la interfaz y tú decides sus límites
A2UI permite que un agente componga interfaces con tu catálogo de componentes. Cómo encaja con AG-UI y CopilotKit, qué controla el frontend y qué valida el servidor.
La respuesta puede ser una pantalla que se pueda usar
Un agente que compara opciones no siempre debería devolver una lista de párrafos. A veces hacen falta un selector, varios campos y una confirmación clara. A2UI permite describir esa interfaz mediante datos para que la aplicación la dibuje con sus propios componentes.
La guía conjunta de Google y CopilotKit del 29 de octubre profundiza en la integración de este formato ya existente con agentes de distintos frameworks. Lo relevante es el reparto del trabajo: el equipo construye las piezas y el agente decide cómo combinarlas para la petición concreta.
A2UI, AG-UI y CopilotKit hacen trabajos distintos
A2UI describe qué debe aparecer y con qué datos. AG-UI puede transportar esos mensajes y los eventos de la conversación. CopilotKit aporta la integración entre el agente y la aplicación, con el runtime y las superficies donde se muestra la interfaz.
En la ruta que explica la guía, un agente compatible con AG-UI emite operaciones A2UI y el cliente las entrega a su renderer. A2UI también admite otros transportes: elegir el formato de la interfaz no obliga por sí solo a adoptar todo un framework de agentes.
| Pieza | Responsabilidad |
|---|---|
| A2UI | Describir y actualizar componentes y datos |
| AG-UI | Llevar eventos entre el agente y la aplicación |
| Renderer | Convertir la descripción en componentes reales |
El catálogo es parte del producto
El catálogo define los componentes, funciones y propiedades disponibles. Puede reflejar el sistema de diseño que ya utiliza tu aplicación. El agente recibe ese contrato y el cliente aporta el código que lo representa. Un nombre de componente inventado no debería convertirse en código ejecutable por haber llegado en un mensaje.
Un ejemplo propuesto sería un asistente para comparar planes de almacenamiento. El equipo ofrece un comparador, un selector de usuarios y una acción para revisar la elección. El agente decide qué mostrar según la consulta. El frontend conserva las etiquetas, los estados de carga, el foco y el comportamiento accesible que hayas implementado.
Esto cambia dónde inviertes el esfuerzo. Diseñas bloques reutilizables y sus límites, además de probar las combinaciones que el agente puede producir. La interfaz sigue necesitando trabajo de producto; el catálogo no diseña automáticamente una buena experiencia.
Escribir en un campo no necesita otra respuesta del modelo
Los campos se vinculan a rutas del modelo de datos de la interfaz. Al escribir, el renderer actualiza ese estado local. En el patrón de formulario, el botón resuelve los valores actuales y envía una acción al agente. Así no necesitas convertir cada pulsación en otra llamada al modelo.
En el comparador propuesto, cambiar el número de usuarios puede actualizar primero el formulario. Al solicitar la revisión se envían los valores elegidos y el servidor consulta el precio vigente. Seleccionar una opción y contratarla son operaciones diferentes; el mensaje de la interfaz no sustituye esa comprobación.
También hay que decidir qué estado se comparte. Con sendDataModel activado, el protocolo permite adjuntar el modelo completo de la superficie a los mensajes enviados. Si intervienen varios subagentes, el orquestador debe dirigir esos datos al propietario correcto de la superficie.
Un JSON válido todavía puede pedir algo incorrecto
El cliente necesita comprobar mensajes y propiedades antes de dibujarlos. En la familia 0.9, la generación basada en instrucciones requiere validación posterior y tratamiento de errores. Un esquema en el prompt no garantiza que el modelo lo respete.
La validación de formulario mejora la interacción, pero el backend debe volver a validar datos y permisos. En el ejemplo, un identificador de plan con formato correcto puede referirse a un plan retirado. Tampoco basta con que aparezca un botón llamado Confirmar para autorizar cualquier efecto asociado.
Conviene distinguir además versiones del protocolo y versiones de las librerías. Al consultar la documentación el 31 de octubre, A2UI 0.9.1 figura como versión de producción y 1.0 como candidata. No asumas que todos los renderers implementan lo mismo por aceptar mensajes llamados A2UI.
Dónde merece la pena usarlo
Encaja en tareas donde la conversación descubre lo que hace falta y después hay que comparar, ajustar o revisar datos. Un formulario compuesto con piezas conocidas puede evitar varios turnos para aclarar qué opción eligió la persona.
Si el recorrido siempre es idéntico, una pantalla convencional puede resultar más sencilla de mantener. Para probar A2UI empezaría con un catálogo pequeño y una tarea acotada, revisando teclado, móvil, errores de generación y cambios de estado. Para decidir si compensa, mide si las personas completan la tarea con menos errores o pasos.