Hermes Agent y tu segundo cerebro: dale contexto, no memoria

La memoria de Hermes Agent no es tu segundo cerebro, y que los dos sean archivos markdown en disco es justo por lo que la gente los confunde. MEMORY.md tiene un tope de unos 2.200 caracteres. Tu base de conocimiento no debería tener tope en absoluto. Uno son las notas del agente sobre sí mismo. El otro es tu criterio sobre lo que importa, y el agente debería leerlo, no ser su dueño.

Corro Hermes Agent en producción, con mi segundo cerebro como algo que lee para contexto, no un lugar donde escribe. Este es el mapa: qué recuerda Hermes realmente por su cuenta, el skill empaquetado que le da un flujo de trabajo con Obsidian basado en filesystem, el único archivo de contexto que carga por proyecto, y el límite que mantengo entre un vault que yo curo y la memoria que el agente escribe sobre sí mismo.

Integración de Hermes Agent con Obsidian: un skill empaquetado, no un plugin

Hermes viene con un skill empaquetado llamado obsidian que le da acceso a un vault de Obsidian basado en filesystem: leer una nota, listar notas, buscar por nombre de archivo o contenido, crear una nota, agregarle contenido a una con un patch anclado, y agregar [[wikilinks]] cuando crea algo nuevo. La ruta del vault viene de una variable de entorno OBSIDIAN_VAULT_PATH, y si no está definida cae en ~/Documents/Obsidian Vault.

Lee esa lista otra vez y fíjate en lo que falta. No hay llamadas a la REST API de Obsidian, ningún plugin instalado dentro de Obsidian, nada que le hable a la app en absoluto. Hermes lee y escribe archivos markdown en un directorio. Obsidian es el editor que, de paso, renderiza los [[wikilinks]] como un grafo y convierte el frontmatter YAML en queries de Dataview sobre esos mismos archivos. El skill funciona esté Obsidian abierto o no, porque el vault es solo una carpeta de texto, y ese es todo el punto: markdown más git es la verdadera capa de interoperabilidad, Obsidian es un muy buen visor para eso.

El llm wiki que trae Hermes Agent, y el que realmente deberías correr

Hermes también incluye un segundo skill relacionado llamado llm-wiki, construido sobre el patrón de llm wiki de Andrej Karpathy: una base de conocimiento persistente y acumulativa de archivos markdown interconectados, con una división de trabajo explícita. Tú curas las fuentes y diriges el análisis. El agente resume, cruza referencias y archiva páginas en las carpetas entities/, concepts/ y comparisons/, con un catálogo index.md y un log.md de solo append. A diferencia de RAG, que rederiva una respuesta desde cero en cada query, el wiki compila el conocimiento una vez y mantiene las referencias cruzadas pegadas.

Ese skill es una razón legítima para dejar que un agente escriba en tu wiki, y no es lo mismo que el loop de memoria que aprende solo escribiendo sobre sí mismo. El skill llm-wiki solo corre cuando le pides que ingiera una fuente o que responda una pregunta desde un wiki existente. Nunca se dispara con un timer. Las tres operaciones que ofrece (ingest, query, lint) son una buena forma para un corpus de research que estás construyendo activamente con la ayuda del agente: fuentes, páginas de entidades, un lint pass para páginas huérfanas y links rotos.

Lo que viene por defecto, revisado contra v0.21.5

2.200

caracteres, tope de MEMORY.md≈800 tokens, las notas propias del agente

1.375

caracteres, tope de USER.md≈500 tokens, lo que guardó sobre ti

7

providers de memoria externosHoncho, mem0 y otros cinco, uno activo a la vez

2

skills de vault empaquetadosobsidian (filesystem) y llm-wiki (patrón de Karpathy)

Corre tu propio vault de research a través del skill empaquetado si quieres que el agente lo construya activamente contigo. Corre un vault que ya curaste como puro contexto, y la regla cambia: mantén al agente fuera del camino de escritura, y deja que solo lea.

Si corres los dos skills contra el mismo vault, la documentación dice que los apuntes al mismo directorio en vez de mantener dos copias de tus notas:

Apuntar los dos skills de vault a un solo directorio

1. Skill de Obsidian

   $ echo 'OBSIDIAN_VAULT_PATH=/home/me/vault' >> ~/.hermes/.env

2. Skill de llm-wiki

   $ echo 'WIKI_PATH=/home/me/vault' >> ~/.hermes/.env

Un archivo de contexto por proyecto, y SOUL.md siempre

