Sistema de Memoria del Agente Hermes: Cómo Funciona Realmente la Memoria Persistente de la IA

Ya sabes cómo funciona. Abres un chat con un agente de IA, le explicas tu proyecto, compartes tus preferencias, haces que se haga algo y cierras la pestaña. Cuando vuelves la semana siguiente, es como hablar con un desconocido: todo el contexto se ha ido, cada preferencia ha sido olvidada y el proyecto hay que explicarlo desde cero.

Esto no es un error. Es así como funcionan los Modelos de Lenguaje Grande (LLM) por diseño. Son sin estado: cada solicitud es independiente, cada respuesta se genera a partir del prompt que envías en ese momento, sin memoria, sin historial y sin continuidad más allá de los tokens en la ventana de contexto actual.

Para interacciones de un solo turno, eso está bien. Haces una pregunta, obtienes una respuesta y pasas a la siguiente. Pero para los agentes —sistemas que se supone que hacen cosas a través de sesiones, aprenden de sus errores y evolucionan contigo— la falta de estado es un límite arquitectónico difícil de superar. Es uno de los problemas centrales sin resolver en los sistemas de IA autoalojados.

La industria ha intentado resolver esto. LangChain añadió módulos de memoria. OpenAI introdució asistentes con hilos de conversación. Marcos de trabajo como Letta, Zep y Cognee construyeron arquitecturas enteras en torno a la memoria persistente. Databricks publicó sobre “escalado de memoria”, la idea de que el rendimiento del agente mejora con la experiencia acumulada. Desde 2024, han surgido conjuntos de benchmarks dedicados, estudios sobre memoria episódica y un ecosistema de herramientas en rápido crecimiento para abordar lo que cada vez se reconoce más como uno de los problemas centrales sin resolver en la IA agéntica.

La mayoría de estos enfoques comparten un problema común: tratan la memoria como un añadido —una base de datos que consultas, una ventana de contexto que llenas, un sistema de recuperación que añade latencia y ruido en lugar de claridad.

Hermes Agent toma un enfoque fundamentalmente diferente. La memoria no es algo que el agente recupera cuando lo necesita. Es algo que el agente es en todo momento —integrado en el prompt del sistema, curado, acotado y siempre activo. Es lo suficientemente pequeño para ser rápido, lo suficientemente estructurado para ser útil y lo suficientemente disciplinado para saber qué olvidar.

Este artículo explica exactamente cómo funciona.

Parte 1: El problema de la memoria en los agentes de IA

Por qué “simplemente añadir contexto” no escala para los agentes

La solución obvia a la IA sin estado es añadir contexto. Adjuntar la conversación anterior. Incluir la documentación del proyecto. Enviar todo el historial.

Durante un tiempo, eso funciona. Tienes una ventana de contexto de 128K. Puedes meter mucho texto allí.

Pero el contexto no es memoria —hay una diferencia real e importante entre ellos. El contexto es todo lo que se te muestra en este momento; la memoria es lo que conservas activamente y llevas contigo.

El contexto no tiene curación. Es un vertedero: a medida que crece, el modelo tiene que procesar miles de tokens de historial irrelevante para encontrar el único hecho que necesita. Eso cuesta tokens y dinero, aumenta la latencia y eventualmente choca contra el techo.

La memoria está curada. Es la destilación de la experiencia en algo compacto y accionable. No crece indefinidamente —se consolida, actualiza y olvida.

La memoria humana funciona de la misma manera. No recuerdas cada conversación que has tenido. Recuerdas las partes que importan: con quién estás hablando, qué les importa, en qué han acordado, qué han aprendido. El resto se olvida o es consultable cuando lo necesitas.

El panorama de la investigación

El espacio de la memoria de los agentes de IA ha explotado desde 2024, con conjuntos de benchmarks dedicados, una creciente literatura de investigación y una brecha de rendimiento medible entre diferentes enfoques arquitectónicos. Así es como están las cosas.

Letta (anteriormente MemGPT) fue uno de los primeros marcos de trabajo en tratar la memoria persistente como una preocupación de primera clase, alcanzando 21.7K estrellas en GitHub. Utiliza un modelo de tres capas inspirado en los sistemas operativos: memoria central (pequeña, siempre en contexto), memoria de recuperación (historial de conversación consultable) y memoria de archivo (almacenamiento en frío a largo plazo). El insight de que no toda la memoria es igual era correcto. Sin embargo, la implementación requiere que los agentes se ejecuten completamente dentro del runtime de Letta; adoptarlo significa adoptar toda la plataforma, no solo una capa de memoria.

