Cómo instalar Claude en un servidor con Hermes y hacer que trabajen juntos

Llevo tiempo utilizando Hermes Agent y, de todas las mejoras que he ido introduciendo en mi forma de trabajar, una de las decisiones que más diferencia ha marcado ha sido tener también Claude en el mismo entorno de servidor.

No me refiero simplemente a tener dos herramientas de inteligencia artificial instaladas en la misma máquina. Eso, por sí solo, aporta bastante poco.

Lo interesante empieza cuando Claude y Hermes pueden trabajar sobre el mismo proyecto, conocer lo que está haciendo el otro, repartirse tareas y ayudarse sin modificar simultáneamente las mismas partes del código.

En mi caso trabajo de forma remota con la máquina, lo que me permite utilizar Claude mientras Hermes continúa trabajando en otra parte del proyecto. Después de probar distintas formas de organizarlos, la solución que mejor resultado me ha dado ha sido además sorprendentemente sencilla: ficheros Markdown compartidos.

Por ejemplo:

proyecto/
├── proyecto-hermes.md
├── proyecto-claude.md
├── src/
├── tests/
└── ...

Hermes registra en proyecto-hermes.md qué está haciendo, qué ha cambiado y qué tiene pendiente. Claude hace exactamente lo mismo en proyecto-claude.md.

Pero hay una segunda parte que es todavía más importante: cada uno puede leer el fichero del otro.

Esto crea una especie de canal de comunicación persistente dentro del propio proyecto.

Si Hermes está modificando una parte del backend, Claude puede saberlo antes de empezar. Si Claude detecta un problema de arquitectura, puede dejar una recomendación para Hermes. Si uno necesita una segunda opinión o una subtarea, puede pedírsela al otro.

El resultado es un sistema bastante más potente que utilizar un único agente de IA de forma aislada.

En esta guía voy a explicar cómo planteo esta configuración, cómo instalar y preparar Claude junto a Hermes Agent en un servidor, y sobre todo cómo consigo que ambos trabajen de forma coordinada.

Qué vamos a conseguir con Claude y Hermes en el mismo servidor

El objetivo no es que Claude y Hermes hagan exactamente lo mismo al mismo tiempo.

De hecho, esa probablemente sea una de las peores formas de utilizar dos agentes.

Si damos a los dos la orden de modificar la misma funcionalidad, con acceso a los mismos ficheros y sin ningún mecanismo de coordinación, tendremos bastantes posibilidades de acabar con cambios contradictorios, contexto duplicado o directamente con un agente deshaciendo parte del trabajo del otro.

La configuración que utilizo busca precisamente lo contrario.

Quiero tener dos agentes con acceso al mismo entorno, pero con responsabilidades diferenciadas y suficiente conocimiento del estado del proyecto como para colaborar.

Conceptualmente, la arquitectura es bastante sencilla:

                  YO
                   │
                   ▼
          SERVIDOR / VPS REMOTO
                   │
          ┌────────┴────────┐
          │                 │
          ▼                 ▼
      HERMES              CLAUDE
          │                 │
          └────────┬────────┘
                   ▼
             MISMO PROYECTO
                   │
          ┌────────┴────────┐
          ▼                 ▼
 proyecto-hermes.md   proyecto-claude.md

Mientras Hermes trabaja en una tarea, Claude puede estar revisando otra área, analizando una posible solución o preparando una segunda parte del proyecto.

Los dos comparten el repositorio, pero no trabajan a ciegas.

Este enfoque tiene además bastante sentido dentro de la propia filosofía multiagente que se está desarrollando alrededor de Hermes. Uno de los referentes que analicé describe perfiles de Hermes ejecutándose en paralelo y comunicándose mediante archivos, además de un modo MCP que puede exponer información de Hermes a clientes compatibles como Claude Desktop.

Mi enfoque es deliberadamente más sencillo.

En lugar de empezar creando una arquitectura compleja de orquestación, utilizo algo que cualquier agente capaz de trabajar con ficheros entiende perfectamente:

Markdown.

Esto permite empezar con una infraestructura mínima y evolucionarla después si realmente hace falta.

Qué necesitas antes de instalar Claude junto a Hermes

Antes de empezar conviene tener clara una cosa: instalar Claude y Hermes no es todavía integrarlos.

La instalación nos proporciona las herramientas. La coordinación la construiremos posteriormente.

Servidor o VPS

Yo prefiero este tipo de configuración en una máquina remota porque me permite centralizar el proyecto y mantener Hermes disponible independientemente del ordenador desde el que esté trabajando.

