Comparativa de Agent Memory Providers: Honcho, Mem0, Hindsight y cinco más

Los asistentes modernos siguen olvidándolo todo cuando cierras la pestaña, a menos que algo persista más allá de la ventana de contexto. Los proveedores de memoria de agentes son servicios o librerías que mantienen hechos y resúmenes a través de las sesiones; a menudo se integran como plugins para que el framework se mantenga ligero mientras la memoria escala.

Esta guía compara ocho backends que se distribuyen como plugins de memoria externa de Hermes Agent —Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover y Supermemory— y explica cómo encajan en stacks más amplios de AI systems. Los mismos proveedores aparecen en OpenClaw y otras herramientas de agentes mediante integraciones comunitarias u oficiales. El AI Systems Memory hub incluye este artículo junto con Cognee y guías relacionadas.

Para la memoria central limitada específica de Hermes (MEMORY.md y USER.md), el comportamiento de congelación y los activadores, consulta Hermes Agent Memory System.

Hermes Agent enumera ocho plugins de proveedores de memoria externa para obtener conocimientos persistentes entre sesiones. Solo un proveedor externo puede estar activo a la vez. Los archivos integrados MEMORY.md y USER.md permanecen cargados junto con él: son aditivos, no de reemplazo.

Dependencias externas. Cada proveedor externo, excepto Holographic, requiere al menos una llamada a un servicio externo: un LLM para la extracción de memoria, un modelo de embedding para la búsqueda semántica o una base de datos como PostgreSQL para el almacenamiento. Estas dependencias tienen implicaciones directas en la privacidad, el coste y en si tu stack de memoria puede ejecutarse de forma totalmente self-hosted. Hindsight y ByteRover agrupan o eliminan la mayoría de las dependencias; Honcho, Mem0 y Supermemory requieren la mayor cantidad de elementos móviles. Cuando un proveedor es compatible con Ollama o cualquier endpoint compatible con OpenAI, puedes dirigir las llamadas de LLM y de embedding a un modelo local y mantener los datos completamente fuera de los servidores de terceros.

Activación con Hermes Agent

hermes memory setup   # Interactive picker + configuration
hermes memory status  # Check what's active
hermes memory off     # Disable external provider

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

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

Comparación de Proveedores

Desglose Detallado

Honcho

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

Honcho funciona junto a la memoria existente: USER.md se mantiene tal cual y Honcho añade una capa adicional de contexto. Modela las conversaciones como pares que intercambian mensajes: un par de usuario más un par de IA por cada perfil de Hermes, todos compartiendo un espacio de trabajo.

Dependencias externas: Honcho requiere un LLM para la síntesis de sesiones, la derivación de la representación del usuario y el razonamiento dialéctico; un modelo de embedding para la búsqueda semántica entre observaciones; PostgreSQL con la extensión pgvector para el almacenamiento de vectores; y Redis para el almacenamiento en caché. La nube gestionada en api.honcho.dev gestiona todo esto por ti. Para despliegues auto-hosteados (Docker, K3s o Fly.io), tú proporcionas tus propias credenciales. El espacio para el LLM acepta cualquier endpoint compatible con OpenAI, incluyendo Ollama y vLLM, por lo que la inferencia puede permanecer en las instalaciones locales. El espacio de embedding usa por defecto openai/text-embedding-3-small pero admite proveedores configurables mediante LLM_EMBEDDING_API_KEY y LLM_EMBEDDING_BASE_URL; cualquier servidor de embedding compatible con OpenAI funciona, incluyendo opciones locales como vLLM con un modelo BGE.

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

Ajustes de configuración clave:

• contextCadence (por defecto 1): Turnos mínimos entre actualizaciones de la capa base
• dialecticCadence (por defecto 2): Turnos mínimos entre llamadas al LLM de peer.chat() (se recomienda de 1 a 5)
• dialecticDepth (por defecto 1): Pasadas de .chat() por invocación (limitado de 1 a 3)
• recallMode (por defecto ‘hybrid’): hybrid (auto+herramientas), context (solo inyección), tools (solo herramientas)
• writeFrequency (por defecto ‘async’): Tiempo de vaciado: async, turn, session, o un entero N
• observationMode (por defecto ‘directional’): directional (todo activado) o unified (grupo compartido)

Arquitectura: Inyección de contexto de dos capas — capa base (resumen de sesión + representación + ficha de par) + suplemento dialéctico (razonamiento por LLM). Selecciona automáticamente entre prompts de inicio en frío (cold-start) o en caliente (warm).

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 cada perfil de Hermes (hermes por defecto, hermes.<perfil> para otros).

Configuración:

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

Configuración: $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

Ideal para: gestión de conocimiento auto-hosteada con navegación estructurada.

OpenViking proporciona una jerarquía de sistema de archivos con carga por niveles. Es gratuito, self-hosted y te otorga un control total sobre tu almacenamiento de memoria.

