La generative UI (o agentic UI) es la idea de que un agente de IA no responda solo con texto, sino que construya la interfaz que necesitas en cada momento: una tarjeta de producto, un formulario de reserva, un panel con tres gráficas. En Flutter esto tiene ya nombre y herramientas concretas: el GenUI SDK y el protocolo abierto A2UI, presentados por Google en el I/O de 2026. Aquí explicamos qué son, cómo encajan con MCP y A2A, y —lo más importante para un equipo de producto— cuándo todavía no deberías meterlos en producción.
Qué es la generative UI y por qué no es "otro chatbot"
Un chatbot devuelve una cadena de texto y como mucho unos botones de acción predefinidos. La generative UI cambia el contrato: el modelo devuelve una especificación de interfaz (qué componentes mostrar, con qué datos y en qué disposición) y tu app la renderiza con sus widgets nativos reales.
La diferencia práctica es doble:
- Menos fricción conversacional. En lugar de negociar por chat "¿qué día quieres volar?", el agente genera directamente un selector de fechas y un listado de vuelos.
- UI que se adapta a la intención. La misma app puede mostrar un dashboard financiero a un CFO y un formulario de alta a un usuario nuevo, sin que ninguna de esas pantallas exista "hardcodeada".
El matiz importante: no es magia de layout automático. El agente solo puede pedir componentes que tú has aprobado previamente. Es orquestación sobre un catálogo cerrado, no generación libre de UI.
A2UI: el protocolo que hace la UI "segura como datos y expresiva como código"
A2UI (Agent-to-UI) es un proyecto abierto (licencia Apache 2.0) impulsado por Google con contribuciones de equipos de Cisco, IBM, SAP, Salesforce y CopilotKit/AG-UI. Su objetivo lo resume bien su propia documentación: las respuestas de UI generadas por agentes tenían que ser "seguras como los datos, pero expresivas como el código".
Se apoya en tres piezas:
- Formato. Árboles de componentes en JSON plano y amigable para LLM, con referencias por
idque permiten actualizaciones incrementales (no reenviar toda la pantalla en cada turno). - Transporte. Los mensajes viajan sobre el protocolo A2A (Agent-to-Agent), AG-UI u otros canales. A2UI no reinventa el transporte: se enchufa al que ya uses.
- Render. El cliente mapea las descripciones abstractas de componentes a widgets nativos: Flutter, React, Web Components o SwiftUI.
La clave de seguridad está en el catálogo: el cliente mantiene un conjunto de componentes preaprobados y el agente solo puede pedir que se rendericen esos. No hay ejecución de código arbitrario ni inyección de UI. Esto es lo que permite que un agente remoto, en un sistema multiagente descentralizado, mande interfaz cruzando fronteras de confianza sin iframes sandbox ni eval.
Cómo encaja con A2A y con MCP
- A2A resuelve la comunicación agente-a-agente. A2UI resuelve la capa de UI: un agente puede enviar mensajes A2UI directamente al cliente a través de A2A.
- MCP Apps aborda un problema parecido pero distinto: trata la UI como recursos que se piden vía URIs
ui://y se renderizan en iframes en sandbox. A2UI, en cambio, envía planos de componentes que heredan el estilo de tu app y son legibles por otros agentes orquestadores.
No son competidores excluyentes: MCP sigue siendo la vía para exponer herramientas y contexto a un modelo; A2UI es la vía para que el resultado se dibuje de forma nativa y segura.
GenUI SDK: cómo se implementa en Flutter
El GenUI SDK (paquete genui) es la implementación de referencia de A2UI para Flutter. En la práctica, integrarlo tiene cuatro conceptos:
1. Catálogo de widgets. Declaras qué componentes puede pedir el agente. Cada CatalogItem combina un nombre (el identificador que ve el modelo), un schema de datos y un builder de Flutter:
final riddleCard = CatalogItem(
name: 'RiddleCard',
dataSchema: S.object(
properties: {
'question': S.string(description: 'La pregunta de la adivinanza.'),
'answer': S.string(description: 'La respuesta.'),
},
required: ['question', 'answer'],
),
widgetBuilder: (itemContext) {
final json = itemContext.data as Map<String, Object?>;
return Card(child: Text(json['question'] as String));
},
);
2. Controlador y transporte. El SurfaceController recibe el catálogo y un A2uiTransportAdapter conecta el stream del modelo (Firebase AI Logic, un servidor A2UI propio, o un adaptador a medida para tu LLM):
final surfaceController = SurfaceController(
catalogs: [BasicCatalogItems.asCatalog().copyWith(newItems: [riddleCard])],
);
3. Conversación. La clase Conversation orquesta el ida y vuelta y emite eventos de ciclo de vida (ConversationSurfaceAdded, ConversationSurfaceRemoved) que tu widget escucha para añadir o quitar "superficies" de UI.
4. Data binding reactivo. Un DataModel observable actúa como estado central: los inputs enlazan a rutas ({"binding": {"path": "/user/name"}}) y los widgets que leen esa ruta se reconstruyen solos cuando cambia. La UI generada es reactiva por defecto.
El resultado es que el agente devuelve algo así:
{ "id": "welcome", "component": "Text", "text": "Hola", "variant": "h1" }
…y GenUI lo renderiza con tu Text real, con tu tema, tus fuentes y tu Material 3.
A2UI vs MCP Apps vs structured outputs: tabla comparativa
| Enfoque | Qué devuelve el modelo | Render | Seguridad | Madurez (jul. 2026) |
|---|---|---|---|---|
| Structured outputs (JSON tool calling) | Datos estructurados; tú decides la UI a mano | Widgets fijos que programas tú | Alta (tú controlas todo) | Producción estable |
MCP Apps (ui://) | Recursos de UI vía URI | Iframe en sandbox | Aislamiento por sandbox | Emergente |
| A2UI / GenUI | Planos de componentes JSON | Widgets nativos desde catálogo | Catálogo cerrado, sin código arbitrario | Alfa / pre-1.0 |
Dónde aporta valor de verdad
- Asistentes de dominio (fintech, travel, salud) donde la conversación deriva constantemente en formularios, selectores y confirmaciones que hoy programas uno a uno.
- Superficies dinámicas que cambian según el rol o el contexto del usuario sin multiplicar pantallas en tu código.
- Sistemas multiagente donde un agente remoto necesita presentar UI en tu app sin que le des acceso a ejecutar nada.
Cuándo NO usar GenUI todavía
Aquí es donde toca ser honestos. GenUI y A2UI son prometedores, pero en julio de 2026 no son la opción por defecto:
- Es alfa y pre-1.0. El paquete
genuiestá explícitamente en alfa y A2UI ronda la v0.8; la API "puede cambiar, a veces drásticamente". No lo pongas en la ruta crítica de un producto en producción sin un plan de migración. - El system prompt pesa. Inyectar el catálogo y la semántica de A2UI genera prompts de 3.000–5.000+ tokens, lo que encarece cada llamada y puede reventar los límites de modelos on-device.
- Latencia y coste. Generar UI en cada turno añade latencia de inferencia frente a una pantalla precompilada. Para flujos de alta frecuencia, un
structured outputrenderizado con widgets fijos suele ganar. - Determinismo y QA. Una UI que el modelo decide en runtime es más difícil de testear, versionar y auditar. En sectores regulados (salud, banca), eso es un coste real de cumplimiento.
- Si tus pantallas son estables, no necesitas generative UI: necesitas buen diseño de componentes. No metas un agente donde basta un
switch.
Nuestra recomendación práctica: empieza por un catálogo pequeño en un flujo acotado y no crítico (por ejemplo, un asistente interno), mide latencia y coste por interacción, y solo entonces evalúa ampliarlo.
Cómo lo abordamos en Dribba
Como Partner oficial de Flutter de Google —única agencia española en el directorio desde 2017— seguimos de cerca A2UI y GenUI desde su presentación, precisamente porque tocan las dos capas en las que trabajamos: Flutter y los agentes de IA en producción. Nuestro criterio no cambia con el hype: adoptamos una tecnología cuando aporta valor medible al producto y tiene un camino claro de mantenimiento, no antes.
En proyectos donde la generative UI encaja, la introducimos de forma incremental —catálogo acotado, transporte propio y observabilidad del agente— para que el equipo pueda revertir sin dolor. En los que no, decimos que no.
Conclusión
GenUI y A2UI son, probablemente, el cambio arquitectónico más interesante que le ha pasado a Flutter en 2026: convierten la UI en algo que un agente puede generar de forma segura y nativa. Pero son tecnología joven. La decisión inteligente hoy no es "¿lo usamos ya?", sino "¿en qué flujo acotado podemos experimentar sin riesgo mientras madura?".
Si estás valorando integrar agentes con interfaz generativa en tu app Flutter y quieres una opinión técnica sin humo sobre si te compensa —o si es mejor esperar—, hablemos. Y si quieres el contexto previo, tenemos también un artículo sobre agentes de IA que construyen apps Flutter en tiempo de desarrollo y otro sobre context engineering para agentes en producción.
