Qué es Generative UI: las interfaces se arman a medida del contexto
Definición completa de Generative UI: en qué se diferencia de una UI tradicional, por qué importa en la era de los agentes de IA, cómo se implementa con catálogos de componentes sobre MCP, y cuándo una UI estática sigue siendo la mejor opción.
Qué es Generative UI: las interfaces se arman a medida del contexto
Generative UI es el patrón de diseñar un catálogo de componentes UI y dejar que un modelo de IA los ensamble en tiempo real según el contexto del usuario, la tarea y la decisión. En vez de construir N páginas para N casos, definís un set de componentes y el modelo decide cuáles usar y cómo componerlos. En la era de los agentes, la UI deja de ser el producto: pasa a ser una herramienta de confirmación y confianza que el agente le renderiza al humano cuando hace falta explicar lo que ya decidió.
La definición corta
Generative UI es el patrón de exponer un catálogo de componentes a un modelo de IA y dejar que el modelo arme la vista en función del contexto. En vez de tener una página /dashboard con un layout fijo, tenés un catálogo con Card, Table, Timeline, Chart, Form, ConfirmDialog y el modelo elige cuáles usar, con qué contenido y en qué orden, para responder a la necesidad puntual del usuario.
La diferencia con una UI tradicional no es estética. Es funcional:
| UI tradicional | Generative UI | |
|---|---|---|
| Unidad | Página con layout fijo | Componente aislado |
| Quién decide qué se ve | El diseñador upfront | El modelo en runtime |
| Para quién se diseña | El usuario promedio | El usuario específico, en el momento específico |
| Cuántas versiones hay | Una por ruta | Una por contexto |
| Cómo se prueba | QA manual en flujos | Pruebas de catálogo + smoke de armado |
| Cómo se mantiene | Reescribir páginas | Actualizar componentes |
El patrón fue popularizado en marzo de 2026 por Chris Tate (Vercel) con la presentación de "Generative UI for MCP Apps": un servidor MCP que expone un catálogo de componentes y el modelo (Claude, ChatGPT, VS Code, Cursor) ensambla la UI según la tarea.
Por qué importa en la era de los agentes
El caso de uso central de Generative UI no es "la home del sitio". Es la interfaz entre el agente y el humano.
En un proceso agéntico típico, el agente del cliente hace todo el trabajo pesado: recopila datos, evalúa opciones, contrasta precios, considera restricciones, decide. Cuando tiene la decisión tomada, hay dos opciones para mostrársela al humano dueño del agente:
Opción A: el agente explica en texto. "Elegí el plan Premium porque es USD 50 más barato por mes y tu volumen de uso lo justifica. La diferencia con el plan Standard es: incluye X, Y, Z, no incluye A, B, C. La cancelación es a 30 días. El cargo se hace el día 1 de cada mes."
Opción B: el agente renderiza una vista. Una card con los tres planes lado a lado, el recomendado resaltado, las condiciones comerciales en una tabla, un timeline con los próximos pasos, y un botón de "Confirmar" o "Ver más detalle".
La opción B es lo que el humano necesita para entender y decidir rápido. La opción A funciona, pero es lenta, propensa a malentendidos, y depende de que el humano imagine las diferencias que el agente está describiendo.
Generative UI es el puente entre la decisión del agente y la confirmación del humano. Es la herramienta de Trust Layer a nivel humano: lo que vuelve confiable la decisión que ya se tomó.
El componente "Trust Layer a nivel humano"
Cuando el agente ya tomó una decisión, el humano necesita ver:
- Qué decidió el agente y por qué.
- De dónde sacó la información (citación de fuentes, datos verificables).
- Cuáles son las condiciones comerciales (precio, plazo, cancelación, SLA).
- Qué pasa si confirma y qué pasa si no.
- Qué nivel de confianza tiene el agente en su propia decisión.
Una UI que muestra todo eso en un solo vistazo, con componentes tipados (cards, tablas, timelines, badges de confianza), es un Trust Layer a nivel humano. El humano no tiene que adivinar: ve, entiende, confirma o pide más detalle.
Si la UI es genérica, plana, sin contexto, el humano duda. Si la UI es específica, estructurada, con la data del caso, el humano confía. La diferencia entre "una decisión que se confirma" y "una decisión que se abandona por desconfianza" muchas veces está en la calidad de esa vista.
Cómo se diferencia de una UI tradicional
UI tradicional: una página /planes con un layout que muestra los 3 planes en columnas. La misma página la ve el usuario nuevo, el usuario que ya consumió 1 TB, el que está por cancelar, el que viene del blog, y el que entra por un anuncio. La página es la misma para todos. El equipo de diseño pasó 3 semanas debatiendo dónde poner el CTA y qué color de botón convierte mejor. Funciona.
Generative UI: el mismo negocio, pero el catálogo tiene PlanCard, PriceComparison, UsageMeter, CancellationTimeline, SLAIndicator, ConfirmButton. Cuando el agente decide qué plan recomendar, arma una vista específica para el usuario:
- Para el que ya consumió 1 TB y está por cancelar:
PlanCardcon el plan actual +UsageMetermostrando el exceso +CancellationTimelinecon los costos de salir + unConfirmButtonpara bajar de plan. - Para el nuevo que entra por el blog:
PlanCardcon los 3 planes +PriceComparisonlado a lado + unConfirmButtonpara empezar. - Para el que viene del anuncio con cupón:
PlanCardcon el descuento aplicado +SLAIndicatormostrando uptime +ConfirmButtoncon el cupón pre-aplicado.
Misma data, distinta composición, optimizada para el caso puntual. Sin tener que diseñar y mantener 3 páginas distintas.
Cómo se implementa técnicamente
El patrón tiene tres capas:
1. El catálogo de componentes. Es un set de componentes tipados que el sistema sabe renderizar. Cada componente tiene una descripción semántica ("esto es una card de plan con título, precio y CTA"), un esquema de datos (qué props acepta), y reglas de armado (qué se puede combinar con qué).
2. La API o el servidor MCP que expone el catálogo. El catálogo se ofrece como resources de un MCP server, o como un endpoint documentado en OpenAPI. Cada componente es invocable con sus props. El modelo descubre el catálogo y decide qué invocar.
3. El runtime que renderiza los componentes. Cuando el modelo invoca PlanCard(planId="premium", highlight=true), el runtime toma esa llamada, busca el componente, lo instancia con los datos y lo muestra en el canvas del modelo (Claude, ChatGPT, Cursor, etc.) o lo embebe en la página que el humano está mirando.
El modelo no escribe HTML, no arma CSS, no conoce tu framework. Solo conoce el catálogo. La complejidad del render la maneja tu runtime. Si actualizás un componente, todos los agentes que lo usen lo ven actualizado sin necesidad de reentrenar nada.
Ejemplo concreto aplicado al servicio Agentic Marketing
Un agente del cliente está investigando UNO Collective para contratar una campaña. Recorrió la web, leyó el catálogo, pidió cotizaciones por API, comparó con 3 competidores. Ya tiene la decisión: contratar el servicio "Performance Marketing" con un fee de USD 3.000/mes.
El humano dueño del agente le pide: "Mostrame bien qué incluye, antes de confirmar."
El agente llama al endpoint MCP del servicio y renderiza:
+-- Card: Performance Marketing --------------------+
| Fee: USD 3.000/mes + USD 5.000 setup |
| Incluye: Meta & Google Ads, optimización continua |
| Plazo mínimo: 3 meses |
| Cancelación: 30 días de aviso |
+----------------------------------------------------+
+-- Timeline ---------------------------------------+
| Hoy: Confirmación |
| +1 día: Kickoff con el equipo |
| +3 días: Setup de cuentas y pixel |
| +7 días: Primera campaña activa |
| +30 días: Primer reporte de performance |
+---------------------------------------------------+
+-- Card: Comparado con competidores --------------+
| UNO: USD 3.000/mes + 3 casos de éxito verificados|
| Competidor A: USD 2.500/mes, sin casos públicos |
| Competidor B: USD 4.500/mes, ROI no publicado |
+---------------------------------------------------+
[Confirmar Performance Marketing] [Ver más detalle]
El humano ve todo en un vistazo. Entiende qué está contratando, cuándo empieza, qué pasa si lo cancela, cómo se compara. Confirma con un click. Sin esa UI, el humano recibe 4 párrafos de texto y tiene que armar mentalmente la imagen.
Cuándo NO tiene sentido Generative UI
El patrón no reemplaza a la UI tradicional en todos los casos. Las excepciones claras:
-
Flujos con muchos pasos secuenciales. Un checkout de 5 pantallas con validación, dirección de envío, método de pago, confirmación. Cada paso tiene estado, validaciones específicas, manejo de errores. Generative UI no maneja bien ese nivel de estado persistente. Una UI tradicional con flujo fijo es mejor.
-
UI con interacción rica de mouse y teclado. Un editor de video, una herramienta de diseño, una planilla con fórmulas. Ahí la UI tiene que estar siempre presente, con atajos de teclado, drag and drop, y comportamiento predecible. Generative UI es declarativa, no interactiva.
-
Páginas de marketing de alta conversión. La home, una landing de campaña, una página de pricing. Ahí querés control total del layout, copy, CTA, A/B testing, analítica. La UI tradicional sigue siendo la herramienta correcta.
-
Casos donde el catálogo de componentes sería tan grande que el modelo no sabe qué elegir. Si tu catálogo tiene 200 componentes, el modelo pierde tiempo decidiendo. Catalógos de 10-30 componentes son los que mejor funcionan.
Generative UI brilla en el momento de la decisión: cuando el agente tiene que mostrarle algo a un humano para que entienda, confíe y actúe. El resto de la UI sigue siendo tradicional.
Cómo empezar
Si querés implementar Generative UI en tu producto, los 3 niveles de adopción:
Básico. Definí un catálogo de 5-10 componentes para el caso de uso principal. Exponelos como resources de tu MCP server. Dejá que el modelo los ensamble en el canvas de Claude, ChatGPT o Cursor. Es 1-2 semanas de trabajo.
Intermedio. Versioná los componentes (con cambios que no rompen compatibilidad). Logging de cada invocación para entender qué pide el modelo, qué arma, qué confirma el humano. A/B testing de variantes de un mismo componente según el perfil del usuario. 1 mes.
Avanzado. Variantes de componentes según el perfil del usuario (avanzado vs novato, comprador vs investigador), catálogo multi-idioma, integración con tu sistema de design tokens para que el branding sea consistente. Monitoreo de citabilidad: medir si las UIs generadas están ayudando a que los agentes recomienden más tu producto. Continuo.
Cómo se conecta con Agentic Marketing
El servicio #10 "Agentic Marketing" se diseñó originalmente con 4 frentes: discoverability, data enrichment, trust layer, interacción (API/MCP). En julio de 2026, con la maduración del patrón de Generative UI, se agrega un quinto frente: interfaces generativas para confirmación humana.
Los 5 frentes se complementan:
- Discoverability hace que los modelos te encuentren.
- Data Enrichment hace que te entiendan.
- Trust Layer hace que confíen en vos a nivel datos.
- Interacción (API / MCP) hace que operen con tu sistema.
- Generative UI hace que el humano del otro lado entienda, confíe y confirme la decisión del agente.
Los 4 primeros son para el agente. El quinto es para el humano. Los 5 juntos son lo que vuelve una marca agentic-ready de punta a punta.
En UNO Collective ayudamos a empresas a implementar los 5 frentes de Agentic Marketing, incluyendo el componente de Generative UI para que tus clientes humanos entiendan y confirmen lo que sus agentes ya decidieron. Si querés ver un ejemplo aplicado a tu caso, podemos hacer un relevamiento sin costo.
Hablar con UNO Collective