🤖 AI

Governed Shared Memory for Multi-Agent LLM Systems

Este artigo apresenta o MemClaw, um serviço de memória multi-inquilino de produção que implementa primitivas de memória compartilhada governadas para abordar modos críticos de falha em sistemas de LLM multiagentes, enquanto utiliza o harness de avaliação ArgusFleet para revelar desafios arquiteturais do mundo real, como imposição de escopo assimétrica e conflitos de ordenação de pipeline, que abordagens puramente de design frequentemente negligenciam.

Autores originais: Yanki Margalit, Nurit Cohen-Inger, Erni Avram, Ran Taig, Oded Margalit

Publicado 2026-06-24

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Yanki Margalit, Nurit Cohen-Inger, Erni Avram, Ran Taig, Oded Margalit

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine uma equipe de assistentes de IA trabalhando juntas em um projeto massivo, como uma equipe de construção digital construindo um arranha-céu. No passado, cada assistente tinha seu próprio caderno privado. Se o Assistente A anotasse uma medição, o Assistente B não conseguia vê-la, a menos que alguém fisicamente entregasse o caderno a ele.

Este artigo argumenta que, à medida que as equipes de IA crescem, elas não podem mais ter apenas cadernos privados. Elas precisam de um quadro branco compartilhado e governado onde todos possam escrever e ler, mas com regras estritas sobre quem pode ver o quê, quando e como.

Os autores chamam este sistema de "Memória Compartilhada Governada" (Governed Shared Memory). Eles construíram uma versão real dele chamada MemClaw e o testaram com um testador robô chamado ArgusFleet para ver se ele realmente funciona no mundo real.

Aqui está o detalhamento de suas descobertas usando analogias simples:

1. O Problema: O "Velho Oeste" da Memória Compartilhada

Nos velhos tempos, a memória da IA era apenas sobre lembrar a conversa (como um histórico de chat). Mas agora, com frotas de agentes, a memória é como o estado operacional.

A Analogia: Imagine um hospital. Uma enfermeira (Agente A) atualiza as informações de alergia de um paciente. Um médico (Agente B) precisa ver essa atualização imediatamente. Se o médico vir a informação antiga, o paciente pode se machucar.
O Desafio: Não se trata apenas de encontrar a informação (recuperação); trata-se de governança. Quem tem permissão para vê-la? A informação é antiga ou nova? Quem a escreveu? Se duas pessoas escreverem coisas conflitantes, qual delas vence?

2. Os Quatro "Desastres" que Eles Previniram

Os autores identificaram quatro maneiras pelas quais este sistema poderia falhar, como quatro maneiras diferentes de um escritório compartilhado dar errado:

Vazamento Não Autorizado: Um zelador (Agente A) acidentalmente lê as notas privadas do salário do CEO.
Propagação Obsoleta: O zelador lê as notas do CEO, mas as notas são do ano passado, então o zelador age com base em informações desatualizadas.
Persistência de Contradição: Duas pessoas escrevem no quadro branco ao mesmo tempo. Uma escreve "Reunião às 14h", a outra escreve "Reunião às 15h". Ambas permanecem no quadro, confundindo a todos.
Colapso de Proveniência: Alguém apaga uma nota e escreve uma nova, mas não há registro de quem a escreveu ou quando. É como um mistério: "Quem alterou o cronograma?"

3. A Solução: O "Quadro Branco Governado" (MemClaw)

Eles construíram o MemClaw, um sistema que atua como um quadro branco inteligente que impõe regras.

Recuperação Escopada (Scoped Retrieval): É como um segurança em uma porta. Se você não tiver o crachá correto (permissão), você nem sequer consegue ver a sala, muito menos ler as notas.
Supressão Temporal (Temporal Supersession): Se alguém escrever uma nota nova, a antiga é automaticamente riscada e marcada como "Obsoleta".
Rastreamento de Proveniência: Cada nota possui uma assinatura digital dizendo exatamente quem a escreveu e quando.
Propagação de Política: Controla como as notas se movem entre diferentes grupos (frotas) para que segredos não vazem.

4. O Teste: "ArgusFleet" (O Inspetor Robô)

Eles não apenas adivinharam se funcionava; eles construíram o ArgusFleet, um testador robô que tentou quebrar o sistema. Ele agiu como um auditor de segurança tentando entrar em áreas restritas ou encontrar notas antigas e conflitantes.

O que eles descobriram (As Boas Notícias):

O Teste "Quem Escreveu Isso": Eles criaram 50 cadeias de notas (como uma árvore genealógica de informações). O sistema rastreou perfeitamente cada nota até o seu autor original, mesmo em cadeias profundas, em menos de um segundo.
O Teste de "Segredos": Quando tentaram contrabandear uma nota de uma equipe para outra, o sistema a bloqueou 100% das vezes. Sem vazamentos.
O Teste de "Velocidade": Quando uma nota era escrita, ela se tornava visível para as pessoas certas quase instantaneamente (cerca de 0,8 segundos). Não era uma atualização lenta ou "eventual"; era imediata.

O que eles descobriram (As Más Notícias e Correções):

O Bug da "Porta dos Fundos": Eles encontraram uma brecha na segurança. Se você soubesse o número de ID específico de uma nota, poderia pegá-la diretamente, mesmo que não devesse vê-la. O sistema verificava sua identidade para a função de busca, mas ignorava isso para a função de pegar direto.
- A Correção: Eles corrigiram esse buraco imediatamente. Agora, mesmo que você tenha o número de ID, o sistema verifica seu crachá antes de permitir que você pegue a nota.
O Bug do "Porteiro Confuso": O sistema tinha dois seguranças. Um verificava se uma nota era uma "duplicata" (síncrona) e o outro verificava se era uma "contradição" (assíncrona). Às vezes, o primeiro segurança parava uma nota porque ela parecia muito semelhante a uma antiga, impedindo que o segundo segurança a visse como uma contradição que precisava ser resolvida.
- A Correção: Eles perceberam que a ordem das operações estava errada. O sistema precisa verificar contradições antes de verificar duplicatas simples.

5. A Grande Conclusão

O artigo conclui que construir a memória de IA para equipes não é apenas sobre tornar a IA "mais inteligente" ou dar a ela uma janela de memória maior. É um problema de engenharia de sistemas.

É como construir um banco de dados para um banco, não apenas um diário para uma pessoa. Você precisa de regras estritas, verificações de identidade e relógios sincronizados. Se você tratar a memória da IA como um simples histórico de chat, o sistema acabará vazando segredos, espalhando mentiras ou confundindo os agentes.

Em resumo: Para fazer as equipes de IA trabalharem juntas com segurança, precisamos parar de tratar a memória como uma conversa e começar a tratá-la como um banco de dados seguro e governado.

Resumo Técnico: Memória Compartilhada Governada para Sistemas de LLM Multi-Agente

Declaração do Problema

O artigo argumenta que os sistemas de memória de IA estão transitando de históricos conversacionais isolados e de agente único para um estado operacional compartilhado utilizado por frotas de agentes cooperativos. Neste cenário multi-agente, a memória não é mais meramente um problema de recuperação focado em relevância semântica ou compressão de contexto longo. Em vez disso, torna-se um probleente de sistemas distribuídos governados.

As arquiteturas tradicionais de memória de agente único falham em implantações de escala de frota porque carecem de mecanismos para:

Acesso Escopado: Determinar quais agentes estão autorizados a recuperar memórias específicas com base em função, inquilino (tenant) ou frota.
Correção Temporal: Resolver fatos conflitantes e garantir que dados obsoletos sejam superados.
Proveniência: Rastrear as memórias recuperadas até seu escritor original e histórico de derivação.
Sincronização: Garantir a propagação consistente do estado através das fronteiras dos agentes.

Os autores identificam quatro modos de falha específicos que surgem quando essas propriedades de sistemas distribuídos são ignoradas:

Vazamento Não Autorizado: Agentes recuperando memória fora de seu escopo autorizado.
Propagação Obsoleta: Agentes operando em estados desatualizados devido a atrasos de sincronização.
Persistência de Contradição: Fatos conflitantes coexistindo sem resolução.
Colapso de Proveniência: Incapacidade de rastrear a origem ou o histórico de modificação de uma memória.

Metodologia e Arquitetura

Estrutura Teórica

Os autores formalizam o Problema da Memória de Frota como uma tupla $F = (A, M, G, P, T)$ , representando Agentes, substrato de Memória, Governança, Proveniência e ordenação Temporal. Eles definem operações de memória não como artefatos imutáveis, mas como transições de estado, exigindo que a recuperação satisfaça restrições de autorização, frescor e resolução de contradição, juntamente com a similaridade semântica.

Implementação do Sistema: MemClaw

A arquitetura é instanciada no MemClaw, um serviço de memória multi-inquilino de produção. Principais características incluem:

Recuperação Escopada: Objetos de memória carregam escopos de visibilidade (Local do Agente, Compartilhado com a Equipe, Global do Inquilino, Restrito).
Resolução Temporal: Objetos de memória incluem carimbos de data/hora (timestamps), links de supersessão e marcadores de contradição.
Grafo de Proveniência: Cada objeto armazena a identidade do escritor, o sistema de origem e o histórico de derivação.
Propagação Governada por Política: O acesso é controlado via uma escada de níveis de confiança e aplicação de política explícita.
API: Uma API REST que suporta escritas (com triplas RDF opcionais), busca semântica e upserts de entidades.

Estrutura de Avaliação: ArgusFleet

Para avaliar o sistema, os autores desenvolveram o ArgusFleet, uma estrutura de avaliação em Python de código aberto. Ela exercita a API ao vivo do MemClaw através de quatro experimentos distintos, cada um visando um modo de falha específico:

Experimento de Vazamento: Sonda a aplicação de escopo fazendo com que agentes tentem recuperar segredos (escopados por frota e por agente) que não deveriam ver.
Experimento de Contradição: Testa a supersessão temporal escrevendo fatos conflitantes e verificando se o sistema marca corretamente as linhas antigas como desatualizadas.
Experimento de Proveniência: Constrói cadeias de derivação para verificar se o sistema pode reconstruir a linhagem completa de um fato e atribuir corretamente o escritor.
Experimento de Propagação: Mede taxas de visibilidade e latência de escrita-para-visibilidade para garantir que agentes autorizados vejam atualizações enquanto agentes não autorizados não as vejam.

Principais Resultados

A avaliação foi conduzida em um inquilino de produção real do MemClaw. Os resultados destacam tanto a eficácia dos primitivos quanto lacunas arquiteturais específicas que foram identificadas e remediadas durante o estudo.

1. Proveniência

Resultado: Reconstrução completa de ponta a ponta de todas as 50 cadeias de derivação de profundidade quatro.
Métricas: 100% de completude, 100% de precisão de identidade do escritor e 100% de fidelidade de profundidade.
Latência: Latência sub-segundo por salto (mediana de 291 ms, p95 de 491 ms).

2. Propagação

Resultado: Alta visibilidade intra-frota e zero vazamento entre frotas.
Métricas: 97,5% de visibilidade para leitores irmãos da frota (117/120 sondagens); 0% de vazamento para leitores de frotas estrangeiras (0/80 sondagens).
Latência: Sob o modo de escrita "forte", a janela de escrita-para-visibilidade é efetivamente imediata (mediana de 0,83 s), correspondendo a uma ida e volta de busca. O custo de consistência é pago na latência de escrita, não como um atraso de visibilidade de leitura.

3. Tratamento de Contradição

Resultado: Supersessão correta quando ambas as escritas conflitantes são admitidas.
Métricas: 100% de taxa de detecção (90/90) para casos onde ambas as escritas foram admitidas.
Ressalva: A taxa de detecção geral foi de 49% (98/200) porque um portão de quase-duplicidade síncrono rejeitou muitas escritas contraditórias antes que o detector de contradição assíncrono pudesse processá-las.

4. Vazamento (Aplicação de Escopo)

Achado Inicial: A aplicação de escopo foi bimodal. Enquanto o isolamento ao nível do inquilino se manteve, o escopo de sub-inquilino (frota/agente) não foi aplicado no caminho direto GET-by-id. Um agente com uma credencial escopada poderia recuperar linhas de outras frotas se possuísse o ID da memória.
Remediação: A lacuna foi revelada e corrigida durante o estudo. Testes pós-remediação confirmaram que o GET-by-id agora aplica corretamente o escopo de frota/agente e a escada de confiança.
Caminho de Busca: A busca semântica honrou parcialmente os filtros de frota, mas ainda vazou cerca de 44% das linhas de outras frotas devido ao ranking de similaridade de embedding sobrepor os filtros de política.

Achados Arquiteturais e Discussão

O artigo destaca três insights arquiteturais críticos derivados da avaliação ao vivo:

Aplicação de Escopo Bimodal: O estudo revelou que a aplicação de escopo não era uniforme entre os caminhos da API. O manipulador GET-by-id inicialmente descartava identidades de agentes resolvidas, aplicando apenas as fronteiras do inquilino. Isso demonstra que a governança deve ser implementada explicitamente em cada caminho de recuperação, não apenas na busca.
Deduplicação vs. Contradição: Um problema estrutural foi identificado onde um portão de quase-duplicidade síncrono (baseado em similaridade de embedding) precedeu o detector de contradição assíncrono. Como as contradições naturais frequentemente resultam em textos quase idênticos, o portão as rejeitou antes que o sistema pudesse aplicar regras de supersessão lógica. Os autores sugerem reordenar o pipeline ou ampliar o limite de deduplicação para escritas de triplas RDF.
Propagação com Bloqueio de Privilégio: A implementação atual funde a propagação normal interna da frota com a re-alocação administrativa ao exigir um alto nível de confiança (trust_level ≥ 3) para toda redistribuição. Os autores defendem uma superfície de política mais granular para distinguir entre a propagação padrão de fluxo de trabalho e a migração privilegiada.

Significância e Alegações

O artigo afirma que a recuperação de contexto longo sozinha é insuficiente para a memória multi-agente em produção. A transição para sistemas de escala de frota exige abstrações de nível de sistema para governança, sincronização e correção temporal.

Contribuição 1: Uma formalização do problema da memória de frota, identificando modos de falha específicos (vazamento, obsolescência, contradição, colapso de proveniência).
Contribuição 2: Uma arquitetura de referência e implementação (MemClaw) que trata a memória como estado operacional governado, em vez de um índice de recuperação.
Contribuição 3: Uma avaliação empírica (ArgusFleet) demonstrando que, embora os primitivos como proveniência e propagação possam funcionar corretamente, a avaliação ao vivo é necessária para expor lacunas de aplicação e falhas de ordenação de pipeline que tratamentos baseados apenas em design não detectam.

Os autores enfatem que seus resultados negativos (a lacuna de escopo e a interação dedup/contradição) são centrais para a contribuição, provando que a memória compartilhada governada requer a mesma atenção rigorosa à consistência e controle de acesso historicamente dedicada a bancos de dados distribuídos.