La mayoría de las herramientas de IA que usamos hoy en día son reactivas: esperas a que terminen, cierras la sesión y empiezan de cero la próxima vez. Hermes Agent, el proyecto de código abierto de Nous Research, rompe con esa dinámica. Se ejecuta de forma continua, aprende entre sesiones, crea sus propias habilidades y actúa sobre el sistema de ficheros, la red y decenas de plataformas de mensajería sin que tengas que estar pendiente del teclado.
En esta entrada vamos a ver cómo instalarlo en una máquina virtual de Azure con Ubuntu 24.04 LTS y conectarlo a Azure AI Foundry, usando como cerebro principal el deployment Model-Router, ese despliegue de Foundry que enruta cada petición al modelo más adecuado según el tipo de consulta. No es teoría: lo que leerás a continuación es el proceso real, con los comandos exactos, las decisiones que tomamos y los problemas que nos encontramos por el camino.
Si trabajas con Azure AI Foundry y quieres ir más allá de los chatbots o los copilotos integrados en aplicaciones, esto te da una alternativa autónoma, flexible y completamente bajo tu control dentro del ecosistema Azure.
Qué es Hermes Agent y por qué no es un chatbot
Hermes Agent es un agente autónomo desarrollado por Nous Research. La distinción con un chatbot o un copiloto de IDE no es de marketing: es arquitectónica. Un chatbot responde a una pregunta y termina. Hermes ejecuta un loop cerrado, donde cada sesión alimenta a la siguiente.
Ese loop funciona así: el agente mantiene una memoria curada por él mismo, crea nuevas habilidades a partir de su experiencia, las mejora automáticamente durante el uso y las recupera entre sesiones mediante búsqueda de texto completo con resumen por LLM. Dicho de otro modo, cuanto más tiempo lleva ejecutándose, más capaz se vuelve.
Técnicamente, Hermes no está vinculado a ningún IDE ni depende de que tu portátil esté encendido. Corre en infraestructura propia: un servidor local, Docker, SSH sobre una VM remota o incluso entornos serverless como Modal. Dispone de más de 60 herramientas integradas (búsqueda web, generación de imágenes, síntesis de voz, visión por computadora, navegación) y puede operar simultáneamente en más de 20 plataformas de mensajería: Telegram, Discord, Slack, WhatsApp, Signal, Microsoft Teams, Gmail y otras desde una única puerta de enlace.
Todo esto marca la diferencia cuando lo que necesitas no es «una respuesta» sino un agente que trabaje de forma sostenida sobre una tarea larga o compleja.
Por qué tiene sentido usar Azure AI Foundry como proveedor
Hermes soporta múltiples proveedores de LLM: OpenAI directo, Anthropic, proveedores locales u otros servicios gestionados. La pregunta es cuándo conviene usar Azure Foundry en lugar de ir directamente a OpenAI.
La respuesta tiene varias capas. Primero, el control de costes: si tu organización ya tiene compromisos o PTUs en Azure, el consumo pasa por esa infraestructura y no genera facturas separadas en OpenAI. Segundo, la ubicación de los datos: los modelos servidos en Azure AI Foundry procesan las peticiones dentro de la región Azure que elijas, algo relevante en escenarios con requisitos de residencia de datos. Tercero, el RBAC: la autenticación puede hacerse con Microsoft Entra ID, sin claves de API rotantes, usando identidades gestionadas o roles asignados directamente sobre el recurso Foundry.
En cuarto lugar, la integración con el resto del stack Microsoft: si el agente necesita acceder a otros recursos de Azure (Storage, Key Vault, servicios cognitivos), ya estás dentro del mismo tejido de identidad y red.
Model-Router: un deployment que no es un modelo único
En este despliegue concreto usamos Model-Router, un tipo de deployment disponible en Azure AI Foundry que no apunta a un único modelo sino que enruta dinámicamente cada petición al modelo más adecuado según la naturaleza de la consulta. El sistema analiza la query entrante y decide, en tiempo real, si responde con un modelo de razonamiento, uno de generación rápida, uno especializado en código u otro disponible en el catálogo. El resultado es que no tienes que gestionar manualmente qué modelo usas en cada momento: el enrutador lo hace por ti, optimizando coste y calidad según el tipo de tarea.
Esto lo hace especialmente interesante para un agente como Hermes, que puede recibir tareas muy heterogéneas en la misma sesión.
Prerrequisitos
- Una VM en Azure con Linux. En esta instalación elegimos Ubuntu Server 24.04 LTS – x64 Gen2.
- Acceso SSH a la VM, con posibilidad de usar sudo o directamente como root.
- Un deployment de modelo activo en Azure AI Foundry o Azure OpenAI. En nuestro caso: Model-Router.
- El endpoint OpenAI-style del recurso, con el formato https://<recurso>.openai.azure.com/openai/v1 (no el endpoint del proyecto Foundry; más adelante explicamos la diferencia).
- La API key del recurso Azure OpenAI o Foundry. No la incluyas en artículos, capturas públicas ni repositorios. Si se expone accidentalmente, rótala desde el Portal de Azure.
Paso 1. Selección de la imagen en Azure
La documentación oficial de Hermes indica simplemente «Linux». En Azure eso nos deja libertad, así que elegimos Ubuntu Server 24.04 LTS – x64 Gen2 por ser la distribución más habitual, bien soportada por APT y perfectamente compatible con el instalador del agente.
Figura 1. Selección de imagen en Azure: Ubuntu Server 24.04 LTS – x64 Gen2.
Nota: Si instalas Hermes como root, la configuración quedará en /root/.hermes/. Si usas un usuario normal, se guardará en /home/<usuario>/.hermes/. El resto de la guía asume instalación como root.
Paso 2. Conexión SSH y verificación de Git
Una vez creada la VM, nos conectamos por SSH y elevamos a root. El instalador de Hermes necesita Git para clonar el repositorio, así que comprobamos que está disponible antes de continuar:
sudo su
git –version
La salida confirmó que Git estaba instalado (git version 2.43.0 en Ubuntu 24.04). Si no lo estuviera, un apt install git lo resuelve en segundos.
Paso 3. Instalación con el comando one-line oficial
La documentación oficial ofrece un instalador de una sola línea para Linux, macOS y WSL2. Descarga el script desde GitHub y lo ejecuta con Bash:
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
Figura 2. Comando de instalación one-line indicado por la documentación oficial de Hermes Agent.
El script realiza estas acciones de forma automática, sin intervención manual:
- Detecta el sistema operativo (Linux/Ubuntu).
- Instala uv como gestor rápido de paquetes Python.
- Instala Python 3.11 si no estaba disponible.
- Clona el repositorio de Hermes Agent en /usr/local/lib/hermes-agent.
- Crea el entorno virtual y descarga dependencias.
- Prepara el comando global en /usr/local/bin/hermes.
- Crea la configuración inicial en /root/.hermes/.
Al terminar el script se abre directamente el asistente de configuración. No hace falta lanzarlo por separado.
Paso 4. Setup Wizard: Quick setup
El asistente arranca con varias opciones. Elegimos Quick setup para configurar el proveedor, el modelo y las opciones básicas sin entrar en ajustes avanzados. Suficiente para tener Hermes funcional en pocos minutos.
Paso 5. Elección del proveedor: Azure Foundry
El wizard nos pregunta qué proveedor de LLM vamos a usar. Como el modelo no viene de platform.openai.com sino de nuestro recurso en Azure, elegimos Azure Foundry en lugar de OpenAI directo. La diferencia no es solo de nombre: cada opción configura un endpoint, credenciales y mecanismo de facturación distintos.
Paso 6. Endpoint: OpenAI-style, no el del proyecto Foundry
Aquí está la decisión técnica más importante de toda la instalación. El wizard pide la URL del endpoint, y en Azure existen dos formatos para el mismo recurso Foundry:
- Endpoint OpenAI-style: https://<recurso>.openai.azure.com/openai/v1 — compatible con el formato POST /v1/chat/completions. Es el que usamos.
- Endpoint del proyecto Foundry: https://<recurso>.services.ai.azure.com/api/projects/<proyecto> — orientado a la API de proyectos de Azure AI Foundry. No funcionó con esta configuración de Hermes.
Figura 3. El asistente solicita el API endpoint URL. Usamos el endpoint OpenAI-style de Azure.
Hermes soporta tanto el estilo OpenAI como el estilo Anthropic (para modelos Claude servidos por Foundry, con endpoint .services.ai.azure.com/anthropic). En nuestro caso, al usar Model-Router con modelos GPT y open-weight, el endpoint OpenAI-style es el correcto.
Importante: En el campo endpoint introduce: https://<tu-recurso>.openai.azure.com/openai/v1 Sustituye <tu-recurso> por el nombre de tu recurso Azure OpenAI.
Paso 7. Autenticación: API key
El asistente ofrece dos modos de autenticación. Para esta instalación elegimos API key por su sencillez. La alternativa —Microsoft Entra ID— es la recomendada por la documentación oficial para entornos de producción o corporativos: elimina las claves de larga duración y usa RBAC mediante el rol «Azure AI User» asignado sobre el recurso.
Figura 4. Selección del modo de autenticación: API key o Microsoft Entra ID.
La API key se almacena en ~/.hermes/.env como AZURE_FOUNDRY_API_KEY. No incluyas este archivo en repositorios ni en capturas públicas.
Paso 8. Selección del deployment: escribir Model-Router a mano
El asistente detecta los modelos disponibles en el endpoint y muestra una lista numerada. El deployment que tenemos creado en Azure es Model-Router, pero puede que no aparezca con ese nombre exacto en la lista o que simplemente prefieras introducirlo directamente para evitar confusiones. La opción correcta es escribir el nombre del deployment a mano en lugar de elegir por número:
Pick by number, or type a deployment name:
Model-Router
Figura 5. Hermes detecta modelos disponibles. Escribimos Model-Router directamente en lugar de elegir de la lista.
Atención: El nombre del deployment debe coincidir exactamente con el configurado en Azure, incluyendo mayúsculas y el guión: Model-Router. Un error tipográfico aquí generará errores de conectividad en hermes doctor.
Paso 9. Backend de terminal: mantener local
El asistente pregunta dónde debe ejecutar Hermes los comandos de terminal. Mantenemos la opción local porque queremos que el agente opere directamente sobre la VM de Azure, sin tunelizar la ejecución a ningún entorno externo.
Figura 6. Selección del backend de terminal. Mantenemos «Keep current (local)».
Con esto el wizard finaliza y muestra las rutas de instalación confirmadas:
Config: /root/.hermes/config.yaml
API Keys: /root/.hermes/.env
Data: /root/.hermes/cron/, sessions/, logs/
Code: /usr/local/lib/hermes-agent
Command: /usr/local/bin/hermes
A partir de aquí, el comando hermes ya está disponible en el sistema.
Paso 10. Validación con hermes doctor
Antes de abrir Hermes para una prueba real, ejecutamos el diagnóstico integrado. hermes doctor comprueba el enlace del comando, las dependencias, la configuración del proveedor y la conectividad con el endpoint:
hermes doctor
En nuestro caso el primer diagnóstico señaló dos problemas: el enlace del comando necesitaba corregirse y Azure Foundry reportaba URL None, lo que indicaba que el endpoint no estaba en el lugar exacto que el diagnóstico esperaba. Ejecutamos el arreglo automático primero:
/usr/local/bin/hermes doctor –fix
Después configuramos manualmente el proveedor, el endpoint y el deployment. Esto garantiza que config.yaml tenga los valores correctos independientemente de lo que el wizard hubiera escrito:
hermes config set model.provider azure-foundry
hermes config set model.base_url https://<tu-recurso>.openai.azure.com/openai/v1
hermes config set model.default Model-Router
El detalle del .env: AZURE_FOUNDRY_BASE_URL
Aunque model.base_url quedó guardado en config.yaml, hermes doctor seguía mostrando Azure Foundry con URL None. El motivo: el chequeo de conectividad lee la variable de entorno AZURE_FOUNDRY_BASE_URL desde el archivo .env, no el valor de config.yaml. La solución es añadirla explícitamente:
sed -i ‘/^AZURE_FOUNDRY_BASE_URL=/d’ ~/.hermes/.env
echo ‘AZURE_FOUNDRY_BASE_URL=https://<tu-recurso>.openai.azure.com/openai/v1’ >> ~/.hermes/.env
También verificamos que la API key estaba presente sin exponer su valor:
grep -q ‘^AZURE_FOUNDRY_API_KEY=’ ~/.hermes/.env && echo «AZURE_FOUNDRY_API_KEY existe» || echo «FALTA AZURE_FOUNDRY_API_KEY»
Estado final de hermes doctor
Tras corregir el .env, el diagnóstico mostró Azure Foundry con el estado que buscábamos:
API Connectivity
⚠ OpenRouter API (not configured)
✔ Azure Foundry
El warning de OpenRouter no es un error: no lo configuramos porque nuestro proveedor activo es Azure Foundry. Los avisos sobre Discord, web search, generación de imágenes u otros toolsets son también opcionales: no impiden que Hermes funcione. Se activan más adelante si se necesitan.
Paso 11. Prueba funcional del agente
Con la conectividad validada, abrimos Hermes y enviamos un prompt simple para confirmar que la cadena completa funciona: cliente → Hermes → Azure Foundry → Model-Router → respuesta:
hermes
# Dentro de la interfaz:
Responde exactamente: Hermes conectado a Azure Foundry
Figura 7. Prueba final: Hermes responde usando Model-Router conectado a Azure Foundry.
La respuesta llegó usando Model-Router, lo que confirma que la instalación es correcta y el agente está operativo.
Aclaración: El flag -c en el comando hermes no sirve para enviar prompts directos: se usa para buscar o reanudar sesiones por título. Para iniciar una conversación, lanza hermes sin argumentos y escribe el prompt dentro.
Mejora opcional: instalar ripgrep
Una vez que Hermes funciona, hermes doctor recomienda instalar ripgrep para acelerar las búsquedas de texto en ficheros. No es obligatorio, pero mejora la velocidad de las herramientas de búsqueda del agente. Se instala con APT:
sudo apt update && sudo apt install -y ripgrep
Al volver a ejecutar hermes doctor, el diagnóstico lo muestra como disponible:
✔ ripgrep (rg) (faster file search)
✔ Azure Foundry
Referencia rápida de problemas comunes
Esta tabla recoge los síntomas que nos encontramos durante la instalación y cómo los resolvemos:
| Síntoma | Causa probable | Solución |
| Azure Foundry: URL None | El endpoint no estaba en .env como AZURE_FOUNDRY_BASE_URL. | Añadir AZURE_FOUNDRY_BASE_URL en ~/.hermes/.env con el endpoint OpenAI-style. |
| OpenRouter API not configured | No se configuró OpenRouter. | Ignorar si se usa Azure Foundry como proveedor activo. No bloquea Hermes. |
| No session found con hermes -c | -c busca/reanuda sesiones, no envía prompts. | Abrir hermes sin argumentos y escribir el prompt dentro. |
| ripgrep not found | rg no estaba instalado. | Ejecutar sudo apt update && sudo apt install -y ripgrep |
| Run hermes setup for full tool access | Faltan claves para herramientas opcionales. | Configurar solo las herramientas que se necesiten (web search, Discord, etc.). |
Conclusión
Hermes Agent tiene ya un agente autónomo funcionando sobre infraestructura Azure, con acceso a los modelos de Azure AI Foundry a través de Model-Router. El proceso completo, desde la creación de la VM hasta la validación con hermes doctor, lleva menos de media hora si los prerrequisitos están en orden.
Lo interesante no es solo que funcione, sino que a partir de aquí Hermes empieza a construir memoria y habilidades propias sobre tu entorno. Puedes ampliarlo activando herramientas adicionales (web search, GitHub, mensajería) o configurar autenticación con Microsoft Entra ID para un despliegue más robusto en producción.
Si lo probáis en vuestro entorno y os encontráis con algún comportamiento diferente según la versión de Hermes o el tipo de deployment en Foundry, dejad un comentario. Este tipo de instalaciones evoluciona rápido y la experiencia práctica siempre complementa bien la documentación oficial.
Recursos adicionales
Documentación oficial de Hermes Agent: https://hermes-agent.nousresearch.com/docs/
Guía de integración con Azure Foundry: https://hermes-agent.nousresearch.com/docs/guides/azure-foundry
Guía de instalación: https://hermes-agent.nousresearch.com/docs/getting-started/installation/