Por que os desenvolvedores discutem sobre memória de agentes de IA: técnica ou filosofia?

No Habr foi publicado um artigo técnico típico sobre memória para agentes de IA: SQLite, armazenamento de contexto, busca por conhecimentos acumulados, economia de tokens. Mas os comentários sob a publicação acabaram sendo muito mais interessantes que o próprio texto.

Técnica como motivo para disputa

Na superfície, a discussão parecia padrão: qual banco de dados usar, se a busca semântica é necessária ou se a busca em texto completo é suficiente, como indexar o contexto. Alguns insistiam que SQLite cobre a maioria das tarefas — simples e confiável. Outros exigiam armazenamentos vetoriais, pipelines RAG, mecanismos multi-nível de recuperação. Disputas sobre desempenho são comuns. Mas conforme a discussão se desenvolvia, uma questão diferente começava a emergir por trás dos argumentos técnicos, uma muito mais fundamental.

Três posições que não conseguem concordar

Desenvolvedores discutindo sobre memória para agentes na verdade divergem sobre o que consideram o próprio agente. Basicamente, emergem três posições:

• Instrumental: memória é um cache. Um agente funciona melhor se não precisa reconstruir o contexto do zero cada vez. A tarefa é puramente de engenharia: velocidade, confiabilidade, economia de tokens.
• Comportamental: um agente deveria "lembrar" das preferências do usuário e se adaptar a elas ao longo do tempo. Isso é sobre personalização e experiência do usuário.
• Baseada em identidade: um agente deveria ter um "eu" contínuo — um sentimento da sua própria história que influencia os julgamentos e decisões aqui e agora.

Externamente, essas posições entram em conflito sobre questões técnicas — formato de armazenamento, tamanho da janela de contexto, política de esquecimento. Mas na realidade, divergem no nível das expectativas conceituais. Se para uma pessoa "memória" significa uma tabela de lookup, e para outra significa formar a identidade do agente, elas não concordarão sobre a estrutura de uma tabela de banco de dados.

"O problema não é como armazenar — é o que queremos preservar em

primeiro lugar" — um participante da discussão formulou com precisão a essência da divergência.

Por que as ferramentas são suficientes, mas as perguntas permanecem

Tecnicamente, o problema de memória é resolvido de forma bastante bem. PostgreSQL com pgvector, Chroma, Pinecone, Redis, SQLite simples — cada uma dessas ferramentas cobre cenários reais. O stack é escolhido para a tarefa. O problema é diferente: a comunidade não tem consenso sobre o que é um agente — o que significa não há resposta clara sobre o que exatamente precisa ser lembrado. Se um agente é uma entidade autônoma, a tarefa se torna quase filosófica:

• Como organizar a continuidade do "eu" entre diferentes sessões?
• Como decidir o que é importante lembrar e o que esquecer deliberadamente?
• Como evitar que a memória acumulada se torne uma fonte de alucinações?
• Onde está o limite entre personalização e criar dependência do usuário?

Essas questões não são resolvidas escolhendo entre SQLite e um banco de dados vetorial.

O que isso significa

A discussão no Habr é um sintoma de uma divisão mais ampla na comunidade profissional. Conforme os agentes de IA saem dos protótipos para produtos reais, questões fundamentais sobre sua natureza deixam de ser acadêmicas. Equipes que hoje projetam a arquitetura de memória estão de fato decidindo o que seu agente será — uma ferramenta inteligente ou algo que pretende ser mais. E enquanto essa questão permanecer aberta, as disputas técnicas continuarão.