Sistema de Memoria de Agentes Hermes: Cómo funciona realmente la memoria persistente de la IA

Ya conoces el proceso. Abres un chat con un agente de IA, explicas tu proyecto, compartes tus preferencias, realizas algo de trabajo y cierras la pestaña. Vuelves a la semana siguiente y es como hablar con un extraño: todo el contexto se ha perdido, cada preferencia ha sido olvidada y el proyecto debe explicarse de nuevo desde cero.

Esto no es un error. Es así como funcionan los Grandes Modelos de Lenguaje (LLM) por diseño. Son sin estado (stateless): cada solicitud es independiente, cada respuesta se genera a partir de cualquier instrucción (prompt) que envíes 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. Hacer una pregunta, obtener una respuesta y seguir adelante. Pero para los agentes —sistemas que se supone deben hacer cosas a través de las sesiones, aprender de los errores y evolucionar contigo— la falta de estado es un límite arquitectónico crítico. Es uno de los problemas centrales sin resolver en los sistemas de IA auto-alojados.

La industria ha intentado resolver esto. LangChain añadió módulos de memoria. OpenAI introdujo asistentes con hilos (threads). Marcos de trabajo como Letta, Zep y Cognee construyeron arquitecturas enteras en torno a la memoria persistente. Databricks publicó sobre el “escalado de memoria”, la idea de que el rendimiento del agente mejora con la experiencia acumulada. Desde 2024 han surgido artículos de referencia 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 de agentes.

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

Hermes Agent adopta 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: integrada en el system prompt, curada, acotada y siempre activa. Es lo suficientemente pequeña para ser rápida, lo suficientemente estructurada para ser útil y lo suficientemente disciplinada para saber qué olvidar.

Este artículo explica exactamente cómo funciona eso.

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

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

La solución obvia para 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 ahí.

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

El contexto no tiene curación. Es un volcado: a medida que crece, el modelo tiene que procesar miles de tokens de historial irrelevante para encontrar el único dato que necesita. Eso cuesta tokens y dinero, aumenta la latencia y, eventualmente, alcanza su límite.

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

La memoria humana funciona de la misma manera. No recuerdas cada conversación que has tenido en la vida. Recuerdas las partes que importan: con quién estás hablando, qué le interesa, en qué habéis estado de acuerdo, qué has 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 pruebas (benchmarks) dedicados, una literatura de investigación creciente 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 prioridad de primer nivel, alcanzando las 21,7K estrellas en GitHub. Utiliza un modelo de tres niveles 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). La idea de que no toda la memoria es igual era correcta. Sin embargo, la implementación requiere que los agentes se ejecuten completamente dentro del entorno de ejecución de Letta; adoptarlo significa adoptar toda la plataforma, no solo una capa de memoria.

Zep / Graphiti se centra en la memoria conversacional con seguimiento de entidades temporales: los hechos tienen ventanas de validez para que el grafo sepa cuándo algo era cierto. Es fuerte para chatbots que necesitan grafos de relaciones, pero menos adecuado para agentes autónomos que rastrean hechos del entorno y convenciones de proyectos.

Cognee está diseñado para la extracción de conocimiento a partir de documentos y datos estructurados, con más de 30 conectores de ingesta y un motor de grafos de conocimiento. Destaca en el conocimiento institucional y en los canales de RAG, pero está menos enfocado en la memoria personal del agente. Consulta self-hosting Cognee with local LLMs para obtener una guía de configuración práctica.

Hindsight realiza recuperaciones basadas en grafos de conocimiento con relaciones de entidades y una herramienta de síntesis única llamada reflect que realiza síntesis entre memorias, combinando múltiples memorias en nuevos conocimientos. Está entre los que mejor rinden en los benchmarks de memoria de agentes y está disponible como proveedor de memoria para Hermes Agent.

Mem0 gestiona la extracción de memoria en el lado del servidor mediante el 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), evaluó diez enfoques distintos de memoria de IA y validó el enfoque de extracción selectiva: almacenar hechos discretos, eliminar duplicados y recuperar solo lo que es relevante. Mem0 ha crecido hasta alcanzar aproximadamente las 48K estrellas en GitHub y admite 21 integraciones de marcos de trabajo. La desventaja es la dependencia de la nube y el coste.

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 los system prompts, los activos empresariales y las memorias episódicas/semánticas delimitadas a nivel de organización y de usuario, validando la idea de que la calidad de la memoria importa tanto como la capacidad del modelo.