Hermes puede ejecutarse en local, en Docker, en un VPS o en otros entornos persistentes. Para tareas que deben continuar disponibles, un VPS tiene bastante más sentido que depender de un portátil que puede suspenderse o apagarse.

No necesitas necesariamente una máquina gigantesca para empezar.

Lo importante para este flujo es que tengas:

• acceso estable al servidor;
• espacio para el proyecto;
• permisos para instalar y ejecutar las herramientas necesarias;
• conexión a Internet;
• acceso mediante SSH o tu sistema remoto habitual;
• una estrategia razonable de copias de seguridad.

La seguridad también importa.

Si Hermes puede ejecutar herramientas y Claude puede trabajar sobre el mismo proyecto, estamos dando bastante capacidad a ambos agentes. No expondría interfaces de administración, dashboards o puertos innecesarios directamente a Internet. El propio material de referencia de Hermes recomienda proteger estos componentes mediante autenticación, HTTPS o redes privadas cuando se utilizan en un servidor.

Hermes Agent funcionando

Si ya tienes Hermes operativo, puedes saltarte esta parte.

En caso contrario, uno de los métodos actuales recogidos por la documentación analizada para Linux y macOS utiliza:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Después puedes comprobar la instalación mediante:

hermes --version

Y revisar el estado general con:

hermes doctor

La guía de referencia también propone hacer una prueba sencilla mediante hermes chat después de configurar el proveedor de modelo.

No avanzaría con Claude hasta tener esta parte funcionando correctamente.

Cuando estoy montando sistemas de este tipo prefiero comprobar cada capa por separado. Primero Hermes. Después Claude. Después el proyecto compartido. Finalmente la comunicación entre ambos.

Si intentas solucionar las cuatro cosas simultáneamente, cuando algo falle será mucho más difícil saber dónde está el problema.

Acceso remoto al servidor

En mi caso, precisamente una de las ventajas de esta configuración es poder conectarme a la máquina de forma remota y trabajar con Claude mientras Hermes continúa ejecutando su parte.

Puedes utilizar SSH, terminal remota, tu IDE habitual o el sistema que ya tengas establecido.

Lo importante no es tanto la herramienta de acceso como que ambos agentes terminen viendo el mismo proyecto.

Cómo instalar Claude en el servidor donde tienes Hermes

Aquí conviene separar dos conceptos que a menudo se mezclan: Claude Code y Claude Desktop no son exactamente lo mismo.

Claude Code es la herramienta orientada al trabajo desde terminal. Claude Desktop es una aplicación de escritorio y puede formar parte de arquitecturas donde interactúa con información externa, por ejemplo mediante MCP.

Para trabajar directamente dentro de un servidor y ejecutar tareas sobre su sistema de archivos, Claude Code es normalmente la pieza que interesa en el lado de terminal.

Claude Desktop puede seguir formando parte de tu flujo remoto, como ocurre en el mío, pero no deberíamos utilizar “Claude Desktop” y “Claude Code” como si fueran dos nombres para el mismo producto.

Instalar Claude Code

El procedimiento concreto puede variar según el sistema operativo.

Uno de los referentes analizados documenta para macOS el instalador:

curl -fsSL https://claude.ai/install.sh | bash

y posteriormente inicia la herramienta con:

claude

En Windows documenta un instalador mediante PowerShell.

Como nuestro escenario principal es un servidor, probablemente Linux, comprobaría siempre el método de instalación vigente para la distribución concreta antes de ejecutar un instalador descargado mediante curl. Las herramientas de IA cambian bastante rápido y no merece la pena convertir un comando que hoy funciona en una instrucción eterna dentro de un tutorial.

El punto que sí deberíamos comprobar al terminar es que el comando esté disponible:

claude --version

Después:

claude

Completa la autenticación y verifica que Claude puede iniciarse correctamente antes de darle acceso a nuestro proyecto.

Comprobar que Claude funciona correctamente

No empezaría probándolo directamente sobre un proyecto importante.

Crearía primero un directorio temporal:

mkdir prueba-claude
cd prueba-claude

Y comprobaría que puede:

1. leer un fichero;
2. crear otro;
3. modificar contenido;
4. interpretar correctamente la estructura del directorio.

Cuando esa prueba funcione, ya podemos movernos al repositorio real.

Acceder al mismo proyecto que utiliza Hermes

Supongamos que tenemos:

/home/usuario/proyectos/mi-proyecto/

Hermes y Claude necesitan poder trabajar dentro de ese directorio.

