“Memory is no longer just a feature; it is core AI infrastructure.” — PowerDrill AI, 2026

Cuando un agente IA te olvida todo al cerrar la pestaña, la solución obvia parece una base vectorial: guardas embeddings y buscas por similitud semántica. Simple. Funcional. Pero insuficiente.

En 2026, la categoría de “memoria para agentes” ha explotado en 6 campamentos arquitectónicos completamente distintos. Cada uno optimiza un failure mode diferente: olvido, retrieval drift, pérdida de estado, incoherencia de perfil, o colaboración entre agentes.

Después de analizar las 8 implementaciones que Hermes Agent soporta como plugins — y desplegar OpenViking en producción — aquí va el análisis de por qué el juego no es “quién tiene el vector más grande”, sino “qué tipo de memoria necesita tu agente”.

Los 6 Campamentos

La clave: no compiten entre sí. Un agente de soporte cliente necesita perfil extraído (Mem0). Un agente de desarrollo necesita context OS (OpenViking). Un agente de investigación necesita reflexivo (Hindsight).

Los 8 Plugins de Memoria de Hermes

Hermes Agent soporta 8 providers como plugins externos. Cada uno con arquitectura, trade-offs y costes distintos:

Detalle importante: Solo OpenViking y ByteRover pueden funcionar con embeddings 100% locales (Ollama). Los demás necesitan al menos una llamada a un LLM externo para extraer hechos o generar summaries.

Benchmarks: Los Números Reales

Antes de entrar en arquitectura, los benchmarks. Hay 3 benchmarks estándar en 2026:

Tabla de benchmarks (datos verificados, junio 2026)

Caveat importante: Los benchmarks no son comparables directamente entre sí. Cada sistema usa distinto LLM para extracción, distinto juez, y distintas reglas de evaluación. Mem0 publica resultados con su pipeline cloud (GPT-4o) y con su nuevo algorithm (< 7K tokens). Hindsight publica con su pipeline local. ByteRover publica con Gemini Flash. La métrica útil no es el número absoluto, sino la brecha con el baseline sin memoria.

Cómo Funcionan en Producción

Mem0 — El más popular (55K stars, $24M funding)

Mem0 es el “memory layer as a service”. YC S24, con un Seed de $3.9M (Kindred Ventures) y Series A de $20M (Basis Set Ventures, Peak XV, GitHub Fund, YC). 14M+ descargas pip, 186M API calls en Q3 2025, partner exclusivo de memoria para AWS Agent SDK.

Cada vez que añades una conversación, el servidor ejecuta un LLM que extrae hechos discretos, los deduplica, los embebe y los guarda.

from mem0 import Memory
memory = Memory()  # SaaS o Docker self-hosted

memory.add(messages, user_id="alice")
results = memory.search("qué lenguaje prefiere el usuario?", user_id="alice")

Pricing:

• Free: limitado (testing)
• Developer: $19/mo
• Pro: $249/mo (graph memory, entity linking, multi-hop queries)
• Startup Program: 3 meses gratis si < $5M funding

Fortaleza: Plug-and-play. 3 líneas de código y tienes memoria persistente. Extracción automática de hechos. El ecosistema más grande (CrewAI, LangGraph, Flowise, AWS Strands).

Debilidad: El graph memory cuesta $249/mo — un salto grande desde $19. Cada add consume tokens del LLM para extracción.

Para quién: Apps de consumo que necesitan personalización rápida. MVPs. Equipos que no quieren construir su propia pipeline de extracción.

Hindsight — El más preciso (91.4% LongMemEval, 15K stars)

Hindsight (Vectorize.io, $3.5M raised) usa 4 redes paralelas de memoria (hechos, experiencias, entidades, creencias) con 4 estrategias de retrieval simultáneas (semantic, BM25, graph traversal, temporal filtering). MIT licensed, self-hosted con PostgreSQL bundled.

from hindsight_client import HindsightClient
client = HindsightClient(base_url="http://localhost:8888", bank_id="my-project")

client.retain("Alice pasó del backend a liderar la migración ML.")
client.recall("¿Quién trabaja en la plataforma ML?")
client.reflect("¿Qué cambios organizativos hubo últimamente?")  # Síntesis

Fortaleza: reflect es la killer feature — razona sobre la memoria para generar insights que no estaban explícitos en ningún hecho individual. Constellation View — visualización interactiva del grafo de memorias. Highest published LongMemEval.

Debilidad: Más complejo de desplegar. Más overhead computacional (4 retrievals paralelos + cross-encoder reranking + synthesis).

Para quién: Agentes que necesitan aprendizaje acumulativo. Investigación. Cualquier caso donde “recordar” no basta — necesitas “entender”.

ByteRover — El más eficiente (92.2% LoCoMo, 4.2K stars)

ByteRover es el recién llegado con un paper en arxiv. Su tesis: el mismo LLM que razona sobre una tarea debería curar, estructurar y recuperar el conocimiento. Cero infraestructura externa — no vector DB, no graph DB, no embedding service. Todo como archivos markdown en el filesystem local.

Context Tree jerárquico (Dominio > Tema > Subtema > Entrada) con Adaptive Knowledge Lifecycle (importance scoring, maturity tiers, recency decay).

Fortaleza: 92.2% LoCoMo — el top de la tabla. Temporal reasoning 94.4%. Funciona con Gemini Flash ($0) y aun así obtiene 90.9%. Zero infraestructura.

Debilidad: Nuevo, comunidad pequeña. Paper académico, no tanto battle-tested en producción.

OpenViking — El Context OS

