Memória em Agents com Luciano Oliveira

Destaques

• Nexus é uma API de memória de longo prazo para agentes de IA criada por Luciano Oliveira (RedFox Code): funciona via MCP + Agent Skill, sem VectorDB manual e sem pipeline pra montar.
• Pipeline de ingestão: texto cru entra, o motor extrai entidades e datas e versiona no tempo usando fila assíncrona em Go (biblioteca River), gera embeddings com Jina v5 e reranking com Jina v3, tudo armazenado em Postgres com pgvector e pgvectorscale.
• Busca híbrida (vetorial semântica + palavra-chave + sinais de entidade) seguida de rerank antes de a LLM final responder com fontes e score de confiança.
• Sete tipos de memória: memory, entity, wiki, decision, lesson (lição), error e guideline — guideline é a política fixa que o agente nunca deve esquecer (ex.: "não fazer migrate/delete sem confirmar antes").
• Memória é versionada no tempo: quando um fato muda, a versão nova supera a antiga e o recall nunca devolve dado velho — essa é a diferença central frente a simplesmente "jogar tudo num embedding".
• Benchmark usado é o LongMemEval S400 (mesmo teste que o Mem0 usa para se validar); o Nexus oscila entre 80% e 83% dependendo do juiz LLM escolhido. Luciano mostrou que usar o mesmo modelo como extrator e como juiz infla o placar de forma não confiável (chegou a 92% nesse cenário viesado).
• Arquitetura multi-tenant com isolamento por organização e dois bancos de dados separados (autenticação/front-end vs. memórias) por questão de segurança; dashboard construído em Laravel com Filament e billing via Stripe.
• Testou embeddings da Cohere e rodou localmente com Ollama antes de fechar em Jina — Ollama local ficou entre 40% e 50% de precisão por limite de janela de contexto e tokens de entrada.

Profundidade técnica

A discussão técnica mais densa girou em torno do porquê memória não é só "salvar num banco". Marcelo (Marcelão) exemplificou com um agente de vendas: cada fato do cliente vira memória estruturada, mas fatos mudam no meio da conversa (carro quitado vira carro ainda financiado), e o sistema precisa decidir se aquilo é memória de curto prazo — que decai rápido, do tipo "cliente ainda está validando a proposta" — ou memória persistente, que fica para sempre. Um INSERT simples num banco não resolve deduplicação, reconciliação de fatos conflitantes nem decaimento temporal; é exatamente por isso que uma camada de memória dedicada existe. No Nexus essa lógica roda em workers assíncronos escritos em Go (fila via River): um worker cuida da ingestão, outro prepara o domínio da memória, outro extrai entidades e monta o grafo sem schema prévio, e outro gera o wiki — um resumo vivo de cada tópico, não um dump de texto. A recuperação usa as 20 memórias mais relevantes (contra o padrão de 5 usado por outras soluções) para dar mais material à LLM final reconstruir contexto, existindo um trade-off explícito entre tamanho de chunk, janela de embedding (32 mil tokens no Jina) e precisão — aumentar um parâmetro pode piorar outro, exigindo ajuste fino manual e iterativo. Na geração, Luciano usa Minimax como modelo principal com fallback automático via OpenRouter para Gemini ou GPT quando o Minimax satura, evitando que o agente fique sem resposta. Toda guideline (regra fixa, tipo "sempre leia o histórico antes de responder" ou "nunca faça migrate sem confirmar") funciona como um prompt de sistema permanente que a LLM consulta antes de agir — mas, como reforçou Cláudio, nenhuma ferramenta de memória decide sozinha quando consultar o MCP: isso depende inteiramente de quão bem as skills e guidelines do agente descrevem quando gravar e quando recuperar, sob risco de o agente simplesmente ignorar a ferramenta e reler a estrutura do projeto do zero.

Faça parte do Clã

Esse nível de profundidade técnica — arquitetura real, código em produção, debate aberto sobre build vs. buy — é conteúdo exclusivo de quem está dentro do Clã. Quer participar dos próximos encontros ao vivo? Entre pelo Beer and Code Clã Nível 1.