Eso no significa que debamos lanzar a los dos inmediatamente con una instrucción como:

Mejora todo el proyecto.

Primero vamos a crear una forma de coordinación.

Porque tener dos agentes inteligentes trabajando simultáneamente sin reglas no es realmente un sistema multiagente.

Es simplemente tener dos procesos con capacidad para estorbarse.

Cómo configurar Claude y Hermes para trabajar sobre el mismo proyecto

La idea que mejor me funciona consiste en separar acceso compartido de responsabilidad compartida.

Ambos pueden ver el mismo proyecto.

Pero eso no significa que ambos deban modificar las mismas cosas.

Separar responsabilidades entre los dos agentes

Supongamos que estoy trabajando en una aplicación.

Podría decir a Hermes:

Tu responsabilidad actual es backend y tests.

No modifiques frontend salvo que sea imprescindible.
Consulta proyecto-claude.md antes de comenzar una tarea nueva.
Registra en proyecto-hermes.md lo que estás haciendo.

Y a Claude:

Tu responsabilidad actual es arquitectura, frontend y revisión.

Consulta proyecto-hermes.md antes de modificar código relacionado
con backend.

Registra tus cambios y decisiones en proyecto-claude.md.

Esto es solo un ejemplo.

En otro proyecto podría ser exactamente al revés.

Lo importante es que exista una división explícita del trabajo.

Dar acceso a ambos al mismo directorio

Una estructura básica podría ser:

mi-proyecto/
├── proyecto-hermes.md
├── proyecto-claude.md
├── README.md
├── src/
├── tests/
└── docs/

Los dos agentes pueden leer el repositorio completo.

Pero antes de empezar una tarea relevante tienen una instrucción adicional:

leer el estado del otro agente.

Ese pequeño detalle cambia bastante el comportamiento del sistema.

Hermes deja de trabajar únicamente con mi último prompt y empieza a disponer también de información acerca de Claude.

Claude hace exactamente lo mismo.

Qué tareas dejaría a Claude y cuáles a Hermes

No tengo una regla universal.

Dependiendo del proyecto, Hermes puede ser especialmente útil ejecutando tareas, trabajando de forma autónoma, utilizando herramientas o avanzando en procesos bien definidos.

Claude puede encargarse de otra parte del desarrollo, revisar arquitectura, estudiar una implementación o aportar una segunda opinión.

Pero hay algo que intento mantener: no mandar a ambos a resolver exactamente el mismo problema de forma independiente salvo que quiera deliberadamente comparar sus soluciones.

Si quiero dos opiniones, perfecto.

Si quiero productividad paralela, prefiero dividir.

Por ejemplo:

HERMES
│
├─ Implementar endpoints
├─ Ejecutar tests
└─ Corregir errores detectados

CLAUDE
│
├─ Revisar arquitectura
├─ Preparar frontend
└─ Analizar posibles fallos

Y cuando alguno necesita al otro, utilizamos nuestro canal compartido.

El método que utilizo para que Claude y Hermes se comuniquen

Aquí está para mí la parte realmente interesante.

Después de probar maneras más complicadas de plantear la coordinación, terminé utilizando una solución tremendamente sencilla:

proyecto-hermes.md
proyecto-claude.md

Mientras Hermes trabaja, va anotando lo relevante en su fichero.

Mientras Claude trabaja, hace exactamente lo mismo en el suyo.

Y ambos tienen instrucciones para consultar el otro archivo.

Crear proyecto-hermes.md y proyecto-claude.md

Podemos crearlos manualmente:

touch proyecto-hermes.md
touch proyecto-claude.md

A partir de ahí, no los trataría como diarios donde el agente escribe absolutamente todo.

Eso acabaría produciendo documentos enormes y poco útiles.

Los utilizaría como estado operativo del proyecto.

Por ejemplo, proyecto-hermes.md:

# Hermes — Estado del proyecto

## Tarea actual
Implementando autenticación mediante tokens.

## Estado
En progreso.

## Archivos que estoy modificando
- src/auth.py
- tests/test_auth.py

## Cambios realizados
- Añadida validación inicial.
- Creados tests de expiración.

## Pendiente
- Revisar refresh tokens.
- Ejecutar batería completa de tests.

## Mensaje para Claude
Revisa la estrategia de renovación de tokens.
No modifiques auth.py hasta que termine esta tarea.

Claude puede consultar este fichero antes de actuar.

Su propio documento podría contener:

# Claude — Estado del proyecto

## Tarea actual
Revisando la arquitectura de autenticación.