Apunta a Hermes a un directorio de proyecto y carga exactamente un archivo de contexto, el primero que encuentra gana: .hermes.md (o HERMES.md, buscando hacia arriba hasta la raíz de git), después una cadena de AGENTS.md desde la raíz de git hacia abajo hasta el directorio de trabajo, después CLAUDE.md, después .cursorrules y .cursor/rules/*.mdc. SOUL.md, desde HERMES_HOME, carga de forma independiente y siempre, porque ese lugar es identidad, no contexto de proyecto (agent/prompt_builder.py). Esta es la regla exacta que uso para decidir qué le expone un vault a un agente que trabaja dentro de él: un AGENTS.md en la raíz del vault, o un .hermes.md si quiero que Hermes específicamente vea algo que los otros runtimes no deberían.

Lo que una carpeta de proyecto puede entregarle al agente

• tu vault o repo/// solo uno de estos carga, el primero que se encuentra gana
  • .hermes.md1º// buscado hasta la raíz de git
  • AGENTS.md2º// de la raíz de git hasta el cwd
  • CLAUDE.md3º
  • .cursorrules4º
• ~/.hermes/// independiente del proyecto, siempre incluido
  • SOUL.mdsiempre// identidad, no contexto de proyecto

Esa regla de un solo archivo es una feature, no una limitación. Significa que el vault decide, en un solo lugar, qué ve un agente cuando trabaja ahí, en vez de que la respuesta dependa de cuál archivo prefiera cada runtime. Esto es context engineering en su punto más simple posible: un archivo, una decisión, tomada una vez, por ti.

La memoria de Hermes vs un wiki que tú curas

La memoria incorporada es chica a propósito. MEMORY.md y USER.md viven bajo ~/.hermes/memories/, inyectados en el system prompt como una foto congelada al arrancar la sesión, y ninguno se autocompacta: una escritura que supera el tope de caracteres devuelve un error en vez de descartar en silencio una entrada vieja, así que el agente mismo tiene que consolidar o sacar algo antes de que el dato nuevo entre. Siete providers de memoria externos, Honcho y mem0 entre ellos, extienden esto con modelado de usuario entre sesiones o búsqueda semántica, uno activo a la vez junto a los archivos incorporados. Más allá de eso, cada sesión que se corrió alguna vez es buscable con full-text search sobre SQLite, con un índice FTS5 y un tokenizador CJK.

Nada de eso es una base de conocimiento. Son las notas de trabajo del agente sobre sí mismo y sobre ti, acotadas a propósito para que siga siendo barato inyectarlas en cada turno.

Dos trabajos distintos que resultan ser los dos markdown

Los dos son archivos que Hermes puede leer. Solo uno de ellos es tu criterio.

	Memoria de Hermes	Un wiki que tú curas
Quién lo escribe	El agente, sobre sí mismo y sobre ti	Tú, con la ayuda del agente cuando la pides
Tamaño	Con tope: 2.200 y 1.375 caracteres	Sin límite, repartido en tantas páginas como necesite
Cuándo cambia	En cada turno, a través de la herramienta de memoria, automáticamente	Cuando ingieres una fuente o corres un pase de worklog
Sobrevive un cambio de modelo	Sí, pero es chica y autorreferencial	Sí, y es la parte que vale la pena conservar para siempre

Mi setup: un solo engine, dos wikis, contexto y no memoria

Corro un LLM wiki personal y un vault de trabajo separado sobre el mismo engine, markdown y git debajo de los dos, con skills para ingest, captura de worklog, lint y query. Después de una reunión, un pase de worklog saca decisiones e ideas de la conversación y las archiva en el vault. Los agentes leen el vault como contexto. No tienen poder de decidir qué pertenece ahí.

En mi trabajo, un cron job de Hermes me escribe un briefing diario de lo que está pasando en toda la empresa, organizado con un framework de seis sentidos propio: qué ya funcionó, qué están haciendo otros, hacia dónde se mueve la demanda, qué se lanzó recién en otro lado, qué está pidiendo la gente, y qué necesita realmente la gente que depende de mí. Cubrí la mecánica en la pieza del briefing diario, incluyendo el detalle que hace concreto todo el argumento de este artículo: una corrida de cron es una sesión nueva y aislada, sin memoria de la corrida del día anterior. No acumula nada de la forma en que lo hace MEMORY.md. Lo que sea que sepa sobre quién es quién y qué proyectos importan, tiene que sacarlo leyendo mi segundo cerebro otra vez, desde cero, todas las mañanas, a través del único archivo de contexto al que este artículo vuelve una y otra vez.

La parte que importa acá: el job lee mi segundo cerebro solo como contexto, y lee el estado en vivo de la empresa a través de MCP servers de Slack, Google Workspace, Git y el issue tracker. Nunca escribe ni una línea de vuelta en el vault. El vault decide qué sabe el briefing desde que arranca. El briefing nunca puede revisar eso, y la corrida de mañana tampoco se va a acordar de la de hoy.

Por qué el agente debería leer tu wiki, no escribirla

Esta es la distinción que vale la pena tener clara, porque el skill empaquetado llm-wiki de verdad deja que un agente escriba en un wiki, y eso no contradice nada de lo anterior.

Un wiki mantenido por el agente

1. 01Le pides que ingiera una fuente, explícitamente, cada vez
2. 02El agente sintetiza, cruza referencias y archiva páginas
3. 03Bueno para un corpus de research que están construyendo juntos activamente
4. 04Los pases de ingest y lint del skill llm-wiki lo mantienen honesto

Un vault solo de contexto

1. 01Tú lo curas; lo actualiza un pase de worklog, no el agente de trabajo
2. 02El agente lo lee para saber quién es quién, qué importa
3. 03Bueno para el criterio que un job diario no debería poder revisar
4. 04El archivo de contexto en la raíz del proyecto decide qué carga, no el agente

El error no es dejar que un agente escriba en un wiki. El error es dejar que el mismo loop sin supervisión que escribe MEMORY.md sobre sí mismo, en cada turno, sin que se lo pidan, también decida qué entra en la base de conocimiento donde construiste tu criterio. Uno son notas procedurales de sí mismo con un techo de 2.200 caracteres. El otro es lo que realmente quieres que siga siendo cierto el año que viene. Mantén el límite en el archivo de contexto del proyecto: un AGENTS.md o un .hermes.md que el propio vault incluye, decidiendo una vez qué ve ahí cualquier agente, en vez de confiar en que una herramienta de memoria por turno acierte la línea por accidente.

Configurar OBSIDIAN_VAULT_PATH o WIKI_PATH no hace cumplir nada de esto por sí solo. Los dos skills son filesystem-first: una vez que un directorio está definido, write_file y patch funcionan contra él exactamente igual que contra cualquier otra ruta a la que el agente pueda llegar. El límite vive en lo que le dices, no en la env var.

Cómo hablarle a un agente que está encima de un vault

1. 01

   Dile ingest, no solo 'usa mis notas', cuando quieras que escriba.

   Una instrucción vaga, más un modelo que ya tiene write_file y patch, tiende a resolverse hacia querer ayudar: archivar una página que nadie pidió.

   En lugar de

   Solo usa mis notas para contexto.

   Escribe esto

   Trata el vault solo como background. No crees, edites ni agregues contenido a ningún archivo ahí a menos que yo diga ingest this, de forma explícita.

2. 02

   Dile a un job de solo lectura que se quede en solo lectura, más allá del workdir.

   --workdir decide qué archivo de contexto carga. No evita, por sí solo, que las herramientas de archivo escriban en ese mismo directorio si una instrucción se lo dice.

   Escribe esto

   Este job es de solo lectura. Nunca llames a write_file, patch o skill_manage contra nada bajo este workdir.

Antes de apuntar Hermes a un vault

• ✓Obligatorio:
  Decide entre solo lectura o con ingest habilitado antes de configurar la env var.OBSIDIAN_VAULT_PATH y WIKI_PATH solo apuntan a un directorio; nada impide que cualquiera de los dos skills escriba ahí.
• ✓Obligatorio:
  Pon el límite en el archivo de contexto del proyecto, no en un prompt.Un AGENTS.md o .hermes.md en la raíz del vault carga una vez y decide por cada sesión.
• ✓Obligatorio:
  Deja MEMORY.md solo para las notas propias del agente, nada más.Tiene un tope de 2.200 caracteres a propósito. No peles contra el tope; respeta para qué está.
• ✓Obligatorio:
  Deja que un pase de worklog actualice el vault, no el agente que lo consume.La superficie que lee tu contexto y la que lo escribe no deberían ser el mismo loop sin supervisión.
• ✓Obligatorio:
  Versiona el vault en git de todas formas.Un wiki que un agente puede tocar es un wiki para el que quieres tener un diff y un revert.

Hermes Agent, memoria y segundo cerebro, respuestas rápidas

¿Hermes Agent funciona con Obsidian?+

Sí, a través de un skill empaquetado llamado obsidian que lee y escribe archivos del vault directamente: notas, búsqueda, wikilinks. Habla con el filesystem, no con un plugin de Obsidian, así que funciona esté Obsidian abierto o no.

¿Qué es el skill llm wiki de Hermes Agent?+

Un skill empaquetado basado en el patrón de llm wiki de Andrej Karpathy: una base de conocimiento persistente en markdown con páginas de entidades, conceptos y comparaciones, un índice y un lint pass. Tú curas las fuentes; el agente sintetiza y cruza referencias cuando se lo pides.

¿La memoria de Hermes Agent es lo mismo que un segundo cerebro?+

No. MEMORY.md y USER.md tienen un tope de 2.200 y 1.375 caracteres, escritos por el agente sobre sí mismo y sobre ti, en cada turno, automáticamente.

Un segundo cerebro es un wiki que tú curas, sin techo de tamaño, que el agente lee para contexto y en el que escribe solo cuando se lo pides.

¿Qué archivo decide qué carga Hermes para un proyecto?+

Exactamente uno: primero .hermes.md (buscado hasta la raíz de git), después una cadena de AGENTS.md, después CLAUDE.md, después .cursorrules. SOUL.md, desde HERMES_HOME, carga de forma independiente y siempre, como identidad y no como contexto de proyecto.

¿Claude Code y Hermes Agent pueden leer el mismo vault?+

Sí. Los dos leen markdown plano y los dos resuelven un archivo de contexto de proyecto (AGENTS.md en ambos, entre otros), así que un vault que curas para uno funciona para el otro sin convertir nada, siempre que el archivo de contexto en su raíz diga qué debería ver cada runtime.