Agentis Memory: A Redis-Compatible Store With Vector Search and Local Embeddings

Agentis Memory offers a simple idea that matters for the AI agent market: shared working memory you can use like ordinary Redis. Instead of a separate vector database, an external embedding API and custom SDKs, the project combines a key-value store, semantic search and local embedding computation in a single process. For teams building multi-agent systems, it is an attempt to solve one of their most painful problems: exchanging context between agents without extra network layers and delays.

The problem emerged in a real scenario: investigating production incidents. When several specialized agents study logs, metrics, correspondence and the history of past failures in parallel, each sees only its own piece of the picture. One agent may find OOMKilled in the logs and effectively get to the root cause, while the others keep building their own theories about a CPU spike, a recent deploy or some other correlation. The synthesizer ends up with several conflicting hypotheses, some of which are just noise. Storing such findings in a shared markdown file does not help: writes race, there is no TTL, no structure and no search by meaning. That is no longer enough for an agent system.

Looking at existing solutions showed the same problem from another angle. Mem0 and Zep already position themselves as a memory layer for AI agents, but they bring along a REST API, separate SDKs, a vector store and external services for embeddings. Redis Stack is closer to the needed model because it stays compatible with Redis clients, but it leaves vector computation outside the server. That is tolerable for long-term RAG, but too heavy for working memory, where one agent saves a fact and another must find it within milliseconds. Every extra network hop hurts both latency and reliability.

The first engineering hypothesis was obvious: take Redis itself, fork it and embed ONNX Runtime and a vector index inside. In practice this path quickly ran into difficult work with C, native libraries and memory management, plus instability under concurrent requests. After the failed prototype, the project was rewritten from scratch in Java 25 using GraalVM native-image. The result is a single native binary of about 150 MB with the embedding model already built in. Under the hood it uses the Java Vector API for SIMD acceleration of cosine similarity, Project Loom for virtual threads, ONNX Runtime for local inference of the all-MiniLM-L6-v2 model, and the jvector library for HNSW nearest-neighbor search.

From the outside, Agentis Memory behaves like a familiar Redis server. It supports more than 90 standard commands, TTL, SCAN and basic pub/sub, and you can connect with ordinary clients such as redis-py, Jedis, ioredis or go-redis. The key difference is four additional memory commands.

MEMSAVE takes text, splits it into chunks by sentence, computes 384-dimensional vectors and indexes them asynchronously, usually in 5–10 milliseconds per chunk. MEMQUERY takes a natural-language query and returns the nearest records by cosine similarity. MEMSTATUS shows whether the index is ready for a given key, and MEMDEL removes data from both the key-value layer and the vector index.

For a developer this looks like a minimal extension of the familiar Redis model, not a separate platform with a new ecosystem.

The performance story is also telling. The first Java version ran roughly twice as slow as Redis. After the move to GraalVM native-image and a rewrite of the hot path with the Vector API, the picture reversed: string operations rose from about 60 thousand to 168 thousand ops/sec, putting the project at around 1.36x Redis. In a mixed workload the result was about 1.40x. At pipeline depth 100 the system hit 3.19 million operations per second, about 1.71x Redis, thanks to a multithreaded architecture without a single-threaded event loop. But a trade-off remains: Redis is still ahead on p99 latency for strings, at 3.82 milliseconds versus 6.27 for Agentis Memory, which is the price paid for garbage collection.

Privacy and cost get special emphasis. Embeddings are computed locally via ONNX Runtime inside the process, with no API keys, no calls to external services and no logs, metrics or internal correspondence sent to the cloud. For systems that handle incidents and internal infrastructure, this is not a cosmetic improvement but an important architectural decision. Local inference takes about 2–5 milliseconds per chunk, avoids a separate embedding bill and removes dependence on someone else's uptime. The more sensitive the data and the higher the request rate, the more noticeable the benefit.

More broadly, Agentis Memory shows how the infrastructure around AI agents is changing. Simply connecting an LLM, tools and an orchestrator is no longer enough for the market. The next point of competition is shared memory, the speed of context synchronization and a system's ability to quickly discard false hypotheses. If the Redis-compatible model with local embeddings takes hold in real workloads, such solutions may become for agent systems what ordinary Redis long ago became for classic backend developers: a fast layer for coordination, caching and shared working memory.

*Meta is recognized as an extremist organization and banned in the Russian Federation.