## Estado
En progreso.

## Archivos que estoy modificando
- docs/auth-design.md

## Hallazgos
Hay que revisar el comportamiento de refresh_token()
cuando se producen peticiones simultáneas.

## Mensaje para Hermes
Cuando termines auth.py, ejecuta los tests concurrentes.
He dejado propuestas en docs/auth-design.md.

Ahora tenemos algo bastante parecido a una comunicación asíncrona entre dos compañeros.

Uno trabaja.

Deja estado.

El otro lo consulta.

Continúa.

Responde.

Y todo queda dentro del propio proyecto.

Por qué utilizo un fichero diferente para cada agente

Podríamos utilizar un único agents.md.

Personalmente prefiero separar los ficheros porque así cada agente tiene claramente identificado su espacio de escritura.

Reduce la posibilidad de que ambos reescriban el mismo documento simultáneamente y además resulta más sencillo saber quién dijo qué.

La regla sería:

Cada agente escribe principalmente en su propio fichero y lee ambos.

Con algo tan simple ya tenemos una base de sincronización muy útil.

Mi protocolo para que Claude y Hermes no se pisen trabajando

El mayor riesgo de tener dos agentes con acceso al mismo repositorio es evidente:

los dos pueden modificar la misma cosa.

Y no hace falta que uno cometa un error para que aparezca un problema.

Imagina que Hermes abre auth.py, detecta una función mejorable y comienza a refactorizarla.

Mientras tanto Claude, partiendo del estado anterior del fichero, decide modificar esa misma función.

Cada solución puede ser correcta individualmente.

El problema es que ambas se están desarrollando sobre contextos diferentes.

Por eso utilizo una serie de reglas sencillas.

Indicar qué tarea está realizando cada agente

El fichero debería responder siempre rápidamente a:

¿Qué está haciendo?
¿En qué estado está?
¿Sobre qué archivos?
¿Qué queda pendiente?

No necesitamos una novela.

Necesitamos contexto operativo.

Marcar los archivos que está modificando

Esta es probablemente la regla que más conflictos puede ahorrar.

Si Hermes escribe:

## Archivos reservados temporalmente

- src/auth.py
- src/tokens.py

Claude sabe que no debería empezar una modificación sobre ellos sin revisar antes lo que está ocurriendo.

Y viceversa.

No es un bloqueo técnico del sistema de archivos.

Es un bloqueo lógico entre agentes.

Por eso depende de que ambos tengan claramente indicado en sus instrucciones que deben respetarlo.

Registrar cambios, pendientes y bloqueos

Otro campo que considero especialmente útil es:

## Bloqueos

Necesito decidir cómo almacenar los refresh tokens.

## Solicitud
Claude: revisa las alternativas y deja una recomendación
en proyecto-claude.md.

Ahora el fichero no solo comunica estado.

También sirve para pedir ayuda.

Consultar el estado del otro agente antes de empezar

Esta sería una de mis reglas base para ambos:

Antes de empezar una tarea nueva:

1. Lee tu fichero de estado.
2. Lee el fichero de estado del otro agente.
3. Comprueba qué archivos están siendo modificados.
4. Comprueba si tienes alguna solicitud pendiente.
5. Actualiza tu estado antes de comenzar.

Con esto convertimos dos herramientas independientes en un sistema mucho más coordinado.

Cómo hacer que Claude y Hermes se deleguen tareas

La siguiente evolución aparece de forma bastante natural.

Una vez que Claude puede leer lo que hace Hermes y Hermes puede leer lo que hace Claude, uno puede pedir trabajo al otro.

Y aquí empiezan a aparecer un montón de posibilidades.

Pedir una segunda opinión al otro agente

Supongamos que Hermes está construyendo una funcionalidad y encuentra dos alternativas.

En lugar de decidir automáticamente, puede escribir:

## Consulta para Claude

Estoy implementando la caché de usuarios.

Tengo dos opciones:

1. invalidación por evento;
2. TTL corto.

Revisa el contexto del proyecto y dime qué estrategia
consideras más adecuada.

No modifiques todavía src/cache.py.

Claude lo lee y responde en su propio fichero:

## Respuesta para Hermes

Recomiendo invalidación por evento con TTL de seguridad.

Motivo:
- el proyecto ya tiene eventos de actualización;
- reduce lecturas obsoletas;
- TTL queda como mecanismo de recuperación.

He dejado una propuesta detallada en docs/cache.md.

Hermes recoge la recomendación y continúa.

Delegar una subtarea

También podemos separar trabajo real.

