Agentis Memory: almacén compatible con Redis con búsqueda vectorial y embeddings locales

Agentis Memory propone una idea sencilla pero relevante para el mercado de agentes de IA: una memoria operativa compartida que se usa como un Redis corriente. En lugar de una base de datos vectorial aparte, una API externa de embeddings y SDK a medida, el proyecto combina un almacén clave-valor, búsqueda semántica y cálculo local de embeddings en un único proceso. Para los equipos que construyen sistemas multiagente, es un intento de resolver uno de sus problemas más dolorosos: intercambiar contexto entre agentes sin capas de red ni latencias añadidas.

El problema surgió en un escenario real: la investigación de incidentes en producción. Cuando varios agentes especializados analizan en paralelo logs, métricas, comunicaciones y el historial de fallos anteriores, cada uno ve solo su fragmento del cuadro. Un agente puede encontrar OOMKilled en los logs y llegar de hecho a la causa raíz, mientras los demás siguen elaborando sus propias versiones: un pico de CPU, un despliegue reciente u otra correlación.

Al final, el sintetizador recibe varias hipótesis en conflicto, algunas de las cuales son puro ruido. Guardar esos hallazgos en un archivo markdown compartido no ayuda: hay condiciones de carrera al escribir, no hay TTL, ni estructura, ni búsqueda por significado. Para un sistema de agentes, eso ya no basta.

El análisis de las soluciones existentes mostró el mismo problema desde otro ángulo. Mem0 y Zep ya se presentan como capa de memoria para agentes de IA, pero arrastran una API REST, SDK propios, un almacén vectorial y servicios externos de embeddings. Redis Stack se acerca más al modelo buscado porque mantiene la compatibilidad con los clientes de Redis, pero deja el cálculo de vectores fuera del servidor. Eso es tolerable para RAG de largo plazo, pero demasiado pesado para una memoria operativa, donde un agente guarda un dato y otro debe encontrarlo en milisegundos. Cada salto de red adicional perjudica tanto la latencia como la fiabilidad.

La primera hipótesis de ingeniería era obvia: tomar el propio Redis, bifurcarlo e integrar ONNX Runtime y un índice vectorial. En la práctica, este camino chocó pronto con el trabajo complejo con C, bibliotecas nativas, gestión de memoria e inestabilidad con peticiones concurrentes. Tras el prototipo fallido, el proyecto se reescribió desde cero en Java 25 con GraalVM native-image.

El resultado es un único binario nativo de unos 150 MB con el modelo de embeddings ya incorporado. Por dentro usa la Java Vector API para acelerar con SIMD la similitud del coseno, Project Loom para los hilos virtuales, ONNX Runtime para la inferencia local del modelo all-MiniLM-L6-v2 y la biblioteca jvector para la búsqueda de vecinos más cercanos con HNSW.

Por fuera, Agentis Memory se comporta como un servidor Redis habitual. Admite más de 90 comandos estándar, TTL, SCAN y pub/sub básico, y se puede conectar con clientes corrientes como redis-py, Jedis, ioredis o go-redis. La diferencia clave son cuatro comandos de memoria adicionales.

MEMSAVE recibe texto, lo divide en fragmentos por frases, calcula vectores de 384 dimensiones y los indexa de forma asíncrona, normalmente en 5–10 milisegundos por fragmento. MEMQUERY recibe una consulta en lenguaje natural y devuelve los registros más cercanos por similitud del coseno. MEMSTATUS indica si el índice está listo para una clave concreta, y MEMDEL elimina datos a la vez de la capa clave-valor y del índice vectorial.

Para el desarrollador es una extensión mínima del modelo Redis que ya conoce, no una plataforma aparte con un ecosistema nuevo.

El rendimiento también es revelador. La primera versión en Java era aproximadamente el doble de lenta que Redis. Tras pasar a GraalVM native-image y reescribir la ruta caliente con la Vector API, la situación se invirtió: las operaciones con cadenas subieron de unas 60 mil a 168 mil ops/sec, es decir, el proyecto alcanzó cerca de 1,36x Redis.

En una carga mixta el resultado fue de alrededor de 1,40x. Con una profundidad de pipeline de 100, el sistema alcanzó 3,19 millones de operaciones por segundo, unas 1,71x Redis, gracias a una arquitectura multihilo sin bucle de eventos monohilo. Pero queda una contrapartida: en latencia p99 con cadenas, Redis sigue por delante, con 3,82 milisegundos frente a 6,27 de Agentis Memory, el precio que se paga por el garbage collection.

Se hace especial hincapié en la privacidad y el coste. Los embeddings se calculan localmente con ONNX Runtime dentro del propio proceso, sin claves de API, sin llamadas a servicios externos y sin enviar logs, métricas ni comunicaciones internas a la nube. Para sistemas que manejan incidentes e infraestructura interna, no es una mejora cosmética sino una decisión arquitectónica importante. La inferencia local tarda unos 2–5 milisegundos por fragmento, evita una factura aparte por embeddings y elimina la dependencia del uptime ajeno. Cuanto más sensibles son los datos y mayor la frecuencia de consultas, más se nota la ventaja de este enfoque.

En un plano más amplio, Agentis Memory ilustra cómo cambia la infraestructura en torno a los agentes de IA. Al mercado ya no le basta con conectar un LLM, herramientas y un orquestador. El siguiente punto de competencia es la memoria compartida, la velocidad de sincronización del contexto y la capacidad del sistema de descartar rápidamente hipótesis falsas. Si el modelo compatible con Redis y embeddings locales se consolida en cargas reales, estas soluciones podrían ser para los sistemas de agentes lo que el Redis corriente lleva tiempo siendo para el desarrollador backend clásico: una capa rápida de coordinación, caché y memoria de trabajo compartida.

*Meta está reconocida como organización extremista y prohibida en la Federación Rusa.