Diseño de UI para agentes: principios que empezamos a entender
Actualizado: 2026-05-03
Durante dos años la conversación sobre cómo integrar agentes LLM en producto se redujo a una sola respuesta: un chat con historial a la izquierda, mensaje abajo y área de burbujas en el medio. Esa era la plantilla de facto, y todo producto nuevo la reutilizaba. Doce meses después de que la conversación industrial empezara a cuestionar ese consenso, aparecen patrones de UI pensados específicamente para lo que hacen los agentes hoy. Algunos están consolidándose con rapidez. Otros son moda del ciclo de 2025 que no sobrevivirá a una evaluación honesta.
Puntos clave
- El chat funcionaba mientras el agente hacía una tarea por vez y la conversación cabía en una pantalla; con tareas largas, efectos persistentes y herramientas múltiples, deja de bastar.
- El patrón del panel de progreso (conversación + panel separado de estado de la tarea) ha convergido en Claude Code, Cursor, Cline y Aider, lo que sugiere que funciona.
- La interfaz de revisión y aprobación transforma la confirmación ciega en decisión informada usando la semántica visual del dominio.
- El explorador de ejecuciones es el patrón menos consolidado pero el más prometedor para agentes de larga duración.
- La interfaz de voz como canal principal, el agente cero-interfaz y el agente antropomorfizado con avatar son moda que no ha cuajado.
Por qué el chat dejó de ser suficiente
El chat funcionaba mientras el agente hacía una tarea por vez y la conversación cabía en una pantalla. En cuanto los agentes empezaron a hacer trabajo de fondo durante minutos, invocar varias herramientas en paralelo y mantener estado sobre archivos, el chat se quedó corto.
Tres síntomas concretos se repiten en muchos productos:
- El usuario pulsa el botón de detener porque no sabe si el agente sigue trabajando o se ha quedado colgado.
- Después de una ejecución larga, el usuario no sabe qué archivos han cambiado ni qué comandos se han ejecutado.
- Cuando el agente falla, el usuario no tiene forma clara de ver en qué paso falló ni cómo reanudar.
Esos tres síntomas apuntan al mismo problema: el chat como metáfora no es adecuado para tareas con estado, ejecución larga y herramientas. Hacía falta algo distinto.
El patrón del panel de progreso
El primer patrón que he visto funcionar bien es separar la conversación del progreso de la tarea. La conversación se queda en una columna, y el progreso se muestra en un panel separado que lista paso a paso lo que el agente está haciendo: estado de cada herramienta, archivos tocados, comandos ejecutados y salidas resumidas. El usuario ve la historia de la ejecución sin tener que leer la conversación completa.
Este patrón ha aparecido casi idéntico en varios productos recientes. Claude Code, Cursor, Cline y Aider tienen variantes del mismo principio: conversación mínima, panel de progreso rico. La convergencia sugiere que el patrón funciona, no es casualidad.
La clave del panel de progreso es que cada paso sea colapsable y auditable. El usuario no quiere leer cada salida intermedia, pero sí quiere poder abrir un paso concreto y verlo cuando algo ha ido mal. Es la diferencia entre una barra de progreso simple y un registro navegable.
La interfaz de revisión y aprobación
El segundo patrón consolidado es la interfaz de revisión. Cuando un agente está a punto de ejecutar una acción con efectos laterales —modificar archivos, ejecutar un comando, enviar una petición a una API—, el usuario debe poder revisar y aprobar antes de que ocurra.
Lo que funciona mejor es mostrar el cambio exacto propuesto con la semántica visual del dominio:
- Un diff lado a lado si son archivos.
- Una tabla si son filas de base de datos.
- Una vista previa renderizada si es contenido publicable.
La aprobación deja de ser un botón ciego y se convierte en una decisión informada. Este patrón requiere que el agente exprese su intención en un formato revisable antes de actuar, lo que también hace el sistema más seguro y depurable. Conecta con el patrón de separación agente-ejecutor que describimos en defensa frente a prompt injection.
El explorador de ejecuciones
El tercer patrón, menos consolidado pero prometedor, es el explorador de ejecuciones. Un agente que opera durante horas puede haber ejecutado decenas de tareas, y el usuario necesita navegar ese historial con un modelo mental claro.
No sirve una lista lineal; hace falta una vista arborescente donde cada tarea tiene subtareas y cada invocación tiene entradas y salidas. Productos como OpenAI Agent Responses o las vistas de ejecución en plataformas como Modal están experimentando con estructuras jerárquicas. No hay consenso todavía, pero la dirección está clara: el registro lineal no escala con la complejidad actual.
Moda que no funciona
Tres patrones han aparecido con mucho ruido pero no han cuajado:
- La interfaz de voz como canal principal para agentes de trabajo. Sirve para asistentes de consumo y casos de manos ocupadas, pero no para tareas técnicas donde el usuario necesita ver código, diffs y tablas.
- La interfaz cero, el agente que aprende tus hábitos y actúa sin confirmar. Choca con la realidad de que los modelos se equivocan con suficiente frecuencia como para que el usuario necesite control sobre acciones con efecto.
- El agente antropomorfizado con avatar y mímica facial. Genera interés en demos pero ruido en uso habitual. Los equipos que lo han probado en producto han acabado quitándolo porque distrae.
Principios que empiezan a emerger
Cinco principios se repiten en los productos que funcionan:
- Hacer visible el estado del agente en todo momento. El usuario nunca debe dudar si está trabajando, esperando entrada o ha terminado. La ambigüedad de estado es el problema número uno.
- Separar conversación de ejecución. Hablar con el agente y ver lo que hace son dos tareas distintas que requieren dos espacios visuales distintos.
- Preservar la reversibilidad. Todo paso de efecto lateral debe ser revertible o al menos auditar el cambio con suficiente detalle para deshacerlo.
- Calibrar la confianza explícitamente. El agente debe indicar cuándo está haciendo algo rutinario y cuándo algo experimental donde el usuario debería revisar con más atención.
- Dejar al usuario el vocabulario del dominio. Si el dominio es código, la UI debe hablar de archivos, funciones y commits. Si es soporte, de tickets y conversaciones. Una UI genérica de chat en un dominio técnico pierde capacidad expresiva.
Cómo pensar la decisión
La pregunta que más ayuda no es qué patrón copiar sino qué tareas están haciendo los usuarios y cuánto dura cada una:
- Si la tarea dura menos de un minuto y no tiene efectos persistentes, el chat es suficiente.
- Si dura más de cinco minutos o tiene efectos persistentes, el chat deja de bastar y hay que pensar en panel de progreso, revisión y explorador de ejecuciones.
La otra pregunta útil es cuánta confianza tiene el usuario en el agente. Si es nueva, hay que sobreinformar: cada paso visible, cada decisión auditable, cada acción reversible. Si el usuario lleva meses usándolo y confía, se puede simplificar y ocultar detalles. El mismo producto probablemente necesita dos modos de UI para la misma funcionalidad según el nivel de madurez del usuario.
El chat va a quedarse como canal de entrada universal, pero los productos serios van a tener interfaces mucho más ricas detrás. La era de la burbuja de texto como única metáfora para agentes está terminando, y los equipos que inviertan ahora en patrones alternativos van a tener ventaja competitiva cuando la expectativa del usuario evolucione.