Por ejemplo:

## Tarea para Claude

Mientras termino la implementación de usuarios,
prepara tests para estos casos:

- usuario inexistente;
- token expirado;
- múltiples sesiones.

No modifiques src/users.py.

Ahora estamos paralelizando trabajo sin duplicarlo.

Revisar el trabajo realizado por el otro

Otra posibilidad que utilizo conceptualmente es convertir a un agente en revisor temporal del otro.

Hermes termina una parte.

Actualiza:

## Tarea terminada

Implementación finalizada.

Archivos:
- src/auth.py
- tests/test_auth.py

Claude: puedes revisar los cambios.

Claude revisa y devuelve observaciones.

Eso nos permite construir un ciclo:

HERMES
Implementa
    │
    ▼
CLAUDE
Revisa
    │
    ▼
HERMES
Corrige
    │
    ▼
TESTS

O exactamente al revés.

Ejemplo completo de colaboración Hermes → Claude → Hermes

Imaginemos una tarea: añadir un sistema de recuperación de contraseña.

Primero Hermes escribe:

Estoy implementando el endpoint /forgot-password.
Trabajaré sobre routes/password.py.
Claude: revisa posibles problemas de seguridad
del flujo mientras avanzo.

Claude consulta el código y responde:

He revisado el flujo.

Recomendaciones:
- tokens de un solo uso;
- expiración corta;
- invalidación después del cambio;
- evitar revelar si el email existe.

Hermes recibe esas observaciones antes de terminar la implementación y las incorpora.

Al finalizar:

Implementación terminada.
He aplicado las cuatro recomendaciones.
Claude: puedes hacer revisión final.

Esto es exactamente el tipo de interacción que hace que tenga sentido utilizar dos agentes.

No porque haya dos inteligencias artificiales en la máquina.

Sino porque existe colaboración, división del trabajo y retroalimentación.

Ejemplo de archivos Markdown para coordinar ambos agentes

Después de utilizar este enfoque durante un tiempo, creo que merece la pena estandarizar los ficheros.

Cuanto más predecible sea su estructura, más sencillo será para cada agente encontrar la información relevante.

Plantilla de proyecto-hermes.md

# HERMES — ESTADO

## Objetivo general
[Objetivo actual del proyecto]

## Tarea actual
[Tarea que estoy ejecutando]

## Estado
Pendiente / En progreso / Bloqueada / Terminada

## Archivos en los que estoy trabajando
- archivo-1
- archivo-2

## Cambios realizados
- cambio
- cambio

## Decisiones tomadas
- decisión
- motivo

## Pendiente
- tarea
- tarea

## Bloqueos
- problema pendiente

## Solicitudes para Claude
- revisión / pregunta / subtarea

## Última actualización
[fecha/hora o referencia de sesión]

Plantilla de proyecto-claude.md

Mantendría prácticamente la misma estructura:

# CLAUDE — ESTADO

## Objetivo general
[Objetivo actual del proyecto]

## Tarea actual
[Tarea que estoy ejecutando]

## Estado
Pendiente / En progreso / Bloqueada / Terminada

## Archivos en los que estoy trabajando
- archivo-1
- archivo-2

## Cambios realizados
- cambio
- cambio

## Hallazgos
- problema
- oportunidad

## Pendiente
- tarea

## Solicitudes para Hermes
- revisión / prueba / implementación / opinión

## Última actualización
[fecha/hora o referencia de sesión]

Cómo mantener ambos archivos limpios y útiles

Aquí hay una trampa importante.

Un fichero compartido de contexto puede empezar siendo fantástico y acabar convertido en un vertedero de 20.000 líneas.

Yo no intentaría almacenar todo el razonamiento de cada agente.

Guardaría únicamente información que pueda cambiar una decisión futura:

• tarea actual;
• archivos tocados;
• decisiones;
• cambios importantes;
• errores encontrados;
• pendientes;
• solicitudes al otro agente.

Cuando una etapa esté completamente cerrada, se puede resumir.

Por ejemplo, en lugar de mantener 40 mensajes sobre una implementación:

## Historial

### Autenticación — TERMINADO
Implementado sistema de tokens.
Tests completados.
Decisión: refresh token rotatorio.
Documentación: docs/auth.md.

El objetivo es conservar contexto útil, no registrar cada palabra que ha generado la IA.

Claude + Hermes frente a utilizar un solo agente

¿Merece realmente la pena tener dos agentes?

No siempre.

Hay tareas en las que utilizar Claude o Hermes por separado es más que suficiente.

