Durante dos anios la conversación sobre como 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 forma canonica, la plantilla de facto, y todo producto nuevo la reusaba. Doce meses después de que la conversación industrial empezara a cuestionar ese consenso, aparecen patrones de UI pensados especificamente para lo que hacen los agentes hoy. Algunos estan consolidandose con rapidez. Otros son moda del ciclo de 2025 que no sobrevivira a una evaluación honesta.
Este post repasa los principios que empiezo a ver funcionar en producto real, los que siguen siendo experimentos, y donde creo que se va a estabilizar la interfaz de agente en los próximos meses.
Por que el chat dejo de ser suficiente
El chat funcionaba mientras el agente hacia una tarea por vez y la conversación cabia 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 quedo corto. La ventana de conversación empezo a llenarse de ruido, los mensajes de herramienta se mezclaban con los mensajes del modelo, y el usuario perdia la vision de lo que estaba pasando realmente.
Los sintomas concretos que vi repetirse en muchos productos eran tres. El primero era que el usuario pulsaba el boton de detener porque no sabia si el agente seguia trabajando o se habia quedado colgado. El segundo era que, después de una ejecución larga, el usuario no sabia que archivos habian cambiado ni que comandos se habian ejecutado. El tercero era que, cuando el agente fallaba, el usuario no tenia forma clara de ver en que paso fallo ni como reanudar.
Esos tres sintomas apuntaban al mismo problema: el chat como metafora no era adecuado para tareas con estado, ejecución larga y herramientas. Hacia falta algo distinto.
El patron del panel de progreso
El primer patron 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 esta haciendo, con estados 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 patron ha aparecido casi identico en varios productos recientes. Claude Code, Cursor, Cline y Aider tienen variantes del mismo principio: conversación minima, panel de progreso rico. La convergencia sugiere que el patron 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 si 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 revision y aprobacion
El segundo patron consolidado es la interfaz de revision. Cuando un agente esta a punto de ejecutar una accion con efectos laterales, como modificar archivos, ejecutar un comando o enviar una peticion a una API, el usuario debe poder revisar y aprobar antes de que ocurra. En teoria esto ya estaba en el chat original como confirmacion de texto, pero en la práctica la confirmacion textual es insuficiente porque el usuario no lee el mensaje completo.
Lo que funciona mejor es mostrar el cambio exacto propuesto con la semantica 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 aprobacion deja de ser un boton ciego y se convierte en una decision informada.
Este patron requiere que el agente exprese su intencion en un formato revisable antes de actuar. Es una presion arquitectonica útil: obliga a separar el razonamiento del efecto, lo que hace el sistema mas seguro y mas depurable.
El explorador de ejecuciones
El tercer patron, 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 invocacion tiene entradas y salidas.
Los productos que empiezan a implementar este patron, como OpenAI Agent Responses o las vistas de ejecución en plataformas como Modal, experimentan con estructuras jerarquicas. No hay consenso todavia, pero la dirección esta clara: el registro lineal no escala con la complejidad actual.
Moda que no funciona
Hay patrones que han aparecido con mucho ruido pero no han cuajado. El primero es 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.
El segundo es la interfaz cero, el agente que aprende tus habitos y actua sin confirmar. Suena ambicioso pero choca con la realidad de que los modelos siguen equivocandose con suficiente frecuencia como para que el usuario necesite control sobre acciones con efecto. Una fantasia para tareas importantes.
El tercero es el agente antropomorfizado con avatar y mimica facial. Genera interes en demos pero ruido en uso habitual. Los equipos que lo han probado en producto han acabado quitandolo porque distrae.
Principios que empiezan a emerger
Cinco principios se repiten en los productos que funcionan. El primero es hacer visible el estado del agente en todo momento. El usuario nunca debe dudar si esta trabajando, esperando entrada o ha terminado. La ambiguedad de estado es el problema número uno.
El segundo es 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.
El tercero es preservar la reversibilidad. Todo paso de efecto lateral debe ser revertible o al menos auditar el cambio con suficiente detalle para deshacerlo. El usuario debe poder recuperar el estado previo si decide que la dirección era incorrecta.
El cuarto es calibrar la confianza explicitamente. El agente debe indicar cuando esta haciendo algo rutinario y cuando algo experimental donde el usuario deberia revisar con mas atención.
El quinto es 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 con el cliente. Una UI generica de chat en un dominio técnico pierde capacidad expresiva.
Como pensar la decision
Cuando un equipo me pregunta como disenar la UI de su producto de agente, la pregunta que mas ayuda no es que patron copiar sino que tareas estan haciendo los usuarios y cuanto dura cada una. Si la tarea dura menos de un minuto y no tiene efectos persistentes, el chat es suficiente. Si dura mas de cinco minutos o tiene efectos persistentes, el chat deja de bastar y hay que pensar en panel de progreso, revision y explorador de ejecuciones.
La otra pregunta útil es cuanta confianza tiene el usuario en el agente. Si es nueva, hay que sobreinformar: cada paso visible, cada decision auditable, cada accion reversible. Si el usuario lleva meses usandolo y confia, se puede simplificar y ocultar detalles. El mismo producto probablemente necesita dos modos de UI para la misma funcionalidad segun el nivel de madurez del usuario.
Mi conviccion después de ver este ciclo es que el chat va a quedarse como canal de entrada universal, pero los productos serios van a tener interfaces mucho mas ricas detras. La era de la burbuja de texto como unica metafora para agentes esta terminando, y los equipos que inviertan ahora en patrones alternativos van a tener ventaja competitiva cuando la expectativa del usuario evolucione en los próximos meses.
