O debate “os arquivos são tudo que você precisa” ignora o que realmente está acontecendo na arquitetura de memória do agente

Quando você observa como as principais equipes de engenharia realmente constroem sistemas de memória de agente, surge um padrão: há uma interface de sistema de arquivos para o que os agentes veem e armazenamento de banco de dados para o que persiste. O debate nunca foi “sistema de arquivos ou banco de dados”; sempre foram ambos, nas camadas certas.

A ideia de que os sistemas de arquivos são boas interfaces de agentes não é nova. Dust.tt estava projetando dados da empresa em sistemas de arquivos sintéticos em meados de 2025. Os benchmarks de memória de Letta mostraram ferramentas de sistema de arquivos superando alternativas. LangChain’s trabalho de engenharia de contexto lançou as bases.

Mas em janeiro de 2026 a conversa se intensificou. Vercel publicado algumas avaliações. Harrison Chase compartilhou como LangSmith Agent Builder implementa memória. Jerry Liu declarou, “Arquivos são tudo que você precisa.” “FUSE é tudo que você precisa” clique em Notícias do Hacker. Recurso Skills do Antrópico, que empacota recursos do agente como pastas de arquivos markdownsilenciosamente reforçou o mesmo padrão.

“O debate nunca foi ‘sistema de arquivos ou banco de dados’; sempre foram os dois, nas camadas certas.”

Por que a atenção renovada? Agentes de codificação como Cursor, Claude Code e Windsurf demonstraram que as interfaces do sistema de arquivos funcionam muito bem – pelo menos para código. A questão é se esse sucesso se generaliza.

O apelo é compreensível. Um agente capaz pode precisar interagir com APIs REST, bancos de dados SQL, armazenamentos de vetores, consoles de nuvem, sistemas de arquivos, navegadores da Web e usuários humanos, cada um com protocolos e convenções diferentes. São muitas interfaces para conciliar.

Mas quando você observa como essas equipes realmente constroem seus sistemas, surge uma imagem diferente. Eles estão usando bancos de dados subjacentes – e estão sendo extremamente transparentes sobre o porquê.

Qual é a diferença entre a interface do sistema de arquivos e o armazenamento do sistema de arquivos?

Harrison Chase é transparente sobre a arquitetura do LangSmith Agent Builder em sua postagem no X: Os agentes veem uma interface de sistema de arquivos, mas o armazenamento real é um banco de dados. Como ele explicou em seu aprofundamento técnico no sistema de memória do Agent Builder:

“Os LLMs são ótimos para trabalhar com sistemas de arquivos, mas do ponto de vista da infraestrutura, é mais fácil e eficiente usar um banco de dados.”

Isto não é uma contradição. É uma escolha arquitetônica deliberada:

• Interface = O que o agente vê e interage
• Armazenar = Onde os dados realmente persistem

Estas são decisões independentes. Depois de reconhecer essa distinção, a questão muda de “sistema de arquivos ou banco de dados?” para “qual interface para qual tipo de agente, apoiada por qual armazenamento para quais requisitos?”

O que uma interface de sistema de arquivos realmente fornece aos agentes de IA?

Antes das abstrações do MCP e do sistema de arquivos, conectar um agente a dados externos significava definir esquemas de ferramentas personalizados para cada fonte de dados. Cada endpoint precisa de documentação. Cada esquema precisa de exemplos. Como Tony Powell de Arize observa: “No momento em que o LLM aprende como usar uma API específica, você já engoliu um monte de sua janela de contexto… Você está gastando milhares de tokens em educação em vez de raciocínio.”

A interface do sistema de arquivos oferece uma abordagem diferente: um pequeno conjunto de operações universais que os LLMs já entendem a partir de seus dados de treinamento. Este é o antigo Unix Filosofia “tudo é um arquivo” da década de 1970apenas reaparecendo em uma nova escala. À medida que o Unix reduzia diversas interfaces de dispositivos em operações de arquivos, e o DevOps reduzia a infraestrutura em artefatos de código, a IA agente está transformando diversas fontes de dados em operações de sistemas de arquivos.

As operações principais:

