Por que as ferramentas de programação com IA não compartilham memória?

Toda ferramenta de programação com IA parece ter sua própria forma de lembrar das coisas. Uma guarda anotações em um arquivo Markdown na raiz de um repositório. Outra grava em uma pasta de memórias designada. Uma terceira mantém fatos sobre cada projeto nos servidores de seu host. Nenhuma consegue ler o que as outras escreveram, e uma lição aprendida por um agente de integração contínua geralmente permanece com esse agente.

Essa fragmentação é o problema central que um desenvolvedor expõe em um ensaio recente, e sua resposta é um padrão compartilhado. Ele criou o LoreKit, uma ferramenta de memória de código aberto, e afirma que sua proposta não é uma promoção desse produto. O ponto, segundo ele escreve, é que o setor chegou ao momento de concordar com um formato comum, e que outro setor tecnológico já mostrou como fazer isso.

Ele identifica quatro grandes famílias de formatos de memória em uma máquina típica de desenvolvedor: arquivos de instruções, como AGENTS.md e CLAUDE.md; arquivos gerenciados por agentes, como a ferramenta de memória da Anthropic; fatos de repositório hospedados, como os do GitHub Copilot; e servidores de memória que mantêm um grafo de conhecimento em JSONL. Cada um é razoável isoladamente. Juntos, argumenta ele, continuam reconstruindo a mesma ideia: uma anotação que um agente deixa para o seu eu futuro, armazenada em algum endereço e presumivelmente válida por um certo tempo.

O autor aponta o volume de projetos independentes como evidência de que a necessidade é real. Publicações em comunidades de desenvolvedores descrevem com regularidade uma nova camada de memória criada para um agente específico, cada uma com seu próprio armazenamento, esquema e interface de ferramenta. Cada nova entrada, porém, acrescenta mais um formato que nenhum outro consegue ler.

Como a observabilidade ganhou uma linguagem comum

A memória de agentes de IA poderia seguir o modelo do OpenTelemetry?

O ensaio compara isso à indústria de observabilidade antes de 2019. Cada fornecedor lançava seu próprio agente, biblioteca de instrumentação e formato de dados, de modo que trocar de provedor significava instrumentar o código novamente. Dois projetos abertos, OpenTracing e OpenCensus, tentaram resolver o problema e competiam entre si. Em 2019, eles se fundiram no OpenTelemetry.

Segundo o autor, a chave foi o acordo sobre aquilo em que as empresas deixariam de competir. Isso incluiu um modelo de dados compartilhado, que define o que são span, métrica e registro de log; convenções semânticas com nomes comuns; um único protocolo de transmissão; e implementações de referência, como kits de desenvolvimento de software compartilhados e um coletor. Os fornecedores continuaram competindo em armazenamento, consulta e análise. Os usuários instrumentam seu código uma única vez. O autor, que trabalha diariamente com o OpenTelemetry na Dash0, afirma que esse acordo explica por que muitas ferramentas conseguem ler os dados umas das outras.

Ele argumenta que a memória de agentes está em um ponto semelhante. Os formatos são novos o suficiente para mudar, e já existe um espaço neutro para padrões de agentes. O Model Context Protocol e o AGENTS.md estão ambos sob a Agentic AI Foundation, da Linux Foundation.

O que uma especificação compartilhada poderia abranger

O que um formato compartilhado de memória de IA incluiria?

O ensaio esboça um formato de registro construído em torno de alguns campos: onde uma memória se aplica, um identificador único, uma chave, o tipo de memória, quem a escreveu, como ela deve ser lida, quando expira e quaisquer atributos extras de que uma ferramenta precise. Ele enfatiza que o exemplo ilustra o modelo de dados, e não é uma proposta formal de nomes de campos.

Em torno desse registro, o autor propõe três camadas que espelham o OpenTelemetry. A primeira são convenções compartilhadas, incluindo níveis de endereço padronizados, tipos de memória e espaços de nomes de atributos mantidos em um registro versionado. A segunda é um pequeno contrato de operações, como gravar, ler, listar, buscar e arquivar, exposto pelo Model Context Protocol. Muitos servidores de memória já oferecem uma interface desse tipo, observa ele, mas cada um expõe ferramentas diferentes com significados diferentes. A terceira são testes de conformidade no lugar de uma implementação de referência, verificando se um registro sobrevive a um ciclo completo de ida e volta, se atributos desconhecidos sobrevivem a uma reescrita e se a expiração funciona conforme descrito.

Armazenamento, ranqueamento, embeddings e interfaces de usuário ficariam fora do escopo. O autor afirma que é nesses pontos que as ferramentas devem competir. Ele também defende que a especificação deve viver em um espaço neutro, e não no repositório de seu projeto nem no de qualquer fornecedor.

O ensaio reconhece uma questão estrutural que um padrão precisaria resolver: quem escreve uma memória. Em alguns sistemas é uma pessoa, em outros é o modelo, e em alguns um serviço extrai fatos das conversas. O autor sugere que um padrão não deveria escolher uma abordagem, mas registrar qual delas se aplica, para que os leitores saibam o quanto podem confiar no que leem.

Perguntas em aberto e objeções

O autor trata de várias objeções. Ele admite que um criador de ferramentas naturalmente favoreceria um padrão moldado conforme a sua própria, e diz que o LoreKit deveria adotar um desenho compartilhado diferente caso surja um. Argumenta que o Model Context Protocol padroniza a chamada, mas não o registro. Sobre segurança, reconhece que a memória compartilhada pode ser um canal para injeção de prompt e afirma que uma especificação deveria tornar visível o autor de cada memória, permitir assinaturas e possibilitar que os registros apontem para o código de que dependem.

Ele lista quatro perguntas que diz não conseguir responder ainda. Entre elas, quais níveis de endereço um padrão deveria definir, se o esquecimento deveria ser o comportamento padrão, se um registro deveria estar vinculado ao código de que depende e quem deveria coordenar o trabalho: um grupo de trabalho, uma fundação ou um rascunho ao qual as pessoas enviariam alterações.

Ele convida os criadores das ferramentas que compara e os autores de propostas existentes a trocar ideias. O ensaio informa que o esquema e o formato em disco do LoreKit estão disponíveis sob licença MIT como uma contribuição concreta para a discussão.

Este artigo foi escrito com a assistência de IA.
News Factory APP - notícias agênticas para impulsionar seu SEO e AEO.