Sistema de Memoria Persistente de Hermes Agent: Hacer que la IA Realmente Te Recuerde a Ti y a Tus Proyectos

Después de más de tres meses trabajando con herramientas de IA, casi con certeza habrás chocado contra esta pared: abre una nueva sesión, re-explica todo desde cero. "Este proyecto usa TypeScript, no JavaScript", "Mi puerto SSH es 2222 no 22", "No ejecutes Docker con sudo, estoy en el grupo docker" — las mismas frases, repetidas vaya uno a saber cuántas veces.

Esto no es que el modelo sea tonto. Es un problema de arquitectura. La mayoría de las herramientas de IA tratan "la conversación actual" y "la memoria entre sesiones" como dos cosas separadas — la primera existe, la segunda no, o requiere que la mantengas manualmente.

El sistema de memoria de Hermes Agent fue diseñado desde el principio para conectar estas dos cosas.

Los Dos Archivos del Sistema de Memoria

La memoria persistente de Hermes vive en dos documentos:

Archivo	Propósito	Límite de Capacidad
`MEMORY.md`	Notas personales del agente — hechos del entorno, convenciones del proyecto, información aprendida	2.200 caracteres (~800 tokens)
`USER.md`	Tu perfil de usuario — preferencias, estilo de comunicación, hábitos de trabajo	1.375 caracteres (~500 tokens)

Ambos archivos se almacenan en ~/.hermes/memories/ y se inyectan en el prompt del sistema al inicio de cada sesión — como una "instantánea congelada" que no se actualizará durante la sesión (aunque el agente puede modificar el contenido en disco a mitad de sesión; los cambios tienen efecto en la siguiente sesión).

El diseño de instantánea congelada es intencional: preserva la caché de prefijo del LLM, manteniendo los costos de tokens predecibles — el contexto no cambia con cada turno porque la memoria se actualiza en tiempo real.

Cómo Ve el Agente Su Propia Memoria

Al inicio de la sesión, la memoria aparece en el prompt del sistema en este formato:

══════════════════════════════════════════════
MEMORY (your personal notes) [67% — 1,474/2,200 chars]
══════════════════════════════════════════════
User's project is a Rust web service at ~/code/myapi using Axum + SQLx§
This machine runs Ubuntu 22.04, has Docker and Podman installed§
SSH port is 2222, key at ~/.ssh/staging_ed25519

El agente ve esto y sabe "recuerdo estos hechos, no necesito preguntar al usuario de nuevo." El 67% de uso de capacidad también le indica "casi lleno — consolidar antes de agregar la próxima vez."

Memoria Gestionada por el Agente: La Herramienta `memory`

Los agentes Hermes usan la herramienta memory para operar en la memoria — no porque tú se los recuerdes, sino porque deciden de forma autónoma "esto vale la pena guardar":

add: Agregar una nueva entrada de memoria
replace: Actualizar una entrada de memoria existente (usa coincidencia de subcadena, no se necesita el texto original exacto)
remove: Eliminar memoria que ya no es relevante

# Después de que el agente aprende tu configuración SSH
memory(action="add", target="memory",
       content="SSH port 2222, key at ~/.ssh/staging_ed25519")
 
# Le dices "en realidad cambié al puerto 3000"
memory(action="replace", target="memory",
       old_text="SSH port 2222",
       content="SSH port 3000, key at ~/.ssh/staging_ed25519")

El diseño de coincidencia de subcadena significa que el agente no necesita recordar el texto original completo — solo un fragmento único para ubicar esa entrada de memoria.

Qué Almacenar y Qué No Almacenar

Esta es la clave para que el sistema de memoria entregue valor real — la capacidad es limitada, y cada entrada de memoria consume recursos.

Lo Que el Agente Debería Guardar Proactivamente

Hechos del entorno: "Esta máquina ejecuta macOS 14, Homebrew instalado, Docker Desktop funcionando, shell es zsh + oh-my-zsh" — una entrada cubre mucho conocimiento de fondo que de otro modo podría preguntarse repetidamente.

Convenciones del proyecto: "~/code/api usa Go 1.22, sqlc para consultas DB, chi router, ejecutar pruebas con make test" — el agente no necesitará re-explorar la próxima vez que toque este proyecto.

