Primera semana con Hermes Agent: higiene de memoria, skills y aprobaciones de herramientas

El modo de fallo de una instalación nueva de Hermes es predecible: habilitar todos los conjuntos de herramientas, conectar un canal de mensajería con mucha actividad, dejar que la memoria se llene de ruido y después preguntarse por qué el agente «hizo algo raro». La primera semana debe ser aburrida a propósito. Necesitas una pasarela que funcione, una memoria pequeña y revisada, una skill que justifique su presencia, escrituras de archivos limitadas y un terminal desactivado o aislado, con aprobaciones y reglas de denegación probadas.

Esta guía da por hecho que ya sabes qué es Hermes (/articles/hermes-agent-what-it-is). Consulta el inicio rápido y la guía de instalación oficiales para tu sistema operativo. Los comandos y las etiquetas de la interfaz cambian, así que compruébalos en la documentación vigente el mismo día de la instalación.

No conectes el correo electrónico de producción, el acceso de escritura al CRM ni un shell sin restricciones el primer día. Empieza en local o con un perfil desechable y herramientas principalmente de lectura. Desactiva los envíos salientes y el acceso al shell, o aísla el terminal y prueba el comportamiento de sus aprobaciones y reglas de denegación antes de usarlo.

Día 0–1: instalación, doctor y prueba básica

1. Instala Hermes mediante una vía documentada, como la CLI, Docker o Desktop, siguiendo la guía de instalación oficial.
2. Configura un proveedor de modelos que ya utilices o un endpoint local compatible con OpenAI. Actualmente, Hermes requiere al menos 64.000 tokens de contexto para usar agentes con herramientas. Confirma la ventana de contexto y la configuración de llamadas a herramientas en el servidor del modelo; no basta con comprobar que la URL responde (documentación de proveedores).
3. Ejecuta hermes doctor y examina el resultado, en lugar de interpretar la mera existencia del comando como prueba de que todas las integraciones funcionan.
4. Abre una sola sesión de chat CLI. Pide una tarea inofensiva: resumir un README público que controles, o redactar un párrafo. Confirma las llamadas a herramientas que esperas; deshabilita las que no.

Criterios de éxito del primer día: puedes iniciar una sesión, obtener una respuesta del modelo configurado, confirmar al menos 64.000 tokens de contexto utilizable y enumerar las herramientas habilitadas. Comprueba por separado los sockets que escuchan y las direcciones de enlace. Solo puedes afirmar que «nada escucha públicamente» si todas las pasarelas, los servidores API, los webhooks, los paneles y las interfaces del servidor de modelos habilitados están desactivados o enlazados a una interfaz privada o de bucle local prevista.

Conserva un registro breve de la ejecución: método de instalación, endpoint del modelo, conjuntos de herramientas habilitados y si la pasarela es solo local. Cuando algo falle tras una actualización, ese registro te ahorrará horas.

Higiene de memoria: qué pertenece a USER.md y MEMORY.md

La memoria integrada de Hermes es limitada y seleccionada. La documentación de memoria describe USER.md y MEMORY.md dentro de ~/.hermes/memories/. Se inyectan como una instantánea fija al iniciar la sesión y se modifican mediante una herramienta memory que permite añadir, reemplazar y eliminar datos. Asigna a cada agente que se ejecute en paralelo su propio directorio principal o perfil de Hermes; dos procesos de agentes no deben escribir en el mismo directorio. Los proveedores externos opcionales que enumera la documentación de proveedores de memoria complementan la memoria integrada.

Pon en USER.md (identidad y preferencias estables):

• Cómo quieres que se dirijan a ti; idiomas que usas para el trabajo
• Tono por defecto (directo, sin relleno; reglas de mezcla estonio/inglés si procede)
• Herramientas y sistemas que usas por nombre (Linear, Notion, nombre corto de la organización de GitHub)
• Restricciones duras («nunca hagas commit», «nunca envíes correos a clientes», «pregunta antes del shell»)

Pon en MEMORY.md (hechos de trabajo duraderos):

• Notas sobre la estructura del proyecto que sigan siendo válidas durante meses
• Particularidades recurrentes del proceso («la base de datos de staging es de solo lectura desde este host»)
• Definiciones que el agente sigue confundiendo (etiquetas de severidad, nombres de producto)

Mantén fuera de ambos:

• Claves API, tokens, contraseñas, códigos de recuperación
• Tickets completos de clientes, notas de RR. HH., detalles de salud, datos de pago
• Ruido efímero («hoy pruebo la idea X»)
• Transcripciones enteras de chat pegadas como «memoria»

Trata los archivos de memoria como almacenes de datos sujetos a las mismas reglas que una unidad compartida. Si no dejarías el texto en un canal de Slack con contratistas, no permitas que el agente lo conserve. Es preferible guardar referencias, como «consulta la nota Client-A-brief de la bóveda», que pegar el informe en MEMORY.md.

Revisión semanal de memoria (15 minutos)

Cada viernes del primer mes:

1. Abre USER.md y MEMORY.md.
2. Elimina todo lo obsoleto o demasiado específico.
3. Fusiona duplicados.
4. Confirma que no se ha colado ningún secreto por escrituras accidentales de herramientas.
5. Si habilitaste un proveedor externo de memoria, utiliza sus controles documentados de búsqueda, exportación, eliminación y conservación para comprobar si contiene datos de clientes. Si no ofrece controles de eliminación adecuados, no le envíes esos datos.

La calidad de la memoria es una tarea de operaciones. Sáltatela y el agente reutilizará sin dudar hechos obsoletos.

Skills: publica una, no doce

Las skills son memoria procedimental: un directorio con SKILL.md y, de forma opcional, scripts y referencias que se cargan cuando hacen falta. La documentación oficial de skills explica las skills incluidas, las procedentes de un hub y las creadas por el agente. Trata toda skill externa como código e instrucciones que debes revisar, aunque un catálogo o un analizador ya la haya comprobado.

Regla de skill de la primera semana: crea una skill para un trabajo que ya haces semanalmente.

Esquema de ejemplo de skill para «brief semanal de ops»:

# Skill: weekly-ops-brief

## When to use

User asks for the weekly ops brief or Monday status pack.

## Inputs required

- Date range
- Sources allowed (which channels/repos)
- Audience (internal only)

## Steps

1. List incidents and open P0/P1 items from the provided sources only.
2. Separate facts from inferences; mark inferences as [inference].
3. Draft under 400 words: What happened / What’s blocked / Decisions needed.
4. Do not send externally. Output markdown for human copy-paste.

## Stop rules

- If sources are missing, ask once, then produce a partial brief with gaps listed.
- Never invent metrics.

Guárdala en tu directorio de skills de Hermes siguiendo la documentación vigente. Para invocar una skill instalada, utiliza /<skill-name>. El comando /skills sirve para gestionarlas y revisarlas, no es la sintaxis genérica de invocación (referencia de comandos con barra). No habilites el segundo día un catálogo de skills de la comunidad sin revisar.

Las skills de la comunidad pueden instruir al agente a ejecutar comandos de shell o llamar a APIs externas. Lee SKILL.md como leerías un script de shell de internet. Prefiere skills que escribiste tú hasta que tengas un hábito de revisión.

Activa de forma explícita los controles de escritura del proyecto original: skills.write_approval: true para las skills generadas y memory.write_approval: true para los cambios de memoria. Ambos valores son false de forma predeterminada. Compruébalos en la referencia de configuración vigente, prueba una escritura rechazada e inspecciona el estado pendiente de revisión. Las skills generadas automáticamente son borradores hasta que una persona las revisa y acepta.

Límites de herramientas, aprobaciones y aislamiento: el shell al final

Hermes incluye conjuntos amplios de herramientas, entre ellas web, terminal, archivos, navegador y ejecución de código. Configúralas mediante la interfaz documentada hermes tools y la documentación de herramientas.

Postura recomendada de herramientas en la primera semana:

Hermes tiene tres capas de seguridad distintas que no deben confundirse. Las aprobaciones de comandos peligrosos controlan los comandos del terminal marcados mediante approvals.mode; manual solicita aprobación para los comandos marcados, no para todos. approvals.deny bloquea los patrones de comandos configurados incluso si las comprobaciones de aprobación están desactivadas. Las escrituras de archivos mediante write_file y patch utilizan rutas protegidas y el valor opcional HERMES_WRITE_SAFE_ROOT; no presentan una solicitud de aprobación de escritura, y un terminal que se ejecute con el mismo usuario puede eludir esa protección. Tirith es un analizador de contenido independiente que se ejecuta antes de una acción y permite continuar de forma predeterminada si no está disponible. Utiliza Docker, Modal u otro sandbox documentado cuando el agente deba estar aislado del host (documentación de seguridad, documentación de MCP).

