Radar Tech: seu agente não precisa de memória, precisa de documentação — e o dossiê de hoje mostra por quê
A discussão que dominou a engenharia nas últimas 24h: plugins de memória para agentes falham porque guardam o passado, não o conhecimento. Somado à crítica judicial ao armazenamento inauditável de dados, o recado é o mesmo — contexto precisa ser texto versionado, não um banco vetorial opaco.
Se a conversa de engenharia das últimas 24 horas tivesse um único slogan, seria este: o agente não precisa de memória, precisa de documentação. A frase viralizou e bateu numa dor que quase todo time que usa IA para codar já sente — o contexto entre sessões simplesmente não se sustenta.
O argumento é direto. Um plugin de "memória" hoje funciona assim: pega suas conversas, fatia em pedaços, joga num banco de vetores e, a cada prompt, injeta os cinco fragmentos mais parecidos. Simulação de lembrança, não entendimento. O modelo não sabe o que existe no seu projeto, não sabe o que mudou e não sabe que não sabe. Ele recebe um sorteio sobre o passado e torce para que o recorte certo suba.
O que os plugins de memória erram
O problema não é a implementação — é a arquitetura por trás de todos eles. Similaridade não é correção: parecido não é verdadeiro. Um fragmento isolado perde a motivação, o porquê e o contexto em que a decisão foi tomada. E, o mais perigoso, o passado é tratado como verdade: o código mudou ontem, mas a sessão de cinco meses atrás continua no índice dizendo que a fila certa era outra.
Há um quinto erro, menos debatido e talvez o mais grave: o store é inauditável. Onde ficam dez mil embeddings, qual está desatualizado, qual nunca foi recuperado, qual está errado e silenciosamente influenciando o agente? Ninguém consegue responder. É um banco opaco afetando decisões de engenharia.
A mesma lição vinda de outro canto
No mesmo fim de semana, uma decisão judicial nos EUA chamou de "vigilância de massa indiscriminada" um sistema que cataloga passivamente o deslocamento de pessoas por câmeras de leitura de placas. O núcleo da crítica não foi a tecnologia em si — foi a retenção sem limite e sem auditoria: um store que acumula tudo sobre todos, do qual ninguém consegue dizer o que está guardado nem por quê.
São dois domínios diferentes chegando à mesma conclusão de arquitetura. Um repositório de dados — seja de "memórias" de agente ou de leituras de placas — que ninguém pode inspecionar, datar e expurgar é um passivo. A diferença é que, no caso do agente, o expurgo e a auditoria estão sob seu controle e você pode desenhá-los hoje.
Documentação em vez de recall
A alternativa que ganha tração é trocar o banco vetorial por um workspace documental: arquivos Markdown versionados, que o agente consulta antes de agir e atualiza depois de agir. Nada de embeddings como roteador, nada de reescrever memórias durante a noite. Texto plano que o time lê, edita, commita e compartilha.
Na prática, isso significa algumas decisões concretas:
- Um índice determinístico (
00-INDEX.md) que diz onde está cada coisa e "quando ler" — o roteador é o índice, não a busca por similaridade. - Contrato de leitura: para cada tipo de tarefa, a sequência de arquivos que o agente abre.
- Contrato de escrita: os gatilhos que o obrigam a criar ou atualizar documentação ao fim da tarefa, no mesmo commit — senão o documento nasce órfão e invisível.
- Ciclo de vida por tipo: specs e instruções são vivas; decisões (ADRs) ficam imutáveis; pesquisas externas ganham prazo de validade e expiram.
- Política de redação: segredos, tokens e dados pessoais nunca viram documento.
O ganho não é performance do modelo — é governança. Um git log vira a trilha de auditoria de tudo o que o agente lembra, e qualquer humano consegue inspecionar uma decisão de contexto meses depois.
Por que isso é arquitetura, e não detalhe de ferramenta
Memória sempre foi tratada como recurso de produto — "ligue o plugin e pronto". O que os dois episódios do fim de semana mostram é que o que o sistema retém e por quanto tempo é uma decisão de projeto, no mesmo nível de schema de banco ou política de log. Um agente que carrega um store inauditável é uma dívida técnica silenciosa, exatamente como um log que grava dados de cartão.
A boa notícia é que a correção é barata e incremental: comece por um domínio, crie o índice e o contrato de escrita, rode por duas semanas e meça. Se o agente parar de reimplementar o que já existe e de "lembrar" do que foi aposentado, o workspace se paga.
O catálogo da ArchPrompts agora tem um pacote que transforma essa decisão num plano executável, com contratos de leitura e escrita, política de retenção e critérios de aceite verificáveis — a mesma lógica vale para qualquer time que já perdeu uma tarde explicando ao agente o que ele deveria saber.