• Lista — Mostrar o conteúdo de um local (como ls)
• Ler — Obtenha o conteúdo de um arquivo (como cat)
• Escrever — Crie ou atualize um arquivo
• Procurar — Encontre arquivos por nome ou conteúdo (como find e grep)

O benefício prático é a eficiência simbólica: a educação já aconteceu durante o pré-treinamento. Como observou Pekka Enberg, da Turso, em seu postar no AgentFS: “Dê a um agente acesso a grep, sed, awk, cat e git, e ele se tornará excessivamente capaz e eficaz, não exigindo ferramentas personalizadas.”

Dust.tt estendeu isso criando “sistemas de arquivos sintéticos“- projetando APIs e bancos de dados em hierarquias semelhantes a sistemas de arquivos. Canais Slack tornam-se diretórios. Espaços de trabalho de noção tornam-se pastas. Os dados subjacentes residem em APIs e bancos de dados, mas o agente vê uma árvore de arquivos coerente.

Como as interfaces agente-dados evoluíram de ferramentas personalizadas para operações padronizadas de sistemas de arquivos.

Onde a interface do sistema de arquivos funciona bem para agentes de IA?

O padrão de sistema de arquivos demonstrou valor claro para agentes de codificação.

Isso não deveria ser surpreendente. O código já está organizado como arquivos em diretórios. Os desenvolvedores pensam em termos de sistema de arquivos. Mapa de operações naturalmente: leia um arquivo, edite um arquivo, pesquise na base de código. Ferramentas como Cursor, Claude Code e Windsurf usam esse padrão.

A equipe Letta forneceu um contexto importante em sua análise comparativa: “Os agentes hoje são extremamente eficazes no uso de ferramentas de sistema de arquivos, em grande parte devido à otimização pós-treinamento para tarefas de codificação de agentes.” A frase-chave é “tarefas de codificação agentica” – é aqui que existem os dados de treinamento.

Onde a interface do sistema de arquivos se encaixa bem:

• Agentes de codificação (o código já está em arquivos)
• Processamento de documentos (mapeamento de documentos para arquivos)
• DevOps e infraestrutura (configurações são arquivos)
• Navegação na base de conhecimento (hierarquias funcionam)

Onde a interface do sistema de arquivos falha para os agentes de IA?

O padrão do sistema de arquivos não é universal. Vários contextos expõem suas limitações, e os profissionais que tentaram isso foram sinceros sobre as falhas.

Consultas de dados estruturados

Você não pode encontrar “encontrar todos os clientes que encomendaram o produto X, mas não o produto Y no terceiro trimestre”. Para consultas envolvendo junções, agregações ou travessia de gráficos, as operações do sistema de arquivos são estranhas.

Benchmarks da Vercel deixe esse ponto claramente. Quando eles testaram as operações do sistema de arquivos em consultas de banco de dados para dados estruturados:

Conclusão: para dados estruturados com esquemas claros, linguagens de consulta específicas — seja SQL, API de consulta do MongoDB ou outras interfaces de banco de dados — superam consistentemente as operações do sistema de arquivos.

Desempenho em escala

A abstração do sistema de arquivos esconde um problema crítico: cada operação de arquivo pode se tornar uma chamada de API. Um praticante do Hacker News descreve abandonar totalmente a abordagem: “Se você usar o grep (via fuse), acabará abrindo muitos arquivos, o que resultará em buscas para alguma API, e será lento… Chegamos ao ponto de implementar essa ideia no Rust para realmente testá-la e, no final das contas, ela foi descartada porque, bem, é uma merda.”

Jerry Liu, do LlamaIndex, faz uma observação semelhante em “Arquivos são tudo que você precisa“: “Os agentes de codificação já estão usando ferramentas CLI como principal meio de pesquisa de arquivos, mas observamos que essa abordagem não se adapta a coleções massivas de documentos (1k-1m+).”

A questão é fundamental: os sistemas de arquivos não possuem a indexação que torna as consultas ao banco de dados rápidas.

Ambientes sem servidor e nativos da nuvem

A metáfora do sistema de arquivos pressupõe um sistema de arquivos, mas muitos ambientes de produção — como funções sem servidor, agentes baseados em navegador e computação de ponta — não possuem armazenamento local persistente.

Tipos de agentes não codificadores

Os agentes de atendimento ao cliente precisam de dados estruturados do cliente. Os agentes analíticos precisam de consultas ao banco de dados. A vantagem dos dados de treinamento que torna a interface do sistema de arquivos poderosa para agentes de codificação pode não ser transferida para esses domínios.

Por que as equipes líderes estão usando armazenamento de banco de dados para memória do agente?

Independentemente do padrão de interface escolhido, as equipes líderes convergiram para o armazenamento de banco de dados abaixo:

As razões são consistentes:

• Coordenação multiagente requer transações. Quando vários agentes compartilham estado, você precisa de garantias ACID.
• Escala exige indexação. Grep funciona para pequenas coleções; os sistemas de produção precisam de otimização de consultas no nível do banco de dados.
• Governança requer trilhas de auditoria. As implantações empresariais precisam de rastreabilidade sobre quem acessou o quê, quando e por quê.
• Recuperação híbrida são apostas de mesa. Os sistemas de produção precisam de pesquisa vetorial, pesquisa de texto completo e consultas estruturadas trabalhando juntas.

Bancos de dados de documentos com pesquisa vetorial integrada são particularmente adequados aqui. Uma plataforma que combina armazenamento flexível de documentos, incorporação de vetores e pesquisa de texto completo elimina a necessidade de unir vários sistemas.

Como os desenvolvedores devem escolher a interface e o armazenamento da memória do agente?

A interface do sistema de arquivos não é a única opção. E para alguns tipos de agentes, não é o melhor.

Bancos de dados de documentos como o MongoDB Atlas armazenam dados como documentos JSON, que já têm uma estrutura “semelhante a um arquivo”. Com pesquisa de vetor nativopesquisa de texto completo e pipelines de agregação integrado, os agentes podem consultar diretamente via Ferramentas MCP ou API – nenhuma camada de tradução do sistema de arquivos é necessária. Para agentes analíticos, agentes de atendimento ao cliente ou qualquer fluxo de trabalho que envolva consultas de dados estruturados, esse caminho direto pode superar a interface do sistema de arquivos.

A interface do sistema de arquivos brilha quando os dados de treinamento do agente tornam ls e grep mais confiáveis ​​do que ferramentas personalizadas, principalmente agentes de codificação. Mas essa vantagem dos dados de treinamento não se aplica a todos os domínios.

(DIAGRAMA 3: A Arquitetura Desacoplada)

A arquitetura emergente separa as opções de interface e armazenamento, permitindo que as equipes otimizem cada camada de forma independente.

As verdadeiras perguntas a serem feitas:

• Que tipo de agente? Codificação, documento, análise, atendimento ao cliente?
• Qual interface se adapta a esse tipo? Sistema de arquivos para agentes de codificação, MCP/consultas diretas para dados estruturados.
• Quais requisitos de armazenamento? Escala, coordenação multiagente, governança, padrões de recuperação?
• Você precisa de uma camada de tradução? Ou o agente pode consultar diretamente o banco de dados?

A arquitetura está convergindo. Aqui está o que isso significa para os desenvolvedores

O enquadramento “sistema de arquivos versus banco de dados” obscurece mais do que revela. As equipes que constroem sistemas de agentes de produção já superaram esse debate. Eles separaram a interface do armazenamento e estão usando bancos de dados subjacentes, independentemente da interface que expõem aos agentes.

“Dados estruturados, fluxos de trabalho sem codificação e ambientes sem servidor precisam de abordagens diferentes.”

A interface do sistema de arquivos funciona bem para agentes de codificação e navegação de documentos, onde existem dados de treinamento e a metáfora se ajusta. Mas não é universal. Dados estruturados, fluxos de trabalho sem codificação e ambientes sem servidor precisam de abordagens diferentes.

A questão nunca foi “sistema de arquivos ou banco de dados?” Era sempre ambos – nas camadas certas.

Mikiko Bazeley atua como defensora do desenvolvimento da equipe com foco em sistemas agentes e IA aplicada, posicionando o MongoDB como a memória central, estado e camada de coordenação para aplicativos inteligentes de próxima geração.

Leia mais de Mikiko Bazeley