Política práctica de aprobación para la primera semana:

• Permitir deliberadamente: inspecciones de solo lectura dentro de un directorio de proyecto designado, después de comprobar qué herramientas y rutas todavía pueden salir de ese ámbito.
• Solicitar aprobación o denegar: comandos del terminal marcados, como eliminaciones destructivas, instalación de paquetes y escrituras remotas. Incluye prohibiciones permanentes, como el push forzado o los patrones que envían datos de una tubería al shell, en approvals.deny; una instrucción en prosa no las impone.
• No permitir nunca sin supervisión: despliegues en producción, envío de correos a clientes y acciones en sistemas de pago o identidad. Elimina esas herramientas y credenciales o aíslalas detrás de un servicio independiente controlado por una persona.

Combínalo con patrones de supervisión humana de /articles/human-in-the-loop-design-patterns y seguridad de conexión de /articles/connecting-ai-safely.

Pasarela de mensajería: espera hasta que la vía CLI sea aburrida

No pongas Hermes en un canal de Slack/Telegram de la empresa hasta que:

1. Los archivos de memoria se hayan revisado una vez.
2. Una skill funcione en CLI.
3. El terminal esté desactivado o aislado y hayas probado sus aprobaciones y reglas de denegación.
4. Hayas probado la lista de usuarios permitidos o el emparejamiento por mensaje directo específico de la plataforma. La pasarela de mensajería rechaza a los usuarios desconocidos de forma predeterminada; además, debes revisar por separado los ámbitos de comandos para administradores y usuarios normales (documentación de mensajería).

Un DM privado contigo mismo es una prueba razonable del día cuatro. Un canal público de equipo es una decisión de la semana dos o posterior.

Copia de seguridad antes de encariñarte

La CLI oficial proporciona hermes backup y hermes import. Una copia de seguridad puede contener .env, material de autenticación, configuración, sesiones y otros estados sensibles, así que protege el archivo como si fuera un almacén de credenciales. Detén la pasarela antes de importar; hermes import sobrescribe archivos en el directorio principal de Hermes de destino. Antes de depender del perfil, prueba una importación en un directorio aislado y desechable, y confirma el estado esperado en lugar de dar por hecho que el archivo puede recuperarse (referencia de la CLI).

Ejercicio: lista de aceptación de la primera semana

Imprime o pega esta lista de comprobación. No amplíes el acceso a herramientas hasta que cada casilla esté marcada.

• Instalación y prueba básica del modelo completadas; al menos 64.000 tokens de contexto confirmados; registro de ejecución guardado
• Interfaces que escuchan y direcciones de enlace inspeccionadas; no se ha encontrado ninguna superficie pública involuntaria
• USER.md tiene solo preferencias y restricciones duras
• MEMORY.md es deliberadamente pequeño (un presupuesto inicial de 20 hechos duraderos es un desencadenante de revisión razonable); sin secretos; sin volcados de PII de clientes
• Existe una skill personalizada y se invocó correctamente dentro del ámbito deliberadamente reducido del ejercicio
• Aprobación de escritura de skills y memoria habilitada, o las escrituras correspondientes desactivadas
• La raíz segura para archivos, el conjunto de herramientas del terminal, approvals.mode, las reglas de denegación y el sandbox se han probado cuando corresponde
• Al menos una acción prohibida del terminal o de archivos se rechazó y se verificó en el disco
• No hay integraciones de envío/escritura de producción conectadas
• Copia de seguridad sensible realizada; pasarela detenida; importación probada una vez en un directorio principal desechable de Hermes
• Mensajería limitada a superficie privada de prueba (o aún solo CLI)

Cómo se ve «hecho» después de siete días

Tras completar la lista, tendrás un perfil de Hermes con memoria revisada, un procedimiento examinado y rutas de denegación probadas localmente para las escrituras en el repositorio y la mensajería. Estos controles reducen el riesgo, pero no demuestran que un agente sea incapaz de aprovechar una configuración incorrecta o realizar una llamada dañina a una herramienta. La autonomía llega más adelante, después de conservar registros operativos, repetir pruebas negativas y comprobar que una segunda skill también supera la revisión. Este artículo documenta el plan de pruebas; esos controles no se ejecutaron durante esta revisión.

Siguiente: ejecuciones impulsadas por eventos vía webhooks (/articles/hermes-webhooks-for-event-driven-agents) y cuándo mantener la fontanería en n8n (/articles/hermes-vs-n8n-choose-by-job).