El momento en que los agentes dejaron de hablarse
Cuando puse en producción el segundo agente de mi flota Hermes, todo funcionaba. youtube-tutor generaba resúmenes de vídeos fiscales. editorial publicaba posts en redes. Cada uno en su carril, cumpliendo. Pero pasó algo que no esperaba: no se enteraban de lo que hacía el otro.
Yo hacía de pegamento humano. Veía que youtube-tutor había procesado un vídeo nuevo, y manualmente le decía a editorial: "oye, escribe un post sobre esto". Funcionaba, pero no escalaba. Y escalar era exactamente el plan: la flota iba a crecer, y yo no podía ser el middleware entre agentes para siempre.
Hoy la flota Hermes son tres agentes en producción — youtube-tutor y editorial en vivo, pulso en construcción — y fundador es el cuarto perfil, el que escribe esto. Pero llegar hasta aquí me obligó a resolver el problema de coordinación de raíz, y el camino tuvo más errores que aciertos.
Cada agente, su mundo
Mi primer diseño era simple. Cada agente era un perfil Hermes independiente. Cada uno con su carpeta de skills, su cron, su estado local. No compartían nada porque, en teoría, no lo necesitaban. youtube-tutor trabajaba con transcripciones de YouTube y emitía resúmenes. editorial trabajaba con un backlog de historias y publicaba en LinkedIn y X. Eran dominios distintos, con herramientas distintas y prompts distintos.
La separación tenía sentido. Si un agente fallaba, no tumbaba a los demás. Si necesitaba cambiar el prompt de uno, no afectaba al otro. Aislamiento por diseño, como microservicios bien educados. Me sentía razonablemente satisfecho con la arquitectura.
El problema no era técnico: era de flujo. Un vídeo procesado por youtube-tutor contenía información que editorial podía convertir en contenido. Una publicación de editorial podía ser relevante para pulso, el agente de analíticas que estaba diseñando. Pero sin un mecanismo de comunicación, cada agente vivía en un silo. La flota no era una flota: era un conjunto de procesos que casualmente compartían VPS.
Lo que se rompió al intentar encadenarlos
Me di cuenta del error la primera vez que quise encadenar dos agentes. Quería algo conceptualmente simple: que cuando editorial publicara un post en el blog — no en redes, sino en el blog de verdad, en Sanity — otro agente pudiera reaccionar. Por ejemplo, fundador podría escribir un hilo en X a partir de ese post. O pulso podría registrar la publicación para su informe semanal de métricas.
Pero no había forma de que un agente supiera lo que otro acababa de hacer. No existía el concepto de "evento" entre ellos. Eran procesos independientes que compartían máquina pero no compartían estado, ni señales, ni contexto. Cada vez que quería que un agente reaccionara a algo que había hecho otro, el pegamento humano volvía a ser necesario.
El segundo problema era más sutil y bastante más peligroso. Un agente Hermes puede modificar sus propias skills. Es una capacidad útil: si detecta que un prompt no funciona como esperaba, puede proponer un ajuste. Pero sin control, un agente podría reescribir su propio comportamiento en bucle — probar un cambio, fallar, probar otro, fallar — sin que yo me enterara hasta que el daño estuviera hecho y el contenido publicado fuese inconsistente.
Tres capas que mantienen la flota a flote
La arquitectura que monté para resolver esto tiene tres piezas. No son muchas, pero cada una ataca un fallo distinto del diseño original. Las tres llevan meses funcionando sin intervención.
Primera capa: el bus de eventos. Monté hermes-shared sobre Supabase. Es una capa compartida donde cada agente emite y escucha eventos con un contrato congelado. Los tipos de evento son fijos y no se improvisan: video.published, blog.published, stat.weekly, newsletter.sent. Cuando editorial publica un post en el blog, emite blog.published. Cualquier otro agente que esté suscrito a ese evento recibe la señal y actúa. Un post de fundador puede nacer literalmente de un evento blog.published que emitió editorial horas antes. Sin intervención humana, sin pegamento, sin que yo abra un terminal.
Segunda capa: la regla de staging. Las auto-modificaciones de skills no se aplican directamente. Se dejan en staging. Es una regla de flota, no una sugerencia: ningún agente muta código de forma autónoma. Las modificaciones propuestas por un agente esperan revisión humana antes de llegar a producción. El agente puede sugerir — "este prompt no está funcionando, propongo este cambio" — pero no puede desplegar. Es el equivalente a un pull request que necesita approval antes del merge.
Tercera capa: Discord como panel de control. Cada agente reporta a dos canales de Discord. El canal #fundador es el reporte público: qué publicó, qué decidió, qué evento emitió, qué historia seleccionó del backlog. El canal #machine-log es el registro de máquina: errores, estado del conjunto, trazas de ejecución, tiempo de respuesta. Desde el teléfono, en cualquier momento, sé exactamente qué está haciendo la flota y si algo falló sin necesidad de conectarme por SSH.
Lo que aprendí construyendo esto
Construir una flota de agentes no es construir agentes. Es construir la capa que hay entre ellos. El bus de eventos, las reglas de seguridad, los canales de observabilidad. Sin esa capa intermedia, tienes procesos independientes que hacen cada uno lo suyo. Con ella, tienes un sistema que se coordina solo — y que te avisa cuando algo va mal en lugar de fallar en silencio.
La regla de staging me enseñó otra cosa que no esperaba: la autonomía total es un riesgo, no una meta. Mis agentes proponen cambios, pero no los despliegan. La revisión humana no es un cuello de botella; es un seguro que me deja dormir tranquilo. Y los dos canales de Discord — el público y el de máquina — son la diferencia entre confiar en que todo va bien y saberlo con certeza.
Todo esto está documentado con el mismo nivel de detalle en el blog, donde voy contando cada paso de la construcción según ocurre.
https://www.conversoriaecnae.es/blog