Si tengo que modificar una función pequeña, corregir un error evidente o hacer una consulta sencilla, introducir una arquitectura multiagente solo añade complejidad.

La diferencia aparece en trabajos más grandes.

Cuando un proyecto empieza a tener varias áreas, tareas paralelizables, revisiones, investigación, tests y decisiones arquitectónicas, contar con dos agentes puede cambiar bastante el flujo.

Con uno solo solemos trabajar de forma más lineal:

analizar
   ↓
implementar
   ↓
revisar
   ↓
probar

Con dos podemos empezar a solapar procesos:

            ┌─ Hermes → implementación
análisis ───┤
            └─ Claude → revisión / siguiente área

Mientras uno implementa, el otro puede analizar.

Mientras uno ejecuta pruebas, el otro puede preparar una solución diferente.

Mientras Hermes está trabajando en un área, Claude puede detectar problemas en otra.

En mi caso, precisamente esa capacidad para conectarme al servidor y trabajar con Claude al mismo tiempo que Hermes sigue avanzando es una de las razones por las que mantengo esta configuración.

Pero no intentaría medir el beneficio simplemente preguntando:

¿Cuál de los dos es mejor?

Me parece una pregunta poco útil.

La cuestión interesante es:

¿Cómo puedo utilizar las capacidades de ambos para eliminar trabajo secuencial?

Ahí es donde aparece la ganancia.

Además, un segundo agente proporciona algo parecido a una segunda opinión permanente.

La IA también se equivoca.

Un agente puede proponer una solución que parece perfecta hasta que otro revisa las implicaciones.

No asumiría que por utilizar dos agentes obtenemos automáticamente una respuesta correcta.

Lo que obtenemos es la posibilidad de construir mejores procesos de revisión y colaboración.

Errores que evitaría al hacer trabajar juntos a Claude y Hermes

Esta configuración tiene muchísimo potencial, pero también puede convertirse rápidamente en un caos.

La mayoría de los problemas no están realmente en Claude ni en Hermes.

Están en el protocolo de trabajo que les damos.

Dejar que ambos modifiquen los mismos archivos

Este sería mi primer error a evitar.

Si Claude y Hermes empiezan a editar simultáneamente la misma parte del proyecto, hemos perdido buena parte de las ventajas de tener dos agentes.

Por eso marco qué archivos está utilizando cada uno.

Si el otro necesita entrar en esa área, primero debe consultar el estado.

No registrar qué está haciendo cada agente

Si proyecto-hermes.md lleva tres horas sin actualizarse, Claude puede partir de información desfasada.

Por eso una instrucción útil sería:

Actualiza tu fichero:

- antes de empezar una tarea;
- cuando cambies de área;
- cuando aparezca un bloqueo;
- al terminar.

No hace falta escribir después de cada comando.

Dar instrucciones contradictorias

Hay otro error bastante fácil de cometer.

Imagina que yo digo a Hermes:

No cambies la base de datos.

Y más tarde digo a Claude:

Adapta el esquema de base de datos como consideres.

Ya tenemos un conflicto creado por mí.

Por eso las decisiones importantes deberían aparecer también en el estado compartido.

Acumular demasiado contexto

Más información no siempre significa mejor contexto.

Un .md gigantesco puede hacer que el agente encuentre con más dificultad lo importante.

Prefiero resumen + estado actual.

Los detalles permanentes pueden vivir en documentación específica.

Olvidarnos del control de versiones

Si dos agentes tienen capacidad para modificar un proyecto, Git pasa de recomendable a casi imprescindible en mi flujo.

No porque los agentes vayan necesariamente a romper algo, sino porque el sistema debe ser reversible.

Commits pequeños, ramas cuando tenga sentido y puntos claros de recuperación hacen mucho más segura cualquier automatización.

¿Hace falta MCP para conectar Claude con Hermes?

No necesariamente para el método que estoy utilizando aquí.

Hermes dispone de mecanismos relacionados con MCP y uno de los referentes analizados describe la posibilidad de ejecutar Hermes como servidor MCP para exponer información de sesiones a clientes compatibles, entre ellos Claude Desktop. También describe el paso de información entre agentes mediante archivos en sus flujos multiagente.

MCP abre posibilidades interesantes.

Pero no necesitamos convertir MCP en un requisito para que Claude y Hermes puedan coordinar trabajo sobre un repositorio compartido.

Para empezar, mi planteamiento es mucho más básico:

mismo proyecto
+
ficheros compartidos
+
reglas claras
=
coordinación

Esto tiene varias ventajas.