El hilo conductor en la mayoría de los marcos de trabajo es que tratan la memoria como un problema de recuperación: guardarla en algún lugar, consultarla cuando sea necesario, inyectarla en el contexto. Hermes hace lo contrario: la memoria no se recupera bajo demanda, se inyecta al inicio de la sesión y siempre está presente. Siempre activa, siempre disponible, lo suficientemente curada para seguir siendo útil.

Parte 2: Arquitectura

Lee esta parte de arriba abajo — primero las capas y la recuperación/almacenamiento por turno, luego qué vive en MEMORY.md y USER.md, y finalmente cómo conectar un proveedor externo.

Dos capas

Hermes apila la memoria en dos capas:

1. Integrada (Built-in) — MEMORY.md y USER.md, respaldada por archivos, siempre activa. Límites estrictos de 2.200 caracteres (notas del agente) y 1.375 caracteres (perfil del usuario).
2. Un proveedor externo (opcional) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory y otros que habilites mediante la configuración. Solo un backend externo funciona a la vez. Añade recuperación y retención junto a los archivos; no los sustituye.

El modelo mental es aditivo: archivos centrales congelados más, como máximo, un complemento (plugin). Los ganchos (hooks) de prelectura (prefetch) y sincronización (sync) orquestan la capa externa; los dos archivos permanecen inyectados por separado como parte del system prompt congelado.

Flujo de ejecución (prefetch y sync)

La recuperación ocurre antes de que el modelo responda; la persistencia ocurre después del mensaje del asistente. En el gestor de memoria de Hermes Agent, esto se traduce en prefetch al entrar y sync al salir. Los nombres a continuación coinciden con la interfaz de implementación (MemoryManager, por proveedor prefetch / sync_turn / queue_prefetch).

Mensaje del usuario
    |
    v
MemoryManager.prefetch_all(query)        <-- fase de recuperación
    |
    +-- provider.prefetch(query)        <-- cada proveedor externo busca en su almacén
    |
    v
Contexto inyectado en el turno del LLM
    |
    v
El LLM responde (mensaje del asistente)
    |
    v
MemoryManager.sync_all(user, assistant)  <-- fase de almacenamiento
    |
    +-- provider.sync_turn(user, assistant)
    +-- provider.queue_prefetch(user)    <-- búsqueda en segundo plano para el siguiente turno

Los archivos integrados MEMORY.md y USER.md no se obtienen a través de prefetch_all: ya forman parte del system prompt congelado. Los backends externos se conectan a prefetch_all / sync_all; queue_prefetch permite que un proveedor prepare la recuperación para el siguiente turno sin bloquear la respuesta actual.

Tres caminos hacia la memoria a largo plazo

1. Herramienta memory integrada. El modelo llama a memory con add, replace o remove cuando las instrucciones indican que algo debe persistir: hechos duraderos, preferencias, correcciones, notas del entorno. target='user' mantiene USER.md; target='memory' mantiene MEMORY.md. Ejemplo de forma: memory(action='add', target='user', content='…').

2. Retención pasiva en proveedores externos. En cada turno, el marco de trabajo invoca la ruta de sincronización del proveedor para que la conversación pueda ser fragmentada, resumida o extraída sin que el modelo tenga que nombrar cada hecho. El comportamiento varía según el backend; por ejemplo, Hindsight agrupa turnos y ejecuta una retención estructurada con entidades y relaciones; Honcho envía el diálogo a través de su canal dialéctico; los estilos tipo Mem0 y Supermemory extraen hechos pasivamente de los turnos.

3. Herramientas específicas del proveedor. Cuando el complemento las expone, escrituras explícitas como honcho_conclude, hindsight_retain o honcho_profile almacenan fragmentos duraderos bajo demanda.

Recuperación automática frente a herramientas del proveedor