Zep / Graphiti se centra en la memoria conversacional con seguimiento temporal de entidades —los hechos llevan ventanas de validez para que el gráfico sepa cuándo algo era cierto. Es fuerte para chatbots que necesitan gráficos de relaciones, menos adecuado para agentes autónomos que rastrean hechos del entorno y convenciones del proyecto.

Cognee está construido para la extracción de conocimiento de documentos y datos estructurados, con más de 30 conectores de ingestión y un backend de grafo de conocimiento. Destaca en el conocimiento institucional y pipelines de RAG, pero está menos enfocado en la memoria personal del agente. Consulta autoalojamiento de Cognee con LLMs locales para una guía de configuración práctica.

Hindsight realiza recuperación basada en grafos de conocimiento con relaciones de entidades y una herramienta de síntesis reflect única que realiza síntesis cruzada de memoria —combinando múltiples memorias en nuevos insights. Está entre los mejores en benchmarks de memoria de agentes y está disponible como proveedor de memoria para Hermes Agent.

Mem0 maneja la extracción de memoria en el lado del servidor mediante análisis de LLM, requiriendo una configuración mínima. El artículo de investigación de Mem0, publicado en ECAI 2025 (arXiv:2504.19413), comparó diez enfoques distintos de memoria de IA y validó el enfoque de extracción selectiva —almacenando hechos discretos, eliminando duplicados y recuperando solo lo relevante. Mem0 ha crecido hasta aproximadamente 48K estrellas en GitHub y soporta 21 integraciones con frameworks. La compensación es la dependencia de la nube y el costo.

La investigación de escalado de memoria de Databricks introdujo el concepto de que el rendimiento del agente mejora con la experiencia acumulada. Su arquitectura mantiene prompts del sistema, activos empresariales y memorias episódicas/semánticas con alcance a nivel de organización y usuario, validando la idea de que la calidad de la memoria importa tanto como la capacidad del modelo.

El hilo común en la mayoría de los frameworks es que tratan la memoria como un problema de recuperación: almacénala en algún lugar, consúltala cuando sea necesario, inyéctala en el contexto. Hermes hace lo contrario: la memoria no se recupera bajo demanda, se inyecta al inicio de la sesión y está siempre presente. Siempre activa, siempre disponible, lo suficientemente curada para mantenerse útil.

Parte 2: Arquitectura — Dos archivos, un cerebro

El sistema de memoria integrado de Hermes Agent vive en dos archivos.

• ~/.hermes/memories/MEMORY.md — Notas personales del agente (2.200 caracteres, ~800 tokens)
• ~/.hermes/memories/USER.md — Perfil de usuario (1.375 caracteres, ~500 tokens)

Esa es toda la superficie de memoria persistente: dos archivos, menos de 3.600 caracteres en total, menos de 1.300 tokens. Parece deliberadamente pequeño porque lo es —y esa es exactamente la intención del diseño.

MEMORY.md: Las notas del agente

Aquí es donde el agente almacena todo lo que aprende sobre su entorno, el proyecto, las herramientas, las convenciones y las lecciones aprendidas. Así es como se ve:

El proyecto del usuario es un microservicio en Go en ~/code/gateway usando gRPC + PostgreSQL
Esta máquina ejecuta Ubuntu 22.04, tiene Docker y kubectl instalados
El usuario prefiere snake_case para nombres de variables y evita camelCase

Estos no son registros. Son hechos. Densos, declarativos, cargados de información. Sin marcas de tiempo, sin relleno, sin “el 5 de enero el usuario me pidió que…”

USER.md: El perfil del usuario

Aquí es donde el agente almacena todo lo que sabe sobre ti.

El usuario es un desarrollador full-stack cómodo con TypeScript, Go y Python.
El usuario prefiere snake_case para nombres de variables y evita camelCase.
El usuario utiliza principalmente Linux Ubuntu 22.04.
El usuario despliega en AWS usando Terraform.

Identidad, rol, preferencias, habilidades técnicas, estilo de comunicación, pequeñas molestias. El tipo de cosas que hacen que el agente responda diferente a ti que a cualquier otra persona.

El patrón de instantánea congelada

