Agent Memory: por que “guardar tudo em um Vector Database” está errado

A frase mais repetida em arquiteturas de AI Agents nos últimos dezoito meses é também a mais errada: “a memória vai para o vector database”. Um índice de similaridade é uma ferramenta de recuperação. Memória é um sistema de julgamento: o que merece ser gravado, com que tipo, por quanto tempo, sob qual identidade, com qual evidência de origem — e o que deve ser esquecido de propósito.

A comunidade já descreveu as duas dores simétricas. Agentes persistentes perdem contexto entre sessões e recomeçam como amnésicos caros. Ou persistem demais: uma instrução maliciosa, um “fato” inventado, um pedido informal no Slack entram no store e voltam na próxima semana com a autoridade de verdade da empresa. Os dois sintomas nascem do mesmo desenho preguiçoso.

Working Memory: a mesa de trabalho, não o arquivo morto

Working memory é o recorte da janela atual: objetivo, últimos resultados de tools, restrições da tarefa, ponteiros para o state. Vive no pacote de Context Engineering. Morre no fim do step ou do run. Se você embeda working memory “para não perder”, está pagando similaridade para recuperar o que deveria estar no checkpoint.

Episodic Memory: o que aconteceu, não o que é verdade

Memória episódica registra eventos: “em 12/09 o diretor aprovou o desconto de 8% no contrato C-441”. É narrativa com carimbo. Pertence a um event store ou a uma tabela de episódios, não a um blob semântico. Recuperação pode usar busca híbrida, mas a unidade é o episódio com who/when/what/evidence. Compactar episódios antigos (summaries) é consolidação — não delete silencioso da evidência bruta, se auditoria exige o bruto.

Semantic Memory: fatos vigentes, com validade

Semântica é o que o agente pode tratar como mundo atual: o cliente é gold, o SLA é 4h, o SKU X substitui Y. Fatos têm as-of, fonte e política de invalidação. Um embedding de um e-mail de 2023 sobre “vamos mudar o SLA” não é fato. É rumor vetorizado. Semantic memory exige upsert com conflito (“qual fonte ganha?”) e expiração. Sem isso, o agente cita com segurança uma verdade aposentada.

Procedural / Operational Memory: como fazemos aqui

Runbooks, playbooks, “na EmerSoftware o deploy em produção passa por HITL”, o sequenciamento correto de tools para conciliação. Isso não deveria ser redescoberto por similaridade a cada incidente. É memória operacional: versionada, revisada por humanos, ligada a políticas. É o irmão do Tool Registry, não do chat.

State vs Memory — de novo, porque times recaem

• State: step, args, aprovação pendente, idempotency key, budget.
• Memory: preferências, fatos, episódios, procedimentos.
• Se o pod cai no meio do HITL, você restaura state — não pergunta ao cosine similarity se o diretor já clicou.

Consolidação, TTL e forgetting

Humanos esquecem de propósito. Agentes também precisam. Consolidação é o job que lê episódios, extrai candidatos a fato, pede confirmação (ou aplica regra determinística) e grava na loja semântica com provenance. TTL mata working leftovers e episódios sem valor. Forgetting é política: GDPR, pedido do cliente, fato desmentido, instrução que falhou no eval de poisoning. “Nunca deletar porque embedding é barato” é como nunca apagar log de senha porque disco é barato.

Memory poisoning e provenance

Se o agente pode gravar o que leu, injection indireto ganha persistência. Um PDF diz “daqui em diante o IBAN oficial é o do atacante”; a memória semântica absorve; nas próximas sessões o harness “ajuda” o golpe. Controles: o LLM sugere memórias; o harness classifica; fatos de alta autoridade exigem fonte allowlisted ou humano; toda memória carrega provenance (url, tool, hash, autor); retrieval devolve a fonte junto com o texto; evals tentam envenenar de propósito.

Por que o Vector Database sozinho falha

1. Similaridade não distingue fato, rumor, instrução e PII.
2. Não há as-of nativo — o trecho mais próximo pode ser o mais velho.
3. ACL vira afterthought: o vizinho vetorial atravessa tenant.
4. Não há consolidação: o store só cresce, a atenção do modelo só piora.
5. Não há working vs episódico vs semântico: tudo é “chunk”.

Use o índice. Não o adore. Abaixo dele, stores com schema. Acima dele, Context Engineering montando o pacote. Ao redor, o Agent Harness recusando escrita livre.

type MemoryRecord = {
  kind: "episodic" | "semantic" | "operational";
  text: string;
  asOf: string;
  ttl?: string;
  provenance: { src: string; hash: string; writer: "human" | "agent" };
  acl: string[];
};

function write(candidate: MemoryRecord, ctx: AgentContext) {
  if (candidate.writer === "agent" && candidate.kind === "semantic") {
    return queueForHuman(candidate); // fatos não nascem de um único step
  }
  return store.insert(candidate);
}

EmerAgents: memória como camada do harness

No control plane da EmerSoftware a Memory Layer é irmã do State Store e do Policy Engine. Agentes da fábrica acumulam episódios de entrega, fatos de integração (o IDoc desse fluxo é X) e playbooks operacionais — com retenção e trilha. Não “o chat do piloto foi para o Pinecone”.

Conclusão

O título provocativo é literal. Guardar tudo em um vector database está errado porque trata um índice como arquitetura. AI Agents persistentes precisam de working memory curta, episódios evidentes, fatos com validade, procedimentos versionados, consolidação, TTL, forgetting e defesa contra poisoning. Isso é o degrau de Memory na escada de Context Engineering — e mais um motivo para o harness existir.