La memoria central no necesita una herramienta de lectura: ya está en el prompt. Los backends externos añaden ya sea inyección automática desde el prefetch (sin una llamada de herramienta de recuperación separada para ese fragmento de contexto) o herramientas de recuperación explícitas (honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect y similares) cuando el modelo necesita una consulta más precisa que el simple prefetch.

Modos de recuperación (proveedores externos)

Los complementos admiten un modo de recuperación configurable (normalmente recall_mode junto a memory.provider en la configuración) que intercambia tokens por control.

Cuando no hay un proveedor externo configurado (memory.provider vacío o no establecido), solo se aplican los archivos integrados y la búsqueda de la sesión: sin prefetch/sync de un complemento.

Rutas en disco y presupuestos

La memoria integrada 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 del 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ña porque lo es, y ese es exactamente el propósito 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 los nombres de variables y evita camelCase

Estos no son registros (logs). 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 los 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, cosas que le molestan. Lo que hace que el agente te responda de forma diferente a cualquier otra persona.

El patrón de instantánea congelada (Frozen Snapshot)

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

══════════════════════════════════════════════
MEMORY (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 los nombres de variables y evita camelCase
§

══════════════════════════════════════════════
USER PROFILE (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 los nombres de variables y evita camelCase.
§

El formato utiliza encabezados, porcentajes de uso, recuentos de caracteres y delimitadores § (signo de sección). Las entradas pueden ser multilínea. Está diseñado para ser procesable por el modelo y, al mismo tiempo, legible para los humanos.

¿Por qué congelado? Prefix caching. El system prompt 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ómputo del prefijo y solo procesar las partes variables: la conversación. Esta es una optimización de rendimiento significativa. No estás recalculando 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 system prompt 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 a mitad de la sesión. Esto evita que el modelo entre en un bucle infinito: actualizando la memoria y luego reaccionando a su propia actualización en la misma conversación.

Los límites de caracteres como una 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 carga. Fomenta el volcado de todo sin consolidar nada y, eventualmente, se convierte en ruido. Una memoria acotada obliga al agente a ser selectivo. ¿Qué es realmente importante? ¿Qué necesitaré de nuevo? ¿Qué se puede comprimir sin perder el sentido?

Cuando la memoria está llena, el agente no simplemente falla en silencio. Recibe 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 sigue siendo ú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 es escaneada antes de ser aceptada. El sistema bloquea intentos de inyección de prompts, exfiltración de credenciales, puertas traseras de SSH y caracteres Unicode invisibles.

La memoria también se desduplica. Las entradas que son duplicados exactos se rechazan automáticamente. Esto evita que los adversarios intenten inyectar contenido malicioso mediante envíos repetidos.

Proveedores de memoria externos (activación y enlaces)

Más allá de los archivos integrados MEMORY.md y USER.md, Hermes Agent puede conectar un complemento de memoria externo a la vez —Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover o Supermemory— para obtener conocimiento persistente entre sesiones. Solo un proveedor externo está activo a la vez; los dos archivos centrales permanecen cargados junto a él (es aditivo, no de reemplazo).

Activa e inspecciona los proveedores con hermes memory setup, hermes memory status y hermes memory off, o establece memory.provider y recall_mode en ~/.hermes/config.yaml. Los patrones de credenciales varían (por ejemplo, HINDSIGHT_API_KEY, claves de Honcho bajo $HERMES_HOME/honcho.json); usa hermes memory setup para la configuración interactiva.

Forma mínima de YAML solo con funciones integradas:

memory:
  provider: ""
  memory_enabled: true
  user_profile_enabled: true

Ejemplo de activación para un backend (cambia hindsight por honcho, mem0, supermemory u otros que admita tu instalación):

memory:
  provider: "hindsight"

Para la tabla comparativa completa, las notas sobre la dependencia de LLM y embeddings, los desgloses por proveedor y cómo estos backends se relacionan con OpenClaw y otros entornos, consulta Agent memory providers compared.

Para la configuración específica del perfil y los flujos de trabajo de producción, consulta Hermes Agent production setup. El AI Systems Memory hub enumera esta guía junto con artículos relacionados sobre Cognee y capas de conocimiento.

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

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

La respuesta es: constantemente, pero de forma selectiva. 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 tú se lo pidas. Esto es lo que lo activa.

Correcciones del usuario. Cuando corriges al agente, es una señal para recordar. “No hagas eso otra vez”. “Usa esto en su lugar”. “Recuerda esto”. Estas son instrucciones explícitas para actualizar la memoria.

Ejemplo: le 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 utilizas consistentemente una determinada herramienta, marco de trabajo o flujo de trabajo, se guarda.

Ejemplo: tras 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 mediante la exploración y se guardan como hechos.

Ejemplo: el agente comprueba qué hay 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 utiliza, qué patrones sigue. Estos se descubren mediante la inspección de 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. Tras completar una tarea que requuyó más de 5 llamadas a herramientas, 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 no obvio sobre una herramienta, una API o un sistema —una limitación, una solución alternativa, una convención—, lo guarda.

Qué se omite:

• Información trivial u obvia
• Cosas fáciles de volver a descubrir
• Volcados de datos brutos
• Elementos efímeros específicos de la sesión
• Información que ya está en los archivos de contexto (SOUL.md, AGENTS.md)

Disparadores de lectura: ¿Cuándo recupera el agente?

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

Inicio de sesión (automático). MEMORY.md y USER.md se inyectan en el system prompt. El agente los tiene desde el primer token. Sin necesidad de consultas, sin latencia, sin llamadas a herramientas. 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, utiliza la herramienta session_search. Esto consulta SQLite (~/.hermes/state.db) con búsqueda de texto completo FTS5 y resumen mediante Gemini Flash. Usa esto cuando la pregunta suene a “hablamos de esto antes” en lugar de “recuerda este hecho para siempre”.

Ejemplo: preguntas “¿Hablamos de redes 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 marco de trabajo también ejecuta un paso de prefetch automático antes de cada respuesta (ver Parte 2). Herramientas adicionales como honcho_search, hindsight_recall o mem0_search sirven para búsquedas específicas cuando el agente elige una recuperación explícita; dependiendo del recall_mode, pueden estar activas la inyección automática, las herramientas o ambas.

El árbol de decisión

Así es como el agente sopesa si “vale la pena recordar esto”:

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

El agente no se complica demasiado. Guarda de forma proactiva, consolida cuando está lleno y confía en los límites de caracteres para mantener todo compacto.

Parte 4: Memoria interna frente a bases de conocimiento externas

Aquí es donde suele producirse la confusión. Hermes Agent tiene memoria interna (MEMORY.md, USER.md, proveedores externos) y bases de conocimiento externas (Wiki de LLM, Obsidian, Notion, ArXiv, sistema de archivos), y sirven para roles completamente distintos. Esto es similar a la distinción entre los canales de generación aumentada por recuperación y la memoria de trabajo del agente: la recuperación externa es buena para búsquedas de conocimiento profundo, no para mantener la identidad y las 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: vastos recursos de referencia consultados bajo demanda.

La distinción

Memoria interna (el cerebro):

• Pequeña, persistente, inyectada en el system prompt
• 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 para referencia, accedidas bajo demanda
• Contienen: documentos, artículos, código, notas, bases de datos
• Se accede a ellas mediante herramientas cuando es necesario
• No se “recuerdan”, se consultan
• Ejemplos: Wiki de LLM, 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.

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

Obsidian: Almacenes de notas personales con enlaces bidireccionales. El agente utiliza la habilidad obsidian para leer, buscar y crear notas. Obsidian es parte del ecosistema más amplio de gestión de conocimiento personal en el que Hermes puede intervenir como un recurso de biblioteca.

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

ArXiv: Repositorios de artículos académicos. El agente busca y extrae artículos 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á la idea clave: los conocimientos críticos de las bases externas pueden ser destilados en la memoria interna.

Ejemplo: el agente lee un artículo de ArXiv sobre el escalado de memoria para agentes de IA. No guarda el artículo entero 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 con el usuario y el contexto empresarial almacenado en la memoria.

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

Cuándo usar cada una

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?”
• “¿De qué hablamos el mes pasado?”
• “¿Cuál es la API de este servicio?”
• “¿Cómo es la estructura del código?”

El agente entiende la diferencia y utiliza cada una de forma adecuada; no confunde el hecho de consultar un documento con el hecho de 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 mediante una única herramienta con tres acciones: add, replace, remove.

No hay una acción de read (lectura): el contenido de la memoria se inyecta automáticamente en el system prompt. El agente no necesita leerlo porque siempre está ahí.

add — Añade una nueva entrada.

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

replace — Reemplaza una entrada existente mediante la coincidencia de subcadenas.

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

remove — Elimina una entrada mediante la coincidencia de subcadenas.

memory(action="remove", target="memory",
       old_text="temporary project fact")

Coincidencia de subcadenas (Substring Matching)

replace y remove utilizan subcadenas cortas y únicas a través de old_text. No es necesario el texto completo de la entrada. Esto permite ediciones quirúrgicas sin conocer el contenido exacto.

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

Almacenes de destino: memory frente a 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 del usuario. Identidad, rol, zona horaria, preferencias de comunicación, cosas que le molestan, hábitos de flujo de trabajo.

Gestión de la capacidad

Cuando la memoria es >80% de su capacidad, el agente consolida. Fusiona entradas relacionadas, elimina hechos obsoletos y comprime la 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 redundantes:

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

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

Búsqueda de sesión frente a memoria persistente

session_search y la memoria persistente sirven para propósitos diferentes.

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

Parte 6: La filosofía

Por qué la memoria acotada vence a la memoria ilimitada

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

La memoria acotada funciona mejor. He aquí por qué.

La curación obliga a la calidad. Cuando tienes espacio limitado, solo guardas lo que importa. Comprimes, consolidas y priorizas. La memoria ilimitada fomenta el volcado de todo sin limpiar nunca nada.

La velocidad importa. 1.300 tokens en el system prompt 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 significa mejor memoria. Significa una memoria más ruidosa. El modelo tiene que distinguir la señal del ruido, y eso requiere atención; atención que debería dedicarse a 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 desaprender. No solo olvidar, sino eliminar activamente la información obsoleta.

Así es como lo gestiona Hermes Agent:

• Acción remove: Elimina entradas que ya no son relevantes.
• Acción replace: Actualiza 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 un fracaso, es mantenimiento. Un agente que no puede desaprender acabará cargando tanto ruido como señal.

Escalado de memoria

Databricks introdujo el concepto de “escalado de memoria”: ¿funciona mejor un agente con miles de usuarios 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 merecen ser recordadas. El agente debe extraer conocimientos, no registros (logs).
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 el timestamp Y” no escala.

La memoria acotada de Hermes Agent admite de forma natural 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 la ventaja competitiva en la IA de agentes; no es el modelo en sí, sino lo que el modelo lleva de una sesión a otra. Dos agentes con modelos subyacentes idénticos pueden funcionar de forma muy distinta: uno recuerda tus preferencias, tu entorno y tus errores pasados; el otro empieza de cero cada vez.

La pregunta ya no es si los agentes deben tener memoria persistente. Eso está resuelto: deben tenerla. La pregunta abierta es cómo diseñar esa memoria correctamente: qué guardar, qué descartar, cómo hacer que sea 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 a la que consultas, sino un modelo de trabajo del usuario que el agente lleva consigo en cada conversación.

Conclusión

El sistema de memoria de Hermes Agent es deliberadamente simple: dos archivos, límites de caracteres estrictos, sin canal de recuperación, sin vector database y sin latencia por consulta. Lo que parece una restricción es precisamente el objetivo.

Funciona porque trata la memoria de la misma manera que funciona un cerebro, en lugar de como lo hace una base de datos: pequeña, curada y siempre activa. El agente no recupera la memoria cuando la necesita; la memoria simplemente está ahí, integrada en el system prompt desde el primer token de cada sesión.

Los proveedores de memoria externos amplían este sistema para los usuarios que necesitan más: grafos de conocimiento, soporte multi-agente, almacenamiento auto-alojado, funciones empresariales. Pero el núcleo sigue siendo el mismo: acotado, curado, siempre disponible.

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

Así es como un agente de IA te recuerda. No almacenándolo 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 colaboradores. Es de código abierto y está disponible en github.com/NousResearch/hermes-agent. Para guías de instalación, configuración y flujos de trabajo, consulta la Hermes Agent overview.