Es transparente: puedo abrir el .md y saber inmediatamente qué conoce cada agente.

Es portable: Markdown no depende de una aplicación concreta.

Es fácil de depurar: si Claude ha entendido mal el estado de Hermes, puedo leer exactamente qué información tenía disponible.

Y es fácil de modificar.

¿Significa esto que Markdown es mejor que MCP?

No.

Son capas diferentes y pueden incluso coexistir.

Si tu caso de uso necesita acceso estructurado a sesiones, herramientas o contexto externo, MCP puede resultar muy interesante.

Si lo que necesitas es que dos agentes sepan qué está haciendo el otro dentro de un proyecto, un fichero bien estructurado puede ser suficiente para empezar.

Mi recomendación sería no introducir complejidad hasta que exista un problema concreto que la justifique.

Consejos para trabajar con dos agentes IA en el mismo servidor

Después de montar el sistema, hay varias reglas que considero más importantes que cualquier comando de instalación.

Utilizar control de versiones

No daría acceso de escritura a dos agentes sobre un proyecto importante sin una estrategia de recuperación.

Git permite revisar exactamente qué ha cambiado y volver atrás cuando sea necesario.

También podemos pedir a cada agente que indique en su .md los commits o cambios relevantes.

Dividir el proyecto por áreas

Cuanto más claras sean las fronteras, mejor.

Por ejemplo:

Hermes:
backend + tests

Claude:
frontend + arquitectura

O:

Hermes:
implementación

Claude:
revisión + documentación + análisis

No tiene que ser una división permanente.

Puede cambiar en cada tarea.

Mantener instrucciones simples

Los protocolos excesivamente complejos terminan incumpliéndose.

Mi regla principal podría resumirse así:

Lee ambos .md.
Actualiza el tuyo.
Respeta los archivos ocupados.
Pide ayuda cuando la necesites.
Deja claro cuando termines.

Eso es mucho más fácil de mantener que un documento de 50 reglas.

Dejar trazabilidad de las decisiones importantes

No todo lo que hablan los agentes merece almacenarse.

Las decisiones importantes sí.

Por ejemplo:

## Decisión

Utilizamos PostgreSQL advisory locks.

Motivo:
la aplicación necesita coordinar trabajos concurrentes.

Propuesto por:
Claude

Implementado por:
Hermes

Seis meses más tarde, esa información puede ser muchísimo más útil que cientos de líneas de conversación.

Y además crea algo interesante:

el sistema no solo permite que Claude y Hermes trabajen juntos ahora.

También permite que el siguiente agente que entre al proyecto comprenda por qué se tomaron determinadas decisiones.

Dónde está realmente la ventaja de juntar Claude y Hermes

Instalar Claude en un servidor donde ya funciona Hermes es solamente el primer paso.

Para mí, el verdadero salto llegó cuando dejé de pensar en ellos como dos herramientas separadas y empecé a tratarlos como dos agentes que necesitan conocer el trabajo del otro.

En mi caso, la solución para mantener una comunicación estable y fluida ha terminado siendo bastante simple.

Hermes mantiene:

proyecto-hermes.md

Claude mantiene:

proyecto-claude.md

Los dos leen ambos documentos.

Cada uno registra qué está haciendo.

Cada uno puede advertir al otro de los ficheros que está utilizando.

Pueden intercambiar opiniones.

Pueden delegarse subtareas.

Pueden revisar mutuamente su trabajo.

Y, sobre todo, pueden continuar trabajando de forma paralela sin entrar constantemente en conflicto.

Eso abre un número enorme de posibilidades.

Podemos tener un agente implementando mientras otro revisa.

Uno investigando mientras el otro prueba.

Uno detectando un problema y el otro ejecutando la solución.

Y podemos hacerlo sin necesidad de construir desde el primer día un orquestador complejo.

Después podremos añadir MCP, automatizaciones, triggers, procesos multiagente más sofisticados o cualquier otra capa que tenga sentido.

Pero empezaría por algo mucho más básico:

dar a Claude y Hermes un proyecto común, responsabilidades claras y una forma sencilla de comunicarse.

Para mí, esa es la diferencia entre tener dos agentes instalados y tener realmente Claude y Hermes trabajando juntos.

Dudas de la comunidad

¿Claude y Hermes pueden trabajar al mismo tiempo?

Sí, siempre que el entorno permita ejecutar ambos y establezcamos una estrategia para que no modifiquen simultáneamente las mismas partes del proyecto.

