Agentis Memory: Almacenamiento Compatible con Redis con Búsqueda Vectorial e Embeddings Locales

Agentis Memory propone una idea simple pero importante para el mercado de agentes de IA: una memoria compartida que se comporta como Redis ordinario. En lugar de una base de datos vectorial separada, una API de embedding externa y SDK personalizados, el proyecto combina almacenamiento clave-valor, búsqueda semántica y cálculo local de embeddings en un único proceso. Para equipos que construyen sistemas multiagentes, este es un intento de resolver uno de los problemas más dolorosos: el intercambio de contexto entre agentes sin capas de red adicionales y latencia.

El problema surgió en un escenario real de investigación de incidentes en producción. Cuando varios agentes especializados trabajan en paralelo estudiando logs, métricas, conversaciones e historial de incidentes, cada uno ve solo su propio fragmento del panorama general. Un agente puede encontrar OOMKilled en los logs e identificar la causa raíz, pero los otros continúan construyendo sus propias hipótesis: picos de CPU, un despliegue reciente, o cualquier otra correlación.

El sintetizador termina recopilando varias hipótesis conflictivas, muchas de las cuales son solo ruido. Intentar almacenar estos hallazgos en un archivo markdown compartido no ayuda: surgen conflictos de escritura, no hay TTL, no hay estructura y no hay búsqueda semántica. Para un sistema de agentes, esto ya es insuficiente.

El estudio de soluciones existentes reveló el mismo problema desde otro ángulo. Mem0 y Zep ya se posicionan como capas de memoria para agentes de IA, pero traen APIs REST, SDK separados, almacenamiento vectorial y servicios externos para embeddings. Redis Stack está más cerca del modelo necesario porque mantiene compatibilidad con clientes Redis, pero deja el cálculo vectorial fuera del servidor.

Para RAG a largo plazo esto es tolerable, pero para memoria de trabajo donde un agente guarda un hecho y otro debe encontrarlo en milisegundos, tal esquema es demasiado pesado. Cada salto de red adicional afecta tanto la latencia como la confiabilidad. La primera hipótesis de ingeniería era obvia: tomar Redis mismo, bifurcarlo e incrustar ONNX Runtime e índice vectorial dentro.

En la práctica, este camino rápidamente topó con trabajo complejo con C, bibliotecas nativas, gestión de memoria e inestabilidad bajo solicitudes concurrentes. Después de un prototipo fallido, el proyecto fue reescrito desde cero en Java 25 usando GraalVM native-image. Esto resultó en un único binario nativo de aproximadamente 150 MB con un modelo de embeddings ya incrustado.

Internamente utiliza Java Vector API para aceleración SIMD de similitud de coseno, Project Loom para threads virtuales, ONNX Runtime para inferencia local del modelo all-MiniLM-L6-v2 y la biblioteca jvector para búsqueda HNSW de vecinos más cercanos. Desde el exterior, Agentis Memory se comporta como un servidor Redis familiar. Soporta más de 90 comandos estándar, TTL, SCAN y pub/sub básico, y puede ser accedido a través de clientes regulares como redis-py, Jedis, ioredis o go-redis.

La diferencia clave son cuatro comandos de memoria adicionales. MEMSAVE toma texto, lo divide en chunks por oraciones, calcula vectores 384-dimensionales y los indexa asincrónicamente, usualmente en 5-10 milisegundos por chunk. MEMQUERY toma una consulta en lenguaje natural y devuelve registros más cercanos por similitud de coseno.

MEMSTATUS muestra si el índice está listo para una clave específica, y MEMDEL elimina datos simultáneamente de la capa clave-valor y del índice vectorial. Para un desarrollador, esto se ve como una extensión mínima de un modelo Redis ya familiar, no una plataforma separada con un nuevo ecosistema. La historia de desempeño también fue instructiva.

La primera versión de Java funcionaba aproximadamente el doble de lento que Redis. Después de cambiar a GraalVM native-image y reescribir la ruta crítica usando Vector API, la situación se revirtió: las operaciones de string crecieron de aproximadamente 60 mil a 168 mil ops/sec, colocando el proyecto en aproximadamente 1,36x del nivel de Redis. En carga mixta el resultado fue alrededor de 1,40x.

Con profundidad de pipeline 100, el sistema alcanzó 3,19 millones de operaciones por segundo, o aproximadamente 1,71x Redis, gracias a su arquitectura multihilo sin event loop de un único hilo. Pero el compromiso persiste: en latencia p99 Redis sigue adelante en strings — 3,82 milisegundos versus 6,27 para Agentis Memory, y este es el precio pagado por la recolección de basura. Se hace especial énfasis en privacidad y costo.

Los embeddings se calculan localmente a través de ONNX Runtime directamente dentro del proceso, sin claves de API, sin llamadas a servicios externos y sin enviar logs, métricas o tráfico de servicio a la nube. Para sistemas que trabajan con incidentes e infraestructura interna, esto no es una mejora cosmética sino una decisión arquitectónica importante. La inferencia local toma aproximadamente 2-5 milisegundos por chunk, no cuesta ninguna factura de embedding separada y elimina la dependencia del tiempo de actividad de terceros.

Cuanto más sensibles sean los datos y mayor sea la frecuencia de acceso, más notables serán los beneficios de este enfoque. A un nivel más amplio, Agentis Memory demuestra bien cómo la infraestructura alrededor de agentes de IA está cambiando. El mercado ya no tiene espacio para simplemente conectar un LLM, herramientas y un orquestrador.

El siguiente punto competitivo es la memoria compartida, la velocidad de sincronización de contexto y la capacidad del sistema para descartar rápidamente hipótesis falsas. Si un modelo compatible con Redis con embeddings locales gana tracción en cargas reales, tales soluciones podrían convertirse para sistemas de agentes en lo que Redis ordinario hace mucho tiempo se convirtió para desarrolladores backend convencionales: una capa rápida de coordinación, caché y memoria de trabajo compartida.