OpenViking no se posiciona como “memory provider” sino como context operating system. Iniciado y mantenido por el equipo Viking de ByteDance / Volcengine — docenas de ingenieros en sistemas distribuidos, ML y algorithms con experiencia comercial en context engineering.

La diferencia fundamental: gestiona no solo memorias, sino también documentos, repositorios de código y skills como una jerarquía unificada.

viking://
├── resources/          ← Documentos, repos, PDFs, código
│   ├── infra/
│   └── emergency/
├── user/
│   └── default/
│       └── memories/   ← Hechos del usuario
└── agent/
    └── hermes/
        ├── memories/   ← Lo que el agente aprende
        └── skills/     ← Procedimientos y workflows

3 tipos de contenido vs 1:

Tiered loading — el truco que nadie más tiene:

Esto significa que puedo saber que existe un documento sobre “configuración de permisos NFS” sin leerlo — el L0 abstract ya me dice que existe y de qué trata. Solo bajo a L2 si lo necesito.

AST code extraction — indexado de código sin gastar tokens:

Cuando añades un repositorio, OpenViking no le pide a un LLM que resuma cada archivo. Usa tree-sitter (el mismo motor que los compiladores) para extraer el skeleton estructural: clases, funciones, imports. Un repo de 100 archivos se indexa en segundos, no minutos.

VLM con failover — el pipeline de summaries es resistente:

Nuestra configuración usa glm-4.6v-flash como primario (gratis, 128K contexto, visión) con glm-4.7 como backup automático. Si el primario falla → el backup responde sin intervención. Todo ello corriendo sobre embeddings BGE-M3 locales en Ollama — cero coste de API para la búsqueda.

La Comparación Completa

Lo Que Aprendimos Desplegándolo

Desplegamos OpenViking v0.3.22 en un contenedor LXC (CT110) de nuestro cluster Proxmox, con esta configuración final:

Lecciones del despliegue:

1. La API key expirada es el bug más viejo del mundo. Cuando todo devuelve 401, verificar la key ANTES de investigar red, endpoints o ISP. Perdimos 2 horas en diagnóstico cuando el fix era un sed.

2. El failover no existe hasta que lo rompes. Configurar backup en la config no garantiza nada. Lo verificamos rompiendo intencionalmente el primario y confirmando que glm-4.7 respondió automáticamente.

3. Hermes redacta API keys en tránsito. No se puede escribir una API key a través de las tools del agente — el sistema de seguridad la reemplaza por ***. Workaround: escribir el config con un placeholder y que el usuario haga el sed desde su terminal.

4. Los 6 campamentos son complementarios, no excluyentes. Idealmente, usarías Hindsight para razonar sobre la memoria + OpenViking para gestionar documentos y código. El problema es que Hermes solo permite un provider activo a la vez.

5. Z.AI tiene IPs con TLS inestable. api.z.ai resuelve a dos IPs (128.14.69.45 y .121). La .45 hace connection reset en TLS handshake ~50% del tiempo — causa timeouts intermitentes. No es problema local, es del proveedor.

El Futuro: Qué Nos Falta

OpenViking cubre el 80% de lo que necesitamos. Lo que falta:

1. Knowledge graph. Hindsight/Graphiti trazan relaciones temporales entre hechos (“Alice trabajaba en X cuando cambió Y”). OpenViking no tiene esto.

2. Reflect/synthesis. Hindsight puede generar insights que no estaban en ningún hecho individual. Nosotros solo search/read.

3. Benchmarks publicados. OpenViking no publica métricas de calidad de retrieval en LongMemEval o LoCoMo. No sabemos cómo compara en retrieval quality. ByteRover demostró que publicar benchmarks generó confianza (4.2K → creciendo).

4. Contenido real. Nuestra instancia tiene ~40 vectores — todos de test. El potencial está en indexar repos reales, documentación de infra, y docs del laboratorio.

Conclusión

La pregunta equivocada es: "¿cuál es el mejor sistema de memoria para agentes?"

La pregunta correcta es: "¿qué tipo de memoria necesita mi agente?"

• Si tu agente es un chatbot de soporte → Mem0. Extraer perfiles de usuario automáticamente vale más que indexar repositorios. 55K stars no mienten — es el safe default.

• Si tu agente es un asistente de investigación → Hindsight. La capacidad de razonar sobre hechos acumulados (reflect) es irreplaceable. 15K stars y creciendo rápido (+5K en 5 semanas).

• Si tu agente es un coding agent autónomo → ByteRover. Zero infraestructura, LoCoMo 92.2%, y todo queda como markdown legible.

• Si tu agente es un operador de infraestructura → OpenViking. Necesita documentos, configuraciones, repos de código, procedimientos y memorias operativas — todo en un solo lugar con tiered loading. Backed por ByteDance, con el equipo más grande del espacio.

Para nosotros, que corremos agentes de DevOps sobre un cluster Proxmox con múltiples proyectos, la respuesta fue clara: OpenViking como Context OS, con ByteRover como alternativa para tareas puras de coding, y la posibilidad de añadir Hindsight como complemento para razonamiento sobre la memoria cuando Hermes soporte multi-provider.

El próximo paso: indexar nuestros repos reales (savoury, communia, bazar-lab) como recursos en OpenViking, y medir si el retrieval realmente mejora la calidad de las operaciones diarias. Porque al final, la memoria que no se usa es solo ruido.

Fuentes: Mem0 GitHub, Mem0 Pricing, Mem0 Benchmarks, Hindsight 15K Stars, Hindsight LongMemEval PR, ByteRover LoCoMo, ByteRover Paper (arxiv), OpenViking GitHub, Hermes Memory Providers, Agent Memory Systems Compared (byMar), Memory Providers Compared (glukhov)