Herdr, Hermes y un VPS: mis agentes siguen sin mi Mac
Mike Codeur
Suelo trabajar en varios productos en paralelo. Cada proyecto acumula terminales, ramas, pruebas y varias sesiones de Claude Code o Codex. Dos pestañas se controlan bien. Cuando aumenta el número de agentes, pierdo tiempo buscando cuál espera una respuesta, cuál terminó y cuál sigue trabajando.
Separé dos problemas que antes trataba como uno: organizar las sesiones y ejecutar el trabajo en una máquina que siga disponible. Herdr resuelve el primero. Un VPS resuelve el segundo. Hermes me permite consultar el estado a distancia, tomar una decisión y volver a intervenir cuando hace falta.
Por qué dividir el terminal deja de ser suficiente
Ghostty, tmux y los terminales con paneles siguen siendo útiles. Los sigo usando. El problema aparece cuando la pantalla se convierte en una pila de contextos difíciles de leer.
Con varios proyectos activos necesito responder rápido a cuatro preguntas:
- qué agente trabaja en qué repositorio y rama;
- qué sesión espera una decisión humana;
- qué pruebas pasaron de verdad;
- dónde están la conversación y el diff, sin reconstruir el contexto.
Un panel adicional muestra otro proceso. No convierte automáticamente una flota de terminales en un sistema legible.
Herdr organiza las sesiones sin sustituir a los agentes
Herdr es un runtime de terminales pensado para el trabajo multiagente. Organiza las sesiones en tres niveles: workspace, tab y pane. En mi configuración, un workspace corresponde a un proyecto u objetivo, una tab agrupa una fase del trabajo y cada pane contiene un terminal real.
Claude Code, Codex y los shells siguen ejecutando las tareas. Herdr no los sustituye. Proporciona el cockpit para ver las sesiones, pasar de una a otra y detectar las que parecen estar trabajando, esperando o terminadas.
| Elemento | Función | Ejemplo |
|---|---|---|
| Workspace | Aislar un proyecto u objetivo | API, frontend o corrección acotada |
| Tab | Agrupar una fase de trabajo | Implementación, pruebas, revisión |
| Pane | Alojar un terminal real | Claude Code, Codex, shell de pruebas |
| Estado visible | Dirigir la atención | Agente bloqueado o sesión inactiva |
Un estado done no demuestra calidad. Siempre reviso el diff, las pruebas y el resultado funcional. El cockpit reduce el tiempo de búsqueda; no sustituye la revisión.
La máquina de ejecución cambia el resultado
Un agente iniciado en mi Mac se ejecuta en mi Mac, aunque llame a un modelo remoto. Si el equipo entra en reposo, el trabajo local se suspende. Si se apaga, el proceso termina. Una sesión persistente como tmux puede sobrevivir al cierre del cliente, pero no hace trabajar a un ordenador dormido.
Al mover el sistema a un VPS, los repositorios, agentes, pruebas y el servidor de sesiones quedan en una máquina remota que sigue disponible. Mi Mac se convierte en un cliente. Puedo desconectarme y volver más tarde a las mismas sesiones desde otra máquina autorizada.
| Configuración | ¿Dónde se ejecutan los procesos? | ¿Qué ocurre cuando se desconecta el portátil? |
|---|---|---|
| Terminal local | En el portátil | El resultado depende del estado del portátil |
| tmux local | En el portátil | La sesión sobrevive al cliente, no al reposo del equipo |
| Herdr en un VPS | En el VPS | Las sesiones remotas permanecen en el servidor |
Este cambio también exige disciplina: las dependencias deben estar instaladas en el VPS, los secretos deben limitarse a lo necesario y los archivos locales no se sincronizan solos.
Mi flujo con Herdr, Hermes y el VPS
Mantengo una secuencia sencilla:
- Defino dos tareas independientes y sus criterios de aceptación.
- Creo ramas o worktrees separados si los agentes escriben en paralelo.
- Inicio Claude Code y Codex en panes fáciles de identificar.
- Antes de salir, registro la sesión, la rama, la salida actual y las pruebas esperadas.
- Desde el teléfono, pido a Hermes el estado y la última salida útil de cada sesión.
- Si un agente plantea una duda de producto, el bucle se detiene y yo decido.
- Al volver, abro el mismo cockpit, reviso los diffs y ejecuto otra vez las pruebas.
El teléfono no se convierte en un IDE. Telegram y Hermes sirven para consultar estados y tomar decisiones breves. Vuelvo al terminal para leer código, retomar una conversación o corregir una implementación.
Qué demuestra este sistema y qué no
La demostración muestra que un proceso remoto puede continuar después de desconectar el portátil y que puedo recuperar sus sesiones. No demuestra que un agente vaya a ser productivo durante toda la noche.
Un agente puede detenerse porque:
- terminó la tarea;
- una pregunta requiere criterio humano;
- alcanzó una cuota o presupuesto;
- una prueba falla sin una corrección segura;
- el VPS se queda sin RAM, CPU o espacio en disco;
- una dependencia o servicio externo deja de estar disponible.
La disponibilidad de la máquina es solo una condición. La autonomía útil también depende de tareas acotadas, criterios de aceptación, pruebas, permisos mínimos y una regla clara para pedir ayuda.
Los controles que mantengo
No doy acceso ilimitado a un agente remoto solo porque deba trabajar mientras estoy fuera. Separo los worktrees, limito las credenciales, impido merges automáticos en cambios sensibles y mantengo el despliegue bajo aprobación humana.
Antes de dejar una tarea ejecutándose, compruebo:
- el alcance exacto del repositorio y la rama;
- los comandos de prueba esperados;
- las acciones prohibidas, sobre todo merge y despliegue;
- cómo debe informar el agente de un bloqueo;
- el camino de vuelta si el resultado es incorrecto.
La principal ventaja es la continuidad. Vuelvo a los agentes, sus conversaciones y las pruebas que debo revisar sin pedir a una sesión nueva que reconstruya el trabajo.
▶️ Ver la configuración Herdr + Hermes + VPS
Para recibir más flujos prácticos de IA y desarrollo agéntico, únete a The Agentic Dev.