Panel de Control Agentes de IA: Orquestando Claude Code entre Dispositivos
Introducción
En diciembre de 2025 escribí sobre cómo los desarrolladores nos hemos convertido en orquestadores de agentes, pasando de implementar código a dirigir múltiples agentes de IA trabajando en paralelo. Las mejoras en productividad son reales, pero también lo es el caos.
Ejecutar de 5 a 10 sesiones de Claude Code en varias máquinas, diferentes proyectos y múltiples ramas de git se vuelve rápidamente inmanejable. Personalmente, me olvidaba de sesiones, perdía la pista de qué estaba ejecutándose y dónde, y a veces solo redescubría trabajo abandonado horas o días después.
Las pestañas en el terminal y tmux pueden resolver la organización local. Pero no resuelven la visibilidad entre dispositivos. Necesitaba una vista única de todo, así que construí un dashboard.
El Problema: Orquestar Sin Visibilidad
Mi configuración diaria incluye un MacBook para trabajar sobre la marcha y una estación de trabajo Linux para tareas más pesadas. En cualquier día, puedo tener múltiples sesiones de Claude Code ejecutándose en ambas máquinas, cada una abordando tareas distintas en diferentes proyectos y ramas.
La carga cognitiva de rastrear qué agente está haciendo qué, en qué máquina, se acumula rápido. Tienes que recordar qué ventana de terminal corresponde a qué proyecto, en qué rama está trabajando cada agente, si una sesión sigue activa o se ha bloqueado, y si el agente está esperando permiso o ya ha terminado.
Sin una vista centralizada, el flujo de trabajo de orquestador que describí en mi artículo sobre productividad se desmorona. Pierdes las ventajas del paralelismo que hace que el desarrollo asistido por IA sea tan potente.
Las herramientas existentes solo resuelven partes de este problema. Tmux y los multiplexores de terminal funcionan muy bien en una sola máquina, pero no abarcan dispositivos. Las soluciones basadas en IDE están ligadas a un editor específico. Lo que necesitaba era una herramienta que pudiera agregar información de todas mis máquinas y presentarla en una única vista en tiempo real.
Como comenté en El Futuro de las Herramientas para Desarrolladores, nuestras herramientas necesitan adaptarse a los flujos de trabajo con agentes de IA. Este dashboard es un ejemplo de cómo debería de ser dicha adaptación en la práctica.
El Verdadero Reto: Cambio de Contexto y Carga Cognitiva
Algo que no se discute lo suficiente es que el mayor cuello de botella en el desarrollo paralelo asistido por IA no es la IA en sí. Es el humano.
Cuando estás orquestando múltiples agentes, la carga cognitiva del cambio de contexto entre sesiones se convierte en la principal limitación. ¿En qué estaba trabajando cada agente? ¿Esa sesión terminó o se quedó bloqueada? ¿El agente está esperando mi respuesta? Cada vez que tienes que responder estas preguntas abriendo terminales e inspeccionando el estado manualmente, pagas un impuesto de cambio de contexto que se come las mejoras en productividad que intentas conseguir.
Este es el reto central de la era del orquestador: gestionar la sobrecarga mental del trabajo en paralelo. Cualquier herramienta que pretenda dar soporte al desarrollo asistido por IA necesita abordar esto de frente.
El Dashboard: Qué Hace
El dashboard proporciona una vista en tiempo real de todas mis sesiones de agentes activas en cada dispositivo y proyecto.
Las sesiones están organizadas por dispositivo, de modo que puedo ver inmediatamente qué se está ejecutando en mi MacBook frente a mi estación de trabajo. Cada sesión se representa como una tarjeta que muestra información clave de un vistazo:
- Proyecto y rama git: En qué repositorio y rama está trabajando el agente.
- Enlace al Pull Request: Si el agente ha creado o está trabajando en un PR, se muestra un enlace directo.
- Modelo y uso de contexto: Qué modelo LLM está usando la sesión y cuánto de la ventana de contexto se ha consumido.
- Estado: Si el agente está trabajando activamente, en reposo, o esperando permiso del usuario.
- Descripción de la tarea: Un resumen de lo que el agente está haciendo en ese momento.
- Servidores MCP: Qué servidores de Model Context Protocol están conectados a la sesión.
El dashboard se actualiza en tiempo real a medida que los agentes reportan su estado. Utiliza este flujo de información para detectar automáticamente sesiones inactivas o caídas. Si un agente deja de reportar durante demasiado tiempo, la tarjeta de sesión refleja que algo puede haber ido mal.
Al externalizar este estado, el dashboard ataca directamente el problema de cambio de contexto que describí antes. En lugar de recorrer ventanas de terminal para reconstruir qué está pasando, puedo echar un vistazo al dashboard y conocer el estado de cada agente al instante.
Conexión Remota al Terminal
La funcionalidad que lo cambió todo para mí es la capacidad de conectarme a cualquier sesión de agente directamente desde el navegador.
He visto a desarrolladores montar soluciones elaboradas para conseguir acceso remoto al terminal: VPNs con Tailscale, túneles SSH desde el móvil, configuraciones complejas de tmux con sesiones anidadas, y scripts personalizados para mantener todo sincronizado. Estos enfoques funcionan, pero añaden capas de fricción y configuración que se convierten en una carga de mantenimiento en sí mismos.
El dashboard toma un enfoque diferente. Cuando hago clic en una sesión, obtengo un terminal en vivo integrado directamente en el navegador, conectado a la sesión de ese agente. Puedo leer la salida, proporcionar entrada, aprobar permisos, o intervenir si el agente se desvía. Sin configuración de SSH, sin VPN, sin app de terminal en el móvil. Solo un navegador y la misma interfaz en todas partes.
Esto funciona desde cualquier dispositivo: mi portátil, mi teléfono, una tablet, o cualquier máquina con un navegador web. Durante la comida, puedo revisar una sesión de larga duración desde mi teléfono. En el sofá por la tarde, puedo revisar lo que un agente produjo durante el día desde una tablet. La experiencia de usuario es la misma en todas partes porque la interfaz es siempre la misma aplicación web.
La seguridad fue una preocupación de diseño primordial desde el principio. Esto se ejecuta en mi propio entorno con registro autenticado de dispositivos y acceso limitado, así que el objetivo es la comodidad sin exponer el acceso al terminal públicamente.
Creación Remota de Sesiones
Si la conexión remota al terminal es la funcionalidad que me mantiene conectado, la creación remota de sesiones es la que me permite ser productivo desde cualquier lugar.
Desde el dashboard, puedo iniciar una nueva sesión de Claude Code en cualquiera de mis dispositivos registrados. Elijo un dispositivo, selecciono un proyecto de los repositorios disponibles, y una nueva sesión de agente se lanza en una nueva ventana de tmux en esa máquina. El dashboard la detecta inmediatamente y empieza a monitorizarla.
Esto significa que puedo lanzar sesiones de agentes mientras voy en transporte, y después sentarme a revisar los resultados. Puedo distribuir trabajo entre máquinas según para qué sea mejor cada una, enviando tareas intensivas a la estación de trabajo y las más ligeras al portátil.
La capacidad de empezar trabajo desde cualquier lugar y revisarlo desde otro ha cambiado fundamentalmente cuándo y dónde puedo ser productivo.
Cómo Funciona: Visión General de la Arquitectura
En lugar de repasar cada detalle de implementación, quiero destacar la arquitectura a alto nivel y las decisiones de diseño que hacen este sistema flexible.
El sistema sigue un modelo de heartbeat. Cada sesión de agente reporta su estado al backend del dashboard a intervalos regulares. Este reporte incluye información del proyecto, estado de git, uso de contexto, servidores MCP activos, y la tarea actual del agente.
Los datos de heartbeat se recopilan a través de hooks del agente. En el caso de Claude Code, son hooks de notificación que se disparan cuando el agente transiciona entre estados (trabajando, en reposo, esperando permiso). Los hooks ejecutan un script ligero que envía el estado de la sesión a la API del dashboard.
Para la conexión al terminal, el backend establece un relay WebSocket entre el navegador y la sesión de terminal de la máquina remota. Como el agente y el humano se conectan a la misma sesión subyacente, pueden interactuar con ella simultáneamente.
La decisión de diseño con la que estoy más satisfecho es el patrón enricher. Los datos brutos que llegan de los hooks del agente pasan por una cadena de enrichers, cada uno responsable de extraer o derivar información específica. Por ejemplo, un enricher analiza el transcript del agente para extraer el nombre del modelo, uso de tokens y porcentaje de contexto. Otro enricher detecta URLs de PRs a partir de la rama git.
Este patrón es lo que hace que el sistema sea extensible y agnóstico respecto al agente en el core del dashboard, con hooks y enrichers específicos de cada agente manejando la capa de adaptación. El dashboard no necesita conocer los detalles internos de ningún agente en particular. Solo necesita un script de hook que envíe heartbeats y un enricher que sepa cómo interpretar los datos brutos. Dar soporte a un nuevo agente CLI, ya sea Goose, Gemini CLI, o cualquier herramienta futura, es principalmente cuestión de escribir un nuevo hook y un nuevo enricher. El resto del sistema permanece inalterado.
Una nota sobre el alcance: actualmente está optimizado para orquestación e intervención en vivo, no para analíticas a largo plazo. El enfoque es visibilidad y control en tiempo real entre dispositivos. Puedo añadir vistas históricas más adelante, pero la victoria inmediata fue reducir el coste de verificar y dirigir sesiones activas.
Lo Que He Aprendido Usándolo
Después de varias semanas de uso diario, algunas ideas destacan.
La visibilidad reduce la carga cognitiva drásticamente. La mayor mejora no es ninguna funcionalidad específica. Es simplemente poder verlo todo de un vistazo. Antes del dashboard, gastaba energía mental rastreando el estado de las sesiones en mi cabeza. Ahora ese estado está externalizado, y puedo centrarme en decisiones de mayor nivel como qué asignar a continuación y qué resultados revisar primero.
El porcentaje de contexto es la métrica más útil. De todos los campos del dashboard, el uso de contexto ha sido el mejor predictor de dónde debo mirar a continuación. Cuando un agente tiene un nivel de uso de contexto elevado, normalmente significa que necesito revisar su progreso, reiniciar con una sesión nueva, o preparar un traspaso.
La visibilidad de PRs acorta el ciclo de revisión. Ver qué sesiones han producido pull requests, con enlaces directos, me permite pasar de la orquestación a la revisión inmediatamente en vez de buscar entre las notificaciones de GitHub.
El acceso remoto cambia cuándo y dónde puedes ser productivo. Esto suena obvio en retrospectiva, pero experimentarlo es diferente de teorizarlo. Poder iniciar una sesión desde mi teléfono durante una pausa para el café y revisar los resultados desde mi estación de trabajo una hora después ha añadido momentos genuinamente productivos a partes del día que antes eran tiempo muerto.
Próximos Pasos
El dashboard es funcional y lo uso a diario, pero la hoja de ruta está guiada por un objetivo claro: reducir la necesidad de salir del dashboard para cualquier cosa.
A corto plazo, me centro en funcionalidades que eliminan viajes de ida y vuelta a otras herramientas:
- Gestión de configuración de agentes: Configurar el comportamiento de los agentes directamente desde el dashboard en lugar de editar archivos de configuración en cada máquina.
- Adjunción de archivos: Enviar archivos, documentos de contexto o material de referencia a una sesión de agente sin cambiar al terminal.
- Visor de diffs de código: Revisar los cambios que un agente ha hecho sin abrir un IDE, cerrando un hueco importante en el flujo de trabajo de orquestación.
En cuanto a extensibilidad, el soporte para agentes adicionales es el siguiente paso natural. El patrón enricher que describí antes fue diseñado con esto en mente. A medida que surjan más agentes CLI, el dashboard debería poder agregar sesiones de todos ellos en la misma vista unificada, independientemente de qué agente se esté ejecutando.
Y lo más importante, estoy considerando seriamente liberar el código del dashboard, o al menos los componentes clave: los scripts de hook, el protocolo de heartbeat y el framework de enrichers. Estas piezas podrían ser útiles para cualquiera que esté construyendo flujos de trabajo de orquestación similares, y me encantaría ver qué hacen otros con ellas.
Si estás ejecutando agentes de IA en paralelo y tienes ideas sobre qué haría una herramienta así más útil, me encantaría saber de ti. Ya sea una idea de funcionalidad, un enfoque diferente al mismo problema, o simplemente tu experiencia gestionando múltiples agentes, escríbeme.
Conclusión
El cambio de implementador a orquestador que describí en mi artículo sobre productividad requiere herramientas diferentes. Los terminales e IDEs estándar no fueron diseñados para un desarrollador gestionando una flota de agentes de IA en múltiples máquinas.
Este dashboard es mi respuesta actual a ese vacío. Me da visibilidad, control y una forma consistente de monitorizar, intervenir y lanzar trabajo desde cualquier lugar.
Los desarrolladores que aprendan a orquestar agentes de IA de forma efectiva tendrán una ventaja real en la próxima era de la ingeniería de software. Y las herramientas que construyamos hoy para dar soporte a esa orquestación, por muy en bruto y poco pulidas que estén, darán forma a lo que esa era será.
Sigo iterando sobre esto, y agradecería cualquier feedback, sugerencia de funcionalidades y experiencias de cualquiera que esté afrontando retos similares.