Comportamientos corregidos: "No ejecutar Docker con sudo, el usuario está en el grupo docker" — no repetir errores pasados; este es uno de los escenarios más valiosos para el sistema de memoria.

Trabajo significativo completado: "Migración de base de datos de MySQL a PostgreSQL el 2026-04-15, scripts de migración en ~/code/api/migrations/" — permite que el agente conozca el estado histórico.

Lo Que No Almacenar

Información demasiado vaga: "El usuario está trabajando en un proyecto" — sin valor accionable, ocupa espacio y no recuerda nada útil.

Hechos fácilmente re-consultables: "Python 3.12 soporta anidamiento de f-strings" — el agente puede encontrar esto con una búsqueda; no vale la pena ocupar capacidad de memoria.

Datos crudos grandes: Archivos de registro, bloques de código grandes — demasiado intensivos en espacio; usa session_search para encontrar conversaciones históricas en su lugar.

Contenido ya en archivos de contexto: Si .hermes.md o AGENTS.md ya contiene documentación del proyecto, no almacenes una copia en MEMORY.md también.

Gestión de Capacidad: Qué Pasa Cuando Está Llena

Cuando la memoria está llena, el agente recibe una respuesta de herramienta como esta:

{
  "success": false,
  "error": "Memory at 2,100/2,200 chars. Adding this entry (250 chars) would exceed the limit.",
  "current_entries": ["..."]
}

El agente debería entonces: leer la memoria existente → encontrar entradas para consolidar o eliminar → reorganizar, luego agregar la nueva entrada.

Cómo se ve una buena entrada de memoria:

# Buena: alta densidad de información, una entrada cubre múltiples hechos
User runs macOS 14, uses Homebrew, Docker Desktop and Podman installed. Shell: zsh with oh-my-zsh. Editor: VS Code with Vim keybindings.

# Buena: específica y accionable
Project ~/code/api uses Go 1.22, sqlc for DB queries, chi router. Run tests with 'make test'. CI via GitHub Actions.

# Mala: demasiado vaga
User has a project they're working on.

# Mala: demasiado verbosa
On April 15th, the user mentioned that they have a project located at ~/code/api. I discovered it uses Go version 1.22 and...

Búsqueda de Sesiones: La Cola Larga Más Allá de la Memoria

El sistema de memoria tiene un límite de capacidad, pero todas tus conversaciones con Hermes se almacenan en ~/.hermes/state.db (SQLite + búsqueda de texto completo FTS5).

La herramienta session_search permite al agente consultar conversaciones históricas:

hermes sessions list   # Explorar sesiones pasadas

Cuando el agente llama internamente a session_search, encuentra conversaciones pasadas relevantes y usa Gemini Flash para resumirlas — permitiéndole responder preguntas como "la semana pasada discutimos ese plan de migración de autenticación, ¿qué decidimos al final?"

Característica	Memoria Persistente	Búsqueda de Sesiones
Capacidad	~1.300 tokens totales	Ilimitada (todas las sesiones)
Velocidad	Instantánea (en prompt del sistema)	Requiere búsqueda + resumen de LLM
Uso	Hechos clave necesarios cada vez	Buscar conversaciones pasadas específicas
Gestión	El agente activamente selecciona	Todo se guarda automáticamente

Los dos son complementarios: la memoria almacena "conocimiento común", la búsqueda de sesiones encuentra "historia".

El Efecto Real del Sistema de Memoria

Después de usar el sistema de memoria, abrir una nueva sesión de Hermes se siente diferente — no "Hola, soy una IA, ¿cómo puedo ayudarte?" sino "Recuerdo que tu proyecto de API usa Go 1.22, chi router, con pruebas ejecutadas via make test."

Esta diferencia se vuelve muy notoria con el uso a largo plazo: tus conversaciones con el agente se sienten cada vez más como hablar con alguien que genuinamente entiende tu entorno de trabajo, en lugar de incorporar a un nuevo empleado a tu sistema cada vez.

La compensación de diseño es: la capacidad es limitada. No puedes meter todo — realmente necesitas desarrollar el criterio de "¿vale esto ocupar espacio de memoria?" — lo cual es consistente con la filosofía general de diseño de Hermes: los agentes deberían tener restricciones y disciplina, no expandirse sin límites.