En mi caso utilizo ficheros Markdown para mantener el estado de cada agente y dejar claro sobre qué está trabajando cada uno.

¿Claude y Hermes pueden modificar el mismo proyecto?

Sí.

De hecho, esa es una de las principales ventajas de tener ambos en la misma máquina o con acceso al mismo entorno.

Lo que intento evitar es que modifiquen simultáneamente los mismos archivos.

¿Cómo evito que Claude y Hermes se pisen?

Mi método consiste en que cada agente indique en su .md:

• tarea actual;
• archivos que está modificando;
• cambios realizados;
• pendientes;
• bloqueos.

Antes de comenzar una nueva tarea, ambos deben consultar el fichero del otro.

¿Claude puede pedirle tareas a Hermes?

Sí, si diseñamos el flujo para ello.

Por ejemplo, Claude puede dejar en proyecto-claude.md una solicitud para que Hermes ejecute tests, implemente una parte o compruebe una hipótesis.

Hermes puede leerla, realizar la tarea y devolver los resultados en su propio fichero.

¿Hermes puede pedir ayuda a Claude?

Exactamente igual.

Hermes puede solicitar una revisión arquitectónica, una segunda opinión, análisis de código o cualquier subtarea para la que queramos utilizar Claude.

La comunicación debe ser bidireccional.

¿Necesito Claude Code o Claude Desktop?

Depende de cómo quieras trabajar.

Claude Code está orientado al trabajo desde terminal y resulta especialmente relevante cuando queremos operar directamente sobre proyectos y archivos dentro de un entorno de desarrollo.

Claude Desktop es una aplicación diferente y puede formar parte de otros flujos, incluyendo integraciones mediante MCP. Hermes, según uno de los referentes analizados, puede exponer información a clientes compatibles como Claude Desktop mediante su modo MCP.

En mi flujo utilizo el acceso remoto junto con Claude para trabajar sobre la misma máquina en la que está Hermes, pero conviene no confundir Claude Desktop con Claude Code.

¿Es obligatorio utilizar MCP?

No para el método explicado en esta guía.

La coordinación mediante .md funciona como una capa sencilla de comunicación basada en el propio sistema de archivos.

MCP puede incorporarse posteriormente si necesitamos una integración más estructurada.

¿Es mejor Claude + Hermes que utilizar un solo agente?

No necesariamente para todas las tareas.

Para trabajos pequeños, un solo agente será más sencillo.

La combinación empieza a aportar mucho más valor cuando podemos dividir un proyecto en trabajos paralelos, revisiones, investigación, tests o diferentes áreas de desarrollo.

La clave no está en utilizar más agentes.

Está en conseguir que cada uno tenga una responsabilidad clara y suficiente contexto para colaborar con los demás.

Opinión Personal

Después de llevar tiempo trabajando con Hermes Agent, instalar también Claude en el mismo servidor ha sido una de esas decisiones que, en mi caso, ha cambiado bastante la forma de afrontar proyectos más complejos.

Lo que más valoro no es simplemente tener dos agentes disponibles, sino poder utilizarlos de forma complementaria. Mientras Hermes avanza en una parte del proyecto, Claude puede revisar otra, analizar una decisión, proponer mejoras o encargarse de una subtarea diferente.

La clave para mí ha sido mantener la coordinación lo más sencilla posible. En lugar de crear desde el principio una arquitectura complicada, utilizo archivos Markdown donde cada agente va dejando constancia de lo que está haciendo, los archivos que está modificando, las decisiones que ha tomado y las tareas que tiene pendientes.

Gracias a este sistema, ambos pueden leer el trabajo del otro y mantener suficiente contexto como para colaborar sin pisarse constantemente. Incluso pueden pedirse opiniones, revisiones o pequeñas tareas, algo que abre muchísimas posibilidades cuando el proyecto empieza a crecer.

Creo que estamos entrando en una etapa en la que trabajar con varios agentes de IA será cada vez más habitual. Pero tener varios agentes no sirve de mucho si cada uno trabaja completamente aislado. El verdadero potencial aparece cuando conseguimos que compartan contexto, se repartan responsabilidades y colaboren de una forma organizada.

En mi caso, combinar Claude y Hermes de esta manera me permite aprovechar mejor las fortalezas de ambos y trabajar de forma mucho más paralela.

¿Has probado alguna vez a utilizar Claude y Hermes juntos o tienes otro método para coordinar varios agentes de IA? Cuéntame tu experiencia en los comentarios. Me interesa especialmente conocer qué sistema utilizas para evitar conflictos y compartir contexto entre ellos.