Redis-compatible storage with vector search

Agentis Memory: Redis-Compatible Protocol with Native Vector Search and Local Inference

Six subagents investigate an incident: one finds OOMKilled in logs, another spots a CPU spike in Grafana, a third extracts context from Slack. Without shared memory, they generate competing hypotheses. The solution is a Redis-compatible storage with built-in semantic search. One GraalVM binary, local embeddings via ONNX, any Redis client connects without changes.

Why Existing Solutions Fell Short

Mem0 and Zep rely on REST APIs, external vector databases (Qdrant, Postgres), and cloud embeddings (OpenAI). Every MEMSAVE involves three network hops with millisecond latencies. Redis Stack supports vector search via RediSearch but requires external vector inference. A zero-dependency service was needed: RESP protocol, asynchronous vectorization, HNSW indexing in a single process.

The first attempt was a Redis fork with a C module and ONNX Runtime. Result: segfaults under concurrency, manual memory management at the allocator boundary. Switching to Java: GraalVM native-image compiles into a 150MB binary with the all-MiniLM-L6-v2 model embedded (384 dimensions, 2-5ms inference).

Tech Stack for High Performance

• GraalVM native-image: startup <1s, predictable latency without JIT warmup.
• Java Vector API (Project Panama): SIMD for cosine similarity in HNSW searches.
• Project Loom (Virtual Threads): RESP connections in lightweight threads without reactor pattern.
• ONNX Runtime: local embedding inference.
• jvector: HNSW for ANN search.

Benchmark with memtier_benchmark: JVM version — 0.5x Redis (60k ops/s). After native-image + Vector API — 1.36x Redis (168k ops/s) on string operations.

Architecture: KV + Vector Layer

Classic KV-engine (90+ Redis commands: strings, hashes, lists, sets, sorted sets, TTL, SCAN, pub/sub) + vector layer.

redis-cli -p 6399 MEMSAVE "agent:fact:stack" "We use Python 3.12 with FastAPI"
# → OK (asynchronously: chunks → embeddings → HNSW)

MEMQUERY vectorizes the query, searches HNSW by cosine, returns key+text+score:

redis-cli -p 6399 MEMQUERY "Python FastAPI memory issue" TOPK 3
# 1) "agent:fact:stack" "We use Python 3.12 with FastAPI" 0.92

MEMDEL removes from HNSW+KV. MEMSIM for similarity score between texts. Asynchronous processing: KV OK instantly, indexing in background (5-10ms/chunk).

Scenario: Incident Investigation

• LogsInvestigator: MEMSAVE "logs:pod:payment" "OOMKilled pod payment-service".
• MetricsInvestigator: MEMQUERY "memory pressure payment-service" → finds OOM, adjusts hypothesis.
• SlackContextInvestigator: MEMQUERY "deploy payment-service yesterday" → links to deployment.

Synthesizer aggregates a coherent report without noise.

Benchmarks and Optimizations

| Operation | Redis (ops/s) | Agentis Memory (ops/s) | Speedup |

|-----------|---------------|------------------------|---------|

| SET/GET | 120k | 168k | 1.36x |

| MEMSAVE | N/A | 12k (with inference) | - |

| MEMQUERY | N/A | 8k TOPK=10 | - |

Vector API speeds up cosine similarity by 2.5x vs scalar. Virtual Threads scale to 10k connections without thread exhaustion.

Key Takeaways

• Compatibility: 90% Redis API + 4 semantic commands (MEMSAVE, MEMQUERY, MEMDEL, MEMSIM).
• Performance: 1.36x Redis on KV, local inference without network.
• Zero deps: native binary with model, no Docker/keys.
• Use Case: real-time shared memory for multi-agent systems.
• Openness: source code on GitHub for experimentation.

— Editorial Team