Al inicio de la sesión, ambos archivos se cargan desde el disco y se inyectan como un bloque congelado en el prompt del sistema. Así es como se ve:

══════════════════════════════════════════════
MEMORIA (tus notas personales) [7% — 166/2.200 caracteres]

El proyecto del usuario es un microservicio en Go en ~/code/gateway usando gRPC + PostgreSQL § Esta máquina ejecuta Ubuntu 22.04, tiene Docker y kubectl instalados § El usuario prefiere snake_case para nombres de variables y evita camelCase §

══════════════════════════════════════════════ PERFIL DE USUARIO (quién es el usuario) [8% — 110/1.375 caracteres] ══════════════════════════════════════════════ El usuario es un desarrollador full-stack cómodo con TypeScript, Go y Python. § El usuario prefiere snake_case para nombres de variables y evita camelCase. §

El formato utiliza encabezados, porcentajes de uso, conteos de caracteres y delimitadores `§` (signo de sección). Las entradas pueden ser multilínea. Está diseñado para ser parseable por el modelo mientras permanece legible para humanos.

¿Por qué congelado? [Caché de prefijos](https://www.glukhov.org/es/llm-performance/). El prompt del sistema es el mismo en cada turno de una sesión. Al mantener la memoria estática después del inicio de la sesión, el modelo puede cachear el cálculo del prefijo y solo procesar las partes variables —la conversación. Esta es una optimización de rendimiento significativa. No estás re-computando la atención sobre los mismos tokens de memoria en cada turno.

Los cambios realizados durante una sesión persisten en el disco inmediatamente, pero solo aparecen en el prompt del sistema al inicio de la siguiente sesión. Las respuestas de las herramientas siempre muestran el estado en vivo, pero la "mente" del modelo no cambia en medio de la sesión. Esto evita que el modelo persiga su propia cola —actualizando la memoria y luego reaccionando a su propia actualización en la misma conversación.

### Límites de caracteres como característica

2.200 caracteres. 1.375 caracteres. Estos no son límites arbitrarios. Son restricciones de diseño que fuerzan la curación.

La memoria ilimitada es una desventaja. Fomenta verter todo, nunca consolidar y eventualmente convertirse en ruido. La memoria acotada fuerza al agente a ser selectivo. ¿Qué es realmente importante? ¿Qué necesitaré de nuevo? ¿Qué se puede comprimir sin perder el significado?

Cuando la memoria está llena, el agente no falla en silencio. Obtiene un error con las entradas actuales y el uso, y luego sigue un flujo de trabajo:

1. Leer las entradas actuales de la respuesta de error
2. Identificar entradas eliminables o consolidables
3. Usar `replace` para fusionar entradas relacionadas en versiones más cortas
4. Añadir la nueva entrada

Así es como la memoria se mantiene útil. No es una base de datos. Es una colección curada de hechos que importan.

### Seguridad: Escaneo de inyección de prompts

Cada entrada de memoria se escanea antes de ser aceptada. El sistema bloquea intentos de inyección de prompts, exfiltración de credenciales, puertas traseras SSH y caracteres Unicode invisibles.

La memoria también se deduplica. Las entradas duplicadas exactas se rechazan automáticamente. Esto evita que los adversarios intenten inyectar contenido malicioso a través de envíos repetidos.

---

## Parte 3: Cuando se activa la memoria — Disparadores y decisiones

La pregunta más común sobre la memoria de Hermes Agent es cuándo guarda realmente algo.

La respuesta es: constantemente, pero selectivamente. El agente gestiona su propia memoria a través de la herramienta `memory`, y la decisión de guardar está impulsada por una combinación de señales explícitas y patrones implícitos.

### Disparadores de escritura: ¿Cuándo decide el agente guardar?

El agente guarda la memoria de forma proactiva. No espera a que se lo pidas. Estos son los desencadenantes.

**Correcciones del usuario.** Cuando corriges al agente, esa es una señal para recordar. "No hagas eso de nuevo." "Usa esto en su lugar." "Recuerda esto." Estas son instrucciones explícitas para actualizar la memoria.

Ejemplo: pides al agente que configure un entorno de Python. Sugiere `pip`. Dices "Uso `poetry` para todo". El agente guarda: `El usuario prefiere usar el gestor de paquetes 'poetry' para todos los proyectos de Python.`

**Preferencias descubiertas.** El agente observa patrones e infiere preferencias. Si usas consistentemente una cierta herramienta, marco de trabajo o flujo de trabajo, se guarda.

Ejemplo: después de verte usar `poetry` varias veces en diferentes proyectos, el agente lo guarda como una preferencia.

**Hechos del entorno.** Cosas sobre la máquina, el proyecto, las herramientas instaladas. Estos se descubren a través de la exploración y se guardan como hechos.

Ejemplo: el agente verifica qué está instalado y guarda: `Esta máquina ejecuta Ubuntu 22.04, tiene Docker y kubectl instalados.`

**Convenciones del proyecto.** Cómo está estructurado el proyecto, qué herramientas usa, qué patrones sigue. Estos se descubren mediante la inspección del código y se guardan.

Ejemplo: `El proyecto del usuario es un microservicio en Go en ~/code/gateway usando gRPC + PostgreSQL.`

**Flujos de trabajo complejos completados.** Después de completar una tarea que tomó 5+ llamadas de herramienta, el agente considera guardar el enfoque como una habilidad o al menos anotar qué funcionó.

**Particularidades de las herramientas y soluciones alternativas.** Cuando el agente descubre algo poco obvio sobre una herramienta, API o sistema —una limitación, una solución alternativa, una convención— lo guarda.

**Qué se omite:**

- Información trivial u obvia
- Cosas fácilmente redescubribles
- Volcados de datos sin procesar
- Efímeros específicos de la sesión
- Información ya en archivos de contexto (SOUL.md, AGENTS.md)

### Disparadores de lectura: ¿Cuándo recuerda el agente?

La memoria no se recupera —siempre está ahí. Pero hay diferentes niveles de acceso.

**Inicio de sesión (automático).** MEMORY.md y USER.md se inyectan en el prompt del sistema. El agente los tiene desde el primer token. No se necesita consulta, no hay latencia, no hay llamada de herramienta. Esta es la memoria central —siempre activa.

**`session_search` (bajo demanda).** Cuando el agente necesita encontrar algo de conversaciones pasadas que no está en la memoria central, usa la herramienta `session_search`. Esto consulta SQLite (`~/.hermes/state.db`) con búsqueda de texto completo FTS5 y resumen de Gemini Flash.

Ejemplo: preguntas "¿Discutimos la red de Docker la semana pasada?". El agente busca en el historial de la sesión y devuelve un resumen de la conversación relevante.

**Herramientas de proveedores externos (cuando están configurados).** Cuando un proveedor de memoria externo está activo, el agente tiene herramientas adicionales disponibles: `honcho_search`, `hindsight_recall`, `mem0_search`, etc. Estas se usan cuando el agente determina que se necesita contexto externo.

### El árbol de decisiones

Así es como el agente pondera "¿vale la pena recordar esto?":

¿Es esto una corrección o instrucción explícita? SÍ → Guardar en memoria NO → ¿Es esto una preferencia o patrón? SÍ → Guardar en perfil de usuario NO → ¿Es esto un hecho del entorno o convención? SÍ → Guardar en memoria NO → ¿Es esto fácilmente redescubrible? SÍ → Omitir NO → ¿Es esto específico de la sesión? SÍ → Omitir NO → Guardar en memoria

El agente no se lo piensa demasiado. Guarda de forma proactiva, consolida cuando está lleno y confía en los límites de caracteres para mantener las cosas ajustadas.

---

## Parte 4: Memoria interna vs. Bases de conocimiento externas

Aquí es donde a menudo ocurre la confusión. Hermes Agent tiene *memoria interna* (MEMORY.md, USER.md, proveedores externos) y *bases de conocimiento externas* (LLM Wiki, Obsidian, Notion, ArXiv, sistema de archivos), y cumplen roles completamente diferentes. Esto es similar a la distinción entre [generación aumentada con recuperación](https://www.glukhov.org/es/rag/) pipelines y memoria de trabajo del agente —la recuperación externa es buena para búsquedas de conocimiento profundo, no para llevar identidad y preferencias. La memoria interna es el cerebro del agente —siempre activa, curada, llevada a cada sesión. Las bases de conocimiento externas son su biblioteca —recursos de referencia vastos consultados bajo demanda.

### La distinción

**Memoria interna (el cerebro):**

- Pequeña, persistente, inyectada en el prompt del sistema
- Contiene: preferencias del usuario, convenciones del agente, lecciones inmediatas
- Siempre "en mente" durante la conversación
- Curada, acotada, gestionada activamente
- Ejemplos: MEMORY.md, USER.md, Honcho, Hindsight, Mem0

**Bases de conocimiento externas (la biblioteca):**

- Vastas, solo de referencia, accedidas bajo demanda
- Contiene: documentos, papers, código, notas, bases de datos
- Accedida mediante herramientas cuando sea necesario
- No "recordada" —consultada
- Ejemplos: LLM Wiki, Obsidian, Notion, ArXiv, sistema de archivos, GitHub

### Cómo se relacionan

El agente *accede* a las bases externas mediante herramientas cuando es necesario. No las "recuerda" —las consulta.

**LLM Wiki (llm-wiki):** Base de conocimiento interconectada en Markdown de Karpathy para construir y consultar conocimiento del dominio. El agente usa la habilidad `llm-wiki` para leer, buscar y consultarla. Es un recurso de referencia, no memoria.

**[Obsidian](https://www.glukhov.org/es/knowledge-management/tools/obsidian-for-personal-knowledge-management/):** Bóvedas de notas personales con enlaces bidireccionales. El agente usa la habilidad `obsidian` para leer, buscar y crear notas. Obsidian es parte del ecosistema más amplio de [gestión del conocimiento personal](https://www.glukhov.org/es/knowledge-management/) que Hermes puede aprovechar como recurso de biblioteca.

**Notion/Airtable:** Bases de datos estructuradas y wikis accedidas vía API. El agente las consulta cuando es necesario.

**ArXiv:** Repositorios de papers académicos. El agente busca y extrae papers cuando investiga un tema.

**Sistema de archivos:** Código del proyecto, documentación, configuraciones. El agente lee archivos cuando trabaja en un proyecto.

### El patrón de destilación

Aquí está el insight clave: los insights críticos de las bases externas pueden ser *destilados* en la memoria interna.

Ejemplo: el agente lee un paper de ArXiv sobre escalado de memoria para agentes de IA. No guarda todo el paper en la memoria. Guarda la conclusión clave: `Escalado de memoria: el rendimiento del agente mejora con la experiencia acumulada a través de la interacción del usuario y el contexto empresarial almacenado en la memoria.`

El recurso externo es vasto. La memoria interna es la destilación.

### Cuándo usar cuál

**Memoria interna para:**

- "¿A quién estoy ayudando?"
- "¿Qué prefieren?"
- "¿Qué acabamos de aprender?"
- "¿Cuál es la configuración del proyecto?"
- "¿Qué herramientas están disponibles?"

**Bases de conocimiento externas para:**

- "¿Cuál es la última investigación sobre X?"
- "¿Qué hay en la documentación de mi proyecto?"
- "¿Qué discutimos el mes pasado?"
- "¿Cuál es la API para este servicio?"
- "¿Cuál es la estructura del código?"

El agente entiende la diferencia y usa cada uno apropiadamente —no confunde consultar un documento con recordar algo que ha aprendido sobre ti y tu entorno.

---

## Parte 5: Cómo funciona realmente

Veamos la mecánica.

### La herramienta `memory`

El agente gestiona la memoria a través de una sola herramienta con tres acciones: `add`, `replace`, `remove`.

No hay acción `read` —el contenido de la memoria se inyecta automáticamente en el prompt del sistema. El agente no necesita leerlo porque siempre está ahí.

**`add`** — Añade una nueva entrada.

```python
memory(action="add", target="memory",
       content="El usuario ejecuta macOS 14 Sonoma, usa Homebrew, tiene Docker Desktop instalado.")

replace — Reemplaza una entrada existente usando coincidencia de subcadenas.

memory(action="replace", target="memory",
       old_text="modo oscuro",
       content="El usuario prefiere el modo claro en VS Code, modo oscuro en la terminal")

remove — Elimina una entrada usando coincidencia de subcadenas.

memory(action="remove", target="memory",
       old_text="hecho temporal del proyecto")

Coincidencia de subcadenas

replace y remove usan subcadenas cortas y únicas vía old_text. No necesitas el texto completo de la entrada. Esto hace posibles ediciones quirúrgicas sin conocer el contenido exacto.

Si una subcadena coincide con múltiples entradas, se devuelve un error solicitando una coincidencia más específica. El agente luego refina su consulta.

Almacenes objetivo: memory vs user

El parámetro target determina qué archivo se actualiza.

• memory — Notas personales del agente. Hechos del entorno, convenciones del proyecto, particularidades de las herramientas, lecciones aprendidas.
• user — Perfil de usuario. Identidad, rol, zona horaria, preferencias de comunicación, pequeñas molestias, hábitos de flujo de trabajo.

Gestión de capacidad

Cuando la memoria está >80% llena, el agente consolida. Fusiona entradas relacionadas, elimina hechos desactualizados y comprime información.

Las buenas entradas de memoria son compactas y densas en información:

El usuario ejecuta macOS 14 Sonoma, usa Homebrew, tiene Docker Desktop instalado. Shell: zsh con oh-my-zsh. Editor: Neovim con el plugin Telescope.

Las malas entradas de memoria son vagas o verbosas:

El usuario tiene un proyecto.
El 5 de enero de 2026, el usuario me pidió que mirara su proyecto que está ubicado en ~/code/gateway y usa Go con gRPC y PostgreSQL para la capa de base de datos.

La primera es densa y útil. La segunda es demasiado vaga o demasiado verbosa.

Búsqueda de sesión vs Memoria persistente

session_search y la memoria persistente cumplen funciones diferentes.

Regla general: usa la memoria para hechos críticos que deben estar siempre en contexto. Usa la búsqueda de sesión para consultas históricas.

Parte 6: Proveedores de memoria externos — Comparación de las 8 opciones

Más allá de MEMORY.md y USER.md integrados, Hermes Agent soporta 8 plugins de proveedores de memoria externa para conocimiento persistente y entre sesiones.

Solo un proveedor externo puede estar activo a la vez. Los archivos integrados siempre están activos junto con el proveedor externo —aditivos, no de reemplazo.

Activación

hermes memory setup   # Selector interactivo + configuración
hermes memory status  # Verificar qué está activo
hermes memory off     # Desactivar proveedor externo

O manualmente en ~/.hermes/config.yaml:

memory:
  provider: openviking  # o honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

Comparación de proveedores

Desglose detallado

Honcho

Mejor para: sistemas multi-agente, contexto entre sesiones, alineación usuario-agente.

Honcho funciona junto con la memoria existente —USER.md permanece igual, y Honcho añade una capa adicional de contexto. Modela las conversaciones como pares intercambiando mensajes —un par de usuario más un par de IA por perfil de Hermes, todos compartiendo un espacio de trabajo.

Herramientas: honcho_profile (leer/actualizar tarjeta de par), honcho_search (búsqueda semántica), honcho_context (contexto de sesión —resumen, representación, tarjeta, mensajes), honcho_reasoning (sintetizado por LLM), honcho_conclude (crear/eliminar conclusiones).

Perillas de configuración clave:

• contextCadence (predeterminado 1): Mínimo de turnos entre actualizaciones de la capa base
• dialecticCadence (predeterminado 2): Mínimo de turnos entre llamadas LLM peer.chat() (1-5 recomendado)
• dialecticDepth (predeterminado 1): Pases .chat() por invocación (limitado 1-3)
• recallMode (predeterminado ‘hybrid’): hybrid (auto+herramientas), context (inyectar solo), tools (solo herramientas)
• writeFrequency (predeterminado ‘async’): Timing de vaciado: async, turn, session, o entero N
• observationMode (predeterminado ‘directional’): directional (todo activado) o unified (pool compartido)

Arquitectura: Inyección de contexto de dos capas —capa base (resumen de sesión + representación + tarjeta de par) + suplemento dialéctico (razonamiento LLM). Selecciona automáticamente prompts de arranque en frío vs caliente.

Mapeo multi-par: El espacio de trabajo es un entorno compartido entre perfiles. El par de usuario (peerName) es una identidad humana global. El par de IA (aiPeer) es uno por perfil de Hermes (hermes predeterminado, hermes.<perfil> para otros).

Configuración:

hermes memory setup  # seleccionar "honcho"
# o legado: hermes honcho setup

Config: $HERMES_HOME/honcho.json (local al perfil) o ~/.honcho/config.json (global).

Gestión de perfiles:

hermes profile create coder --clone  # Crea hermes.coder con espacio de trabajo compartido
hermes honcho sync                   # Rellena pares de IA para perfiles existentes

OpenViking

Mejor para: gestión de conocimiento autoalojada con navegación estructurada.

OpenViking proporciona una jerarquía de sistema de archivos con carga escalonada. Es gratis, autoalojado, y te da control total sobre tu almacenamiento de memoria.

Herramientas: viking_search, viking_read (escalado), viking_browse, viking_remember, viking_add_resource.

Configuración:

pip install openviking
openviking-server
hermes memory setup  # seleccionar "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Mejor para: gestión de memoria sin manos con extracción automática.

Mem0 maneja la extracción de memoria en el lado del servidor. No configuras nada —simplemente funciona. Compensación: dependencia de la nube y costo.

Herramientas: mem0_profile, mem0_search, mem0_conclude.

Configuración:

pip install mem0ai
hermes memory setup  # seleccionar "mem0"
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env

Config: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

Mejor para: recuperación basada en grafos de conocimiento con relaciones de entidades.

Hindsight construye un grafo de conocimiento de tu memoria, extrayendo entidades y relaciones. Su herramienta única reflect realiza síntesis cruzada de memoria —combinando múltiples memorias en nuevos insights.

Herramientas: hindsight_retain, hindsight_recall, hindsight_reflect (síntesis cruzada de memoria única).

Configuración:

hermes memory setup  # seleccionar "hindsight"
echo "HINDSIGHT_API_KEY=your-key" >> ~/.hermes/.env

Instala automáticamente hindsight-client (nube) o hindsight-all (local). Requiere >= 0.4.22.

Config: $HERMES_HOME/hindsight/config.json

• mode: cloud o local
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (predeterminado)

UI local: hindsight-embed -p hermes ui start

Holographic

Mejor para: configuraciones centradas en la privacidad con almacenamiento solo local.

Holographic usa álgebra HRR (Representación Reducida Holográfica) para codificación de memoria, con puntuación de confianza para la fiabilidad de la memoria. Sin dependencia de la nube —todo se ejecuta localmente en tu propio hardware.

Herramientas: 2 herramientas para operaciones de memoria vía álgebra HRR.

Configuración:

hermes memory setup  # seleccionar "holographic"

Sin dependencias. Todo se ejecuta localmente.

RetainDB

Mejor para: actualizaciones de alta frecuencia con compresión delta.

RetainDB usa compresión delta para almacenar actualizaciones de memoria de manera eficiente. Es basado en la nube con un costo de $20/mes, pero la compresión significa menos transferencia de datos y actualizaciones más rápidas.

Herramientas: retaindb_profile (perfil de usuario), retaindb_search (búsqueda semántica), retaindb_context (contexto relevante para la tarea), retaindb_remember (almacenar con tipo + importancia), retaindb_forget (eliminar memorias).

Configuración:

hermes memory setup  # seleccionar "retaindb"

ByteRover

Mejor para: entornos con ancho de banda restringido con extracción pre-compresión.

ByteRover comprime la memoria antes de la extracción, reduciendo el uso de ancho de banda. Disponible en modos local o nube.

Herramientas: 3 herramientas para operaciones de memoria.

Configuración:

hermes memory setup  # seleccionar "byterover"

Supermemory

Mejor para: flujos de trabajo empresariales con cercado de contexto e ingestión de grafo de sesión.

Supermemory proporciona cercado de contexto (aislando la memoria por contexto) e ingestión de grafo de sesión (importando historiales completos de conversación). Es basado en la nube y de pago, pero diseñado para gestión de memoria a escala empresarial.

Herramientas: 4 herramientas para operaciones de memoria.

Configuración:

hermes memory setup  # seleccionar "supermemory"

Cómo elegir

• ¿Necesitas soporte multi-agente? Honcho
• ¿Quieres autoalojado y gratis? OpenViking o Holographic
• ¿Quieres configuración cero? Mem0
• ¿Quieres grafos de conocimiento? Hindsight
• ¿Quieres compresión delta? RetainDB
• ¿Quieres eficiencia de ancho de banda? ByteRover
• ¿Quieres características empresariales? Supermemory
• ¿Quieres privacidad (solo local)? Holographic

Para configuraciones de proveedor por perfil completas y patrones de flujo de trabajo del mundo real, consulta configuración de producción de Hermes Agent.

Parte 7: La filosofía

Por qué la memoria acotada supera a la memoria ilimitada

El instinto es hacer la memoria lo más grande posible. Almacenar todo. Recuperar lo que necesitas.

La memoria acotada funciona mejor. Aquí está el porqué.

La curación fuerza la calidad. Cuando tienes espacio limitado, solo guardas lo que importa. Comprimís, consolidáis y priorizáis. La memoria ilimitada fomenta verter todo y nunca limpiar.

La velocidad importa. 1.300 tokens en el prompt del sistema es rápido. 100.000 tokens recuperados de una base de datos es lento. La memoria debe ser instantánea, no una consulta.

El ruido degrada el rendimiento. Más memoria no es mejor memoria. Es memoria más ruidosa. El modelo tiene que distinguir señal de ruido, y eso toma atención —atención que debería gastarse en la tarea real.

Olvidar es una característica. La memoria humana olvida. Eso no es un error —es cómo priorizamos. Los agentes también deberían olvidar. No todo merece ser recordado.

El problema del “olvido”

Los agentes necesitan des-aprender. No solo olvidar, sino activamente eliminar información desactualizada.

Así es como Hermes Agent lo maneja:

• Acción remove: Eliminar entradas que ya no son relevantes.
• Acción replace: Actualizar entradas con nueva información.
• Presión de capacidad: Cuando la memoria está llena, el agente consolida y elimina entradas antiguas.
• Escaneo de seguridad: Bloquea entradas maliciosas o corruptas.

Olvidar no es fracaso —es mantenimiento. Un agente que no puede des-aprender eventualmente cargará tanto ruido como señal.

Escalado de memoria

Databricks introdujo el concepto de “escalado de memoria”: ¿un agente con miles de usuarios rinde mejor que uno con un solo usuario?

Su investigación sugiere que sí, pero con matices. El escalado de memoria requiere:

1. Extracción de calidad: No todas las interacciones valen la pena recordar. El agente debe extraer insights, no registros.
2. Recuperación efectiva: Las memorias recuperadas deben ser relevantes. El ruido degrada el rendimiento.
3. Generalización: Las memorias deben ser patrones, no especificidades. “El usuario prefiere Python” escala. “El usuario ejecutó el comando X en la marca de tiempo Y” no lo hace.

La memoria acotada de Hermes Agent soporta naturalmente el escalado de memoria. Al forzar la curación, asegura que las memorias sean generalizables, compactas y útiles.

Qué significa esto para el futuro

La memoria se está convirtiendo en el foso competitivo en la IA agéntica —no el modelo en sí, sino lo que el modelo lleva entre sesiones. Dos agentes con modelos subyacentes idénticos pueden rendir muy diferente: uno recuerda tus preferencias, tu entorno y tus errores pasados; el otro empieza en frío cada vez.

La pregunta ya no es si los agentes deben tener memoria persistente. Está resuelto: deben. La pregunta abierta es cómo diseñar esa memoria bien —qué mantener, qué desechar, cómo hacerla instantánea y cómo evitar que se convierta en ruido.

La respuesta de Hermes Agent es mantener la memoria pequeña, curada y siempre activa —no una base de datos que consultas, sino un modelo de trabajo del usuario que el agente lleva consigo a cada conversación.

Conclusión

El sistema de memoria de Hermes Agent es deliberadamente simple: dos archivos, límites de caracteres firmes, sin pipeline de recuperación, sin base de datos vectorial y sin latencia por consulta. Lo que suena como una restricción es todo el punto.

Funciona porque trata la memoria como funciona un cerebro en lugar de como funciona una base de datos —pequeña, curada y siempre activa. El agente no recupera la memoria cuando la necesita; la memoria simplemente siempre está ahí, tejida en el prompt del sistema desde el primer token de cada sesión.

Los proveedores de memoria externa extienden este sistema para usuarios que necesitan más: grafos de conocimiento, soporte multi-agente, almacenamiento autoalojado, características empresariales. Pero el núcleo permanece igual: acotado, curado, siempre disponible.

Y las bases de conocimiento externas —LLM Wiki, Obsidian, Notion, ArXiv— cumplen un rol diferente. Son la biblioteca, no el cerebro. El agente las consulta, no las recuerda. Los insights críticos se destilan en la memoria interna; el resto permanece en la biblioteca.

Así es como un agente de IA te recuerda. No almacenando todo, sino recordando lo que importa.

Hermes Agent fue lanzado por Nous Research en febrero de 2026 y alcanzó más de 64.000 estrellas en GitHub en abril de 2026 (v0.9.0), con más de 242 contribuidores. Es de código abierto y está disponible en github.com/NousResearch/hermes-agent. Para instalación, configuración y guías de flujo de trabajo, consulta la visión general de Hermes Agent.