Dependencias externas: OpenViking requiere un VLM (modelo de lenguaje visual) para el procesamiento semántico y la extracción de memoria, y un modelo de embedding para la búsqueda vectorial; ambos son obligatorios. Los proveedores de VLM compatibles incluyen OpenAI, Anthropic, DeepSeek, Gemini, Moonshot y vLLM (para despliegue local). Para los embeddings, los proveedores compatibles incluyen OpenAI, Volcengine (Doubao), Jina, Voyage y —vía Ollama— cualquier modelo de embedding servido localmente. El asistente interactivo openviking-server init puede detectar la RAM disponible y recomendar modelos de Ollama adecuados (por ejemplo, Qwen3-Embedding 8B para embeddings, Gemma 4 27B para VLM) y configurar todo automáticamente para una configuración totalmente local y sin claves de API. No se requiere una base de datos externa; OpenViking almacena la memoria en el sistema de archivos.

Herramientas: viking_search, viking_read (por niveles), viking_browse, viking_remember, viking_add_resource.

Configuración:

pip install openviking
openviking-server init   # interactive wizard (recommends Ollama models for local setup)
openviking-server
hermes memory setup  # select "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Ideal para: gestión de memoria sin intervención manual con extracción automática.

Mem0 gestiona la extracción de memoria en el lado del servidor mediante una llamada al LLM en cada operación add: lee la conversación, extrae hechos discretos, elimina duplicados y los almacena. La API de la nube gestionada se encarga de toda la infraestructura. La librería de código abierto y el servidor auto-hosteado te dan un control total.

Dependencias externas: Mem0 requiere un LLM para la extracción de memoria (por defecto: OpenAI gpt-4.1-nano; se admiten 20 proveedores, incluidos Ollama, vLLM y LM Studio para modelos locales) y un modelo de embedding para la recuperación (por defecto: OpenAI text-embedding-3-small; se admiten 10 proveedores, incluidos Ollama y HuggingFace para modelos locales). El almacenamiento utiliza Qdrant en /tmp/qdrant en modo librería, o PostgreSQL con pgvector en modo servidor auto-hosteado; ambos pueden ejecutarse localmente. Es posible lograr un stack de Mem0 totalmente local y sin nube: Ollama para el LLM, Ollama para los embeddings y una instancia local de Qdrant, todo configurado mediante Memory.from_config.

Herramientas: mem0_profile, mem0_search, mem0_conclude.

Configuración:

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

Configuración: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

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

Hindsight construye un grafo de conocimiento de tu memoria, extrayendo entidades y relaciones. Su herramienta única reflect realiza una síntesis entre memorias, combinando múltiples recuerdos para obtener nuevos conocimientos. La recuperación ejecuta cuatro estrategias de búsqueda en paralelo (semántica, palabras clave/BM25, recorrido de grafos, temporal), luego fusiona y reordena los resultados utilizando reciprocal rank fusion.

Dependencias externas: Hindsight requiere un LLM para la extracción de hechos y entidades en las llamadas retain, y para la síntesis en las llamadas reflect (por defecto: OpenAI; los proveedores admitidos incluyen Anthropic, Gemini, Groq, Ollama, LM Studio y cualquier endpoint compatible con OpenAI). El modelo de embedding y el modelo de reranking (cross-encoder) vienen integrados en Hindsight; se ejecutan localmente dentro del paquete hindsight-all y no requieren una API externa. PostgreSQL también viene integrado con la instalación de Python embebido a través de un directorio de datos pg0 gestionado; alternativamente, puedes apuntar Hindsight a una instancia de PostgreSQL externa. Para una configuración totalmente local y sin nube, establece HINDSIGHT_API_LLM_PROVIDER=ollama y apúntalo a un modelo Ollama local: retain y recall funcionarán totalmente; reflect requiere un modelo capaz de realizar llamadas a herramientas (por ejemplo, qwen3:8b).

Herramientas: hindsight_retain, hindsight_recall, hindsight_reflect (síntesis única entre memorias).

Configuración:

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

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

Configuración: $HERMES_HOME/hindsight/config.json

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

Interfaz local: hindsight-embed -p hermes ui start

Holographic

Ideal para: configuraciones centradas en la privacidad con almacenamiento exclusivamente local.

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

Dependencias externas: Ninguna. Holographic no requiere LLM, ni modelo de embedding, ni base de datos, ni conexión a red. La codificación de la memoria se realiza íntegramente mediante álgebra HRR ejecutándose en el mismo proceso. Esto lo hace único entre los ocho proveedores: es el único que opera con cero llamadas externas. La desventaja es que la calidad de la recuperación es inferior a la búsqueda semántica basada en embeddings, y no hay síntesis entre memorias como el reflect de Hindsight. Para usuarios donde la privacidad y la operación sin dependencias son innegociables, Holographic es la única opción que ofrece eso incondicionalmente.

Herramientas: 2 herramientas para operaciones de memoria mediante álgebra HRR.

Configuración:

hermes memory setup  # select "holographic"

RetainDB

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

RetainDB utiliza compresión delta para almacenar eficientemente las actualizaciones de memoria y recuperación híbrida (vector + BM25 + reranking) para mostrar el contexto relevante. Está basado en la nube con un coste de 20 $/mes, y todo el procesamiento de memoria se gestiona en el lado del servidor.

Dependencias externas: Las llamadas al LLM de RetainDB, el pipeline de embedding y el reranking se ejecutan todos en la propia infraestructura en la nube de RetainDB; tú solo proporcionas una RETAINDB_KEY. La extracción de memoria utiliza Claude Sonnet en el lado del servidor. No existe una opción de auto-alojamiento ni un modo local. Todos los datos de la conversación se envían a los servidores de RetainDB para su procesamiento y almacenamiento. Si la soberanía de los datos o la operación fuera de línea es importante para tu caso de uso, este proveedor no es adecuado.

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  # select "retaindb"

ByteRover

Ideal para: memoria local-first con almacenamiento auditable y legible por humanos.

ByteRover almacena la memoria como un árbol de contexto markdown estructurado —una jerarquía de archivos de dominio, tema y subtema— en lugar de vectores de embedding o una base de datos. Un LLM lee el contenido de origen, razona sobre él y coloca el conocimiento extraído en la ubicación correcta de la jerarquía. La recuperación es una búsqueda de texto completo con MiniSearch con una caída por niveles (fallback) a la búsqueda impulsada por LLM, sin necesidad de una base de datos vectorial.

Dependencias externas: ByteRover requiere un LLM para la curación y búsqueda de memoria (se admiten 18 proveedores, incluidos Anthropic, OpenAI, Google, Ollama y cualquier endpoint compatible con OpenAI mediante el slot de proveedor openai-compatible). No requiere modelo de embedding ni base de datos: el árbol de contexto es un directorio local de archivos markdown simples. La sincronización en la nube es opcional y se utiliza solo para la colaboración en equipo; todo funciona completamente sin conexión por defecto. Para una configuración local totalmente autónoma, conecta Ollama como proveedor (brv providers connect openai-compatible --base-url http://localhost:11434/v1) y ningún dato saldrá de tu máquina.

Herramientas: 3 herramientas para operaciones de memoria.

Configuración:

hermes memory setup  # select "byterover"

Supermemory

Ideal para: flujos de trabajo empresariales con context fencing e ingesta de grafos de sesión.

Supermemory proporciona context fencing (aislar la memoria por contexto) e ingesta de grafos de sesión (importar historiales de conversación completos). Extrae automáticamente memorias, construye perfiles de usuario y ejecuta una recuperación híbrida que combina la búsqueda semántica y por palabras clave. La API de la nube gestionada es el objetivo principal de despliegue.

Dependencias externas: El servicio en la nube de Supermemory gestiona toda la inferencia de LLM y el embedding en el lado del servidor; tú solo proporcionas una clave de API de Supermemory. El auto-alojamiento está disponible exclusivamente como un complemento de plan empresarial y se despliega en Cloudflare Workers; requiere que proporciones PostgreSQL con la extensión pgvector (para el almacenamiento de vectores) y una clave de API de OpenAI (obligatoria, con Anthropic y Gemini como adiciones opcionales). No existe una ruta de auto-alojamiento basada en Docker o local: la arquitectura está estrechamente vinculada al edge compute de Cloudflare Workers. Para los usuarios que necesitan soberanía de datos completa sin un contrato empresarial, este proveedor no es la opción adecuada.

Herramientas: 4 herramientas para operaciones de memoria.

Configuración:

hermes memory setup  # select "supermemory"

Cómo elegir

• ¿Necesitas soporte multi-agente? Honcho
• ¿Quieres algo gratuito y auto-hosteado? OpenViking o Holographic
• ¿Quieres cero configuración? Mem0
• ¿Quieres grafos de conocimiento? Hindsight
• ¿Quieres compresión delta? RetainDB
• ¿Quieres eficiencia de ancho de banda? ByteRover
• ¿Quieres funciones empresariales? Supermemory
• ¿Quieres privacidad (solo local)? Holographic
• ¿Quieres algo totalmente local sin servicios externos? Holographic (sin dependencias en absoluto) o Hindsight/Mem0/ByteRover con Ollama
• ¿Quieres una memoria auditable y legible por humanos sin pipeline de embedding? ByteRover

Para obtener configuraciones de proveedores perfil por perfil completas y patrones de flujo de trabajo del mundo real, consulta Hermes Agent production setup.

Guías relacionadas

• AI Systems Memory hub — alcance de este subgrupo y enlaces a las guías de Cognee
• Hermes Agent Memory System — memoria central de dos archivos antes de los plugins
• Hermes Agent production setup — integración de perfiles para proveedores en la práctica