Em maio de 2026 apareceu no Show HN um projeto que tenta resolver um problema velho da categoria nova: agentes de código que esquecem o projeto a cada sessão. O nome é Agents Remember — um conjunto de ferramentas que dá aos coding agents uma memória persistente, versionada junto com o código, e verificada antes de ser usada. Vamos traduzir o que isso significa para quem não vive no terminal.
Resposta direta
Agents Remember é um sistema open-source (versão 2.3.3 em junho de 2026) que dá a coding agents — Claude Code, Cursor, Codex, Antigravity, VS Code Copilot, Hermes e outros — uma memória persistente do projeto, organizada por path, versionada em git, e verificada contra o código real antes de cada uso. Em vez de o agente re-adivinhar as regras do projeto toda vez que você abre uma sessão, as regras vivem em arquivos Markdown ao lado do código, são checadas contra o commit atual, e só são atualizadas depois que a mudança é aprovada. É o equivalente a um README por arquivo, mas com drift-control e workflow de aprovação.
Por que isso importa agora
A maioria dos coding agents hoje tem dois problemas estruturais que ninguém resolveu bem:
- Esquecem o projeto entre sessões. O contexto da janela some, e na próxima vez que você abre o editor o agente começa do zero — não sabe que aquele módulo não pode usar
async, não sabe que aquele endpoint tem contrato com o time de mobile, não sabe que aquela tabela foi descontinuada. - Confiam em instruções top-level que não aparecem na hora certa. Você coloca as regras num
AGENTS.mdna raiz, mas quando o agente está editandosrc/payments/refund.pylinha 142, ele não relê oAGENTS.md. A regra certa está longe demais do momento certo.
O Agents Remember ataca os dois pontos: cada arquivo de código tem um onboarding note espelhado por path (ex: ar-memory/onboarding/src/payments/refund.py.md), o agente lê o código e a nota juntos antes de propor mudança, e a nota é re-verificada contra o commit novo toda vez que algo entra. Se o código mudou, a memória tem que ser atualizada — e isso só acontece depois da mudança aprovada, não antes.
A primeira vista parece detalhe técnico. Não é. É a diferença entre um agente que faz edições plausíveis mas viola regras não-escritas, e um agente que vê as regras no momento exato da decisão.
Como funciona (sem jargão)
O fluxo normal é mais simples do que o nome sugere:
- Você instala o MCP server (via
uvx agents-remember-mcp@latest— um comando só) e copia o starter package do harness que você usa (Claude Code, Cursor, Codex, etc.). Cada harness tem arquivos nativos de skill, hooks e instruções já prontos. - Você roda o skill de onboarding (
c-13-install-and-onboard). Ele cria a estruturaar-coordination/no seu workspace e começa a gerar notas de onboarding para os arquivos do projeto. - No dia a dia, o agente segue o ciclo
l-01-session-job-lifecycle: resolve contexto ativo, checa qualidade da memória, lê o código e a nota por path, propõe mudança, executa, e depois atualiza a nota depois que o commit é aprovado.
O coração da coisa são quatro mecanismos:
- Memória por path.
src/orchestrator/core_editor.pytem nota emar-memory/onboarding/src/orchestrator/core_editor.py.md. Sem busca, sem ranking, sem embedding. O path resolve. - Drift-check contra git. Antes de a nota ser usada, ela é comparada com o commit do arquivo. Se o código mudou e a nota não, ela é marcada como stale. Sem nota stale em decisão.
- Aprovação antes de atualização. O agente não atualiza a nota enquanto a mudança está em discussão. Só depois do commit aprovado. Isso evita o problema de "agente reescreveu a própria memória" que algumas ferramentas mais permissivas têm.
- Providers opcionais para busca semântica. Você pode ligar providers de busca semântica e grafo de código (via Docker + Ollama +
nomic-embed-text) para descobrir arquivos relacionados. Mas a verdade continua sendo o Markdown versionado e o código fonte — não o embedding.
O system/ de cada projeto carrega regras de path, ferramentas, guidelines de código, fontes de doc, política de branch e formato de report. O mesmo setup serve para qualquer harness — você troca o cliente, o comportamento fica.
Comparativo: o que muda na prática
| Aspecto | Coding agent "puro" | Coding agent + Agents Remember |
|---|---|---|
| Conhecimento das regras do projeto | Precisa reler AGENTS.md raiz toda sessão | Nota por path, lida junto com o arquivo |
| Verificação de memória | Nenhuma — o agente confia no que você escreveu | Drift-check contra commit antes de usar |
| Atualização de regras | Manual, raramente | Aprovação-gated, junto com o commit |
| Onboarding de novo agente | Você cola contexto na primeira mensagem | Onboarding notes já estão lá |
| Consistência entre sessões | Depende do seu prompt | Garantida pela nota + drift-check |
| Pesquisa de código | Busca textual no repo | Opcional: semântica + code-graph via providers Dockerizados |
O que isso muda para o seu negócio
Se você não é dev, pode parecer abstrato. Não é. Pense assim: toda vez que seu time (interno ou terceiro) usa um coding agent para mexer no seu sistema, o agent é um estagiário super-poderoso que não conhece suas regras de negócio. Ele vai fazer uma edição que parece correta mas viola uma convenção que só quem trabalha no projeto sabe.
Agents Remember é uma tentativa séria de fechar essa lacuna. Ainda é cedo (2.3.3, ~270 commits, lançamento em maio de 2026), e o path do Claude Code é o mais exercitado — outros harnesses funcionam mas têm menos batalha em produção. Mas a direção é clara: memória persistente, versionada, verificada, e isso é uma peça que vai virar commodity em todo coding agent sério até 2027.
Na prática, se você está contratando um time para construir automações com IA no seu varejo, vale perguntar: como vocês garantem que o agente sabe as regras do nosso CRM, do nosso fluxo de pedido, da nossa regra fiscal? Se a resposta for "a gente coloca no prompt", você tem o problema acima. Se a resposta for "a gente usa memória versionada por path com drift-check", você está olhando para um setup que escala.
Perguntas frequentes
O que é o Agents Remember em uma frase?
Um sistema open-source que dá aos coding agents memória persistente do projeto, organizada por path, versionada em git, e verificada contra o código antes de cada uso.
Como o Agents Remember funciona na prática?
Você instala o MCP server e o starter package do seu harness, roda o skill de onboarding, e no dia a dia o agente lê o código e a nota de onboarding juntos antes de propor mudança. A nota é re-verificada contra o commit e só atualiza depois da mudança aprovada.
Quanto custa implementar o Agents Remember?
O software é gratuito (MIT license, open-source no GitHub). O custo real é o setup inicial — instalar MCP, copiar o starter, rodar o onboarding. Para um projeto de porte médio isso leva algumas horas, não dias. Provedores opcionais (busca semântica) exigem Docker rodando e baixam um modelo de embedding na primeira vez.
Quais os riscos do Agents Remember?
Os principais são: (1) a nota pode ficar stale se ninguém auditar — por isso o drift-check é crítico, (2) o suporte entre harnesses é desigual — Claude Code é o mais estável, outros têm menos batalha, (3) você está adicionando uma dependência nova no fluxo de dev, então o time precisa entender o ciclo. Nada disso é bloqueador, mas precisa ser levado a sério.
O Agents Remember substitui o desenvolvedor?
Não. Ele substitui parte do trabalho de "lembrar e explicar as regras do projeto" — que é o que mais toma tempo do dev sênior revisando PRs. O desenvolvedor continua definindo as regras, revisando mudanças e aprovando o que entra. O agente executa com contexto que antes só existia na cabeça de quem estava há 2 anos no projeto.
Recomendamos também: O que é MCP (Model Context Protocol) e por que vai mudar os agentes de IA e 5 agentes de IA que uma PME brasileira pode usar hoje (sem saber programar).
Quer ver agentes de IA rodando no seu varejo com memória versionada das suas regras de negócio? A Agendai implementa em ~2 semanas — primeira semana de graça. Fale com a gente.