Agentis Memory: Armazenamento Compatível com Redis com Busca Vetorial e Embeddings Locais

Agentis Memory propõe uma ideia simples mas importante para o mercado de agentes de IA: uma memória compartilhada que se comporta como Redis comum. Em vez de um banco de dados vetorial separado, uma API externa de embedding e SDKs personalizados, o projeto combina armazenamento chave-valor, busca semântica e cálculo local de embeddings em um único processo. Para equipes construindo sistemas multi-agentes, essa é uma tentativa de resolver um dos problemas mais dolorosos — troca de contexto entre agentes sem camadas de rede adicionais e latência.

O problema surgiu em um cenário real de investigação de incidente em produção. Quando vários agentes especializados trabalham em paralelo estudando logs, métricas, conversas e histórico de incidentes, cada um vê apenas seu próprio fragmento do quadro geral. Um agente pode encontrar OOMKilled nos logs e rastrear a causa raiz, mas os outros continuam construindo suas próprias hipóteses: picos de CPU, um deploy recente, ou qualquer outra correlação.

O sintetizador acaba coletando várias hipóteses conflitantes, muitas das quais são apenas ruído. Tentar armazenar tais descobertas em um arquivo markdown compartilhado não ajuda: surgem conflitos de escrita, não há TTL, não há estrutura e não há busca semântica. Para um sistema de agentes, isso já é insuficiente.

Pesquisa de soluções existentes revelou o mesmo problema de outro ângulo. Mem0 e Zep já se posicionam como camadas de memória para agentes de IA, mas trazem APIs REST, SDKs separados, armazenamento vetorial e serviços externos para embeddings. Redis Stack é mais próximo do modelo necessário porque mantém compatibilidade com clientes Redis, mas deixa o cálculo vetorial fora do servidor.

Para RAG de longo prazo isso é tolerável, mas para memória de trabalho onde um agente salva um fato e outro deve encontrá-lo em milissegundos, tal esquema é muito pesado. Cada salto de rede adicional afeta tanto latência quanto confiabilidade. A primeira hipótese de engenharia era óbvia: pegar Redis em si, fazer um fork e embutir ONNX Runtime e um índice vetorial dentro.

Na prática, esse caminho rapidamente esbarrou em trabalho complexo com C, bibliotecas nativas, gerenciamento de memória e instabilidade sob requisições concorrentes. Após um protótipo fracassado, o projeto foi reescrito do zero em Java 25 usando GraalVM native-image. Isso resultou em um único binário nativo de cerca de 150 MB com um modelo de embeddings já embutido.

Internamente usa Java Vector API para aceleração SIMD de similaridade de cosseno, Project Loom para threads virtuais, ONNX Runtime para inferência local do modelo all-MiniLM-L6-v2 e a biblioteca jvector para busca HNSW de vizinhos mais próximos. De fora, Agentis Memory se comporta como um servidor Redis familiar. Suporta mais de 90 comandos padrão, TTL, SCAN e pub/sub básico, e pode ser acessado através de clientes regulares como redis-py, Jedis, ioredis ou go-redis.

A diferença chave são quatro comandos de memória adicionais. MEMSAVE recebe texto, o divide em chunks por sentenças, calcula vetores 384-dimensionais e os indexa assincronamente, geralmente em 5-10 milissegundos por chunk. MEMQUERY recebe uma consulta em linguagem natural e retorna registros mais próximos por similaridade de cosseno.

MEMSTATUS mostra se o índice está pronto para uma chave específica, e MEMDEL deleta dados simultaneamente da camada chave-valor e do índice vetorial. Para um desenvolvedor, isso parece uma extensão mínima de um modelo Redis já familiar, não uma plataforma separada com novo ecossistema. A história de desempenho também foi instrutiva.

A primeira versão Java funcionava aproximadamente duas vezes mais lentamente que Redis. Após mudar para GraalVM native-image e reescrever o hot path usando Vector API, a situação se reverteu: operações com strings cresceram de aproximadamente 60 mil para 168 mil ops/sec, colocando o projeto em cerca de 1,36x do nível Redis. Em workload misto o resultado foi cerca de 1,40x.

Em profundidade de pipeline 100, o sistema alcançou 3,19 milhões de operações por segundo, ou cerca de 1,71x Redis, graças à arquitetura multi-threaded sem event loop single-threaded. Mas o trade-off permanece: em latência p99 Redis ainda está à frente em strings — 3,82 milissegundos versus 6,27 para Agentis Memory, e esse é o preço pago pela coleta de lixo. Ênfase especial é colocada em privacidade e custo.

Embeddings são calculados localmente via ONNX Runtime diretamente dentro do processo, sem chaves de API, sem chamadas a serviços externos e sem enviar logs, métricas ou tráfego de serviço para a nuvem. Para sistemas trabalhando com incidentes e infraestrutura interna, isso não é uma melhoria cosmética mas uma decisão arquitetural importante. Inferência local leva cerca de 2-5 milissegundos por chunk, não custa nenhuma fatura de embedding separada e remove dependência do tempo de atividade de terceiros.

Quanto mais sensíveis os dados e maior a frequência de acesso, mais notáveis são os benefícios dessa abordagem. Em nível mais amplo, Agentis Memory demonstra bem como a infraestrutura em torno de agentes de IA está mudando. O mercado não tem mais espaço para simplesmente conectar um LLM, ferramentas e um orquestrador.

O próximo ponto competitivo é memória compartilhada, velocidade de sincronização de contexto e capacidade do sistema de descartar rapidamente falsas hipóteses. Se um modelo compatível com Redis com embeddings locais ganhar tração em cargas reais, tais soluções poderiam se tornar para sistemas de agentes o que Redis comum se tornou há muito tempo para desenvolvedores backend convencionais: uma camada rápida de coordenação, cache e memória de trabalho compartilhada.