Memória compartilhada de agentes tem um problema de access control, e ninguém resolveu

Aqui vai uma afirmação à qual eu teria resistido um ano atrás: a parte difícil de agent memory nunca foi fazer um agente lembrar. É decidir o que acontece quando cinquenta agentes lembram a mesma coisa errada. Memória single-agent é problema de convenience. No momento em que memory é compartilhada por um time, vira problema organizacional de access control, com semantics de correction, deletion e conflict, exatamente as features em que os produtos atuais são mais fracos.

Dois vendors lançaram respostas em poucas semanas. O release Team Memory da Tencent Cloud, que cobri em artigo separado no lançamento, colocou como open source um governed memory hub em 13 de agosto. Asana roda silenciosamente desde o fim do ano passado a versão fechada e platform-bound, Agentic Work Management, com seus AI Teammates. Este texto não é outro announcement recap. É a comparação que anúncios pulam: o que cada sistema realmente faz quando uma memória precisa ser corrigida, apagada ou adjudicated, e quem dentro da organização decide.

Principais conclusões - Shared memory transforma um fact errado da irritação de um user em herança de todo agent. Governance layer, não retrieval quality, vira a feature estrutural. - Team Memory da Tencent oferece access model mais explícito, quatro visibility tiers, per-agent loadouts, private by default, mas sem processo documentado de correction ou expiry para fact já consumido por outros agents. - Agentic Work Management da Asana resolve corretamente confidential leak herdando permissions existentes do Work Graph, mas memory vive dentro da plataforma Asana e correction semantics são opacas. - Graphiti da Zep é única implementation mainstream com resposta principled a stale facts: invalida em vez de apagar, mantendo history. Mas governa memória de um agent, não de um time. - Ninguém entrega conflict resolution quando dois agents escreveram facts contraditórios sobre mesma coisa. Hoje a pergunta é respondida por "retrieval ranking", que não é resposta.

O que aconteceu

Nas duas primeiras semanas de agosto, shared agent memory saiu de research topic para shipping category. Dois eventos servem de âncora:

• Em 13 de agosto, Tencent Cloud anunciou Team Memory, extensão em escala de time do projeto open source TencentDB Agent Memory. Conversations, documents, code graphs e distilled skills viram governed team assets com owners, versions e visibility model de quatro níveis, montados por agent role.

• Uma semana antes, fireside chat da VentureBeat com Arnab Bose, CPO da Asana, deu primeiro detalhe técnico real sobre Agentic Work Management, AWM, sistema shared-memory por trás de AI Teammates da Asana, que Asana diz já estar em production com clientes como FedEx.

Ao redor fica camada open source single-agent memory, Mem0, Graphiti da Zep, Letta, onde ainda vive maior parte da infraestrutura real de memória dos times. Shift interessante é todos agora serem avaliados pelas mesmas quatro perguntas. Quem pode ler uma memória? O que acontece quando está errada? O que acontece quando é apagada? E quando duas memórias discordam?

Tencent Cloud lançou Team Memory, governed shared-memory hub para agent teams, em 13 de agosto de 2026, segundo anúncio. Dias antes, CPO da Asana detalhou Agentic Work Management, shared-memory system por trás de AI Teammates, em entrevista VentureBeat publicada 3 de agosto de 2026.

As quatro perguntas, comparadas

Framing preguiçoso desta categoria é "Tencent versus Asana", open source chinês contra SaaS americano. Perde formato real. Divisão verdadeira é entre sistemas que governam memory como documents com permissions e sistemas que governam memory como facts com lifecycles, e nenhum lado tem as duas metades.

Leia linhas correction e conflict e padrão é desconfortável: as duas cells que mais importam são exatamente as duas que ninguém preencheu.

A própria documentação Team Memory distingue "who can use it, which version is valid, and which Agent should receive it", segundo documentação Tencent reportada pela VentureBeat. Graphiti da Zep invalida stale facts em vez de apagar, segundo repository. Nem Tencent nem Asana documentam publicamente correction ou conflict-resolution process para shared memories já consumidas por outros agents.

O que cada sistema faz certo

Contribuição Tencent é access model, merece crédito por ser explícita onde outros são vagos. Todo memory asset carrega owner, version, visibility tier, private, team, restricted, agent; novos assets default private; agents recebem "Agent Loadout" adequado ao role, em vez de acesso livre ao hub. Scout agent fazendo research recebe market-analysis assets; Builder agent recebe code graph. É memory como organizational infrastructure com lock policy e, como coverage VentureBeat notou, documentação traça linha contra plain RAG: retrieval responde o que pode ser encontrado, Team Memory também quem pode usar.

Contribuição Asana é leak boundary, e exemplo deveria estar em todo governance deck. Se AI Teammate de executive constrói memory em projeto M&A confidential, colleague que conversa depois com mesmo Teammate não pode herdar context. Resposta de Bose, segundo entrevista VentureBeat, é AWM estar sobre Work Graph de 18 anos da Asana, então memory access herda mesmas permissions do trabalho: se você não pode ver projeto, memory do agent sobre projeto também não é sua. Problema realmente difícil resolvido recusando novo permission system, funciona porque Asana já sabe quem vê o quê. Asana fala de team-wide memory e enterprise controls desde anúncio AI Teammates em setembro passado, mas M&A boundary é primeiro mecanismo concreto.

Contribuição Graphiti é lifecycle. Maioria dos sistemas trata fact errado como deletion problem. Graphiti trata como time problem: quando fact deixa de ser verdade, edge é invalidado e timestamped, não apagado, então agent responde "o que é verdade agora" e "o que era verdade em março". Para anything envolvendo audit, é primitive certa, e notável vir do mundo single-agent, não dos novos team systems.

Tencent entrega access tiers mais explícitos com sharing private-by-default; Asana scope agent memory a existing Work Graph permissions para confidential-project memory não leak a colegas sem acesso, segundo Asana CPO Arnab Bose na VentureBeat; Graphiti da Zep invalida stale facts com timestamps em vez de apagar, segundo repository.

O meio não resolvido: correction, conflict, propagation

Agora parte que launch narratives pulam. Fact errado em single-agent memory custa a um user correction repetida. Fact errado em shared store propaga para todo agent que leu antes de alguém notar, e nenhum shipping system documenta processo. Coverage do launch pela VentureBeat coletou practitioners flagging gap em horas: correction e expiry para consumed facts, decisão do que nunca deveria ser escrito, caso em que agents de dois teammates escreveram facts contraditórios sobre mesmo module e shared store precisa escolher winner. Single-agent memory drift devagar. Shared memory drift rápido, porque stale write chega a pessoas que nunca viram session que produziu.

Não é implementation nitpick que point release corrige. Paper de março de 2026, "Governed Memory: A Production Architecture for Multi-Agent Workflows", identifica governance fragmentation e silent quality degradation sem feedback loops como riscos estruturais de shared multi-agent memory, modo acadêmico educado de dizer failure mode está baked into architecture, não vendor. Security framing agrava: guidance agentic OWASP nomeia memory poisoning como attack class distinta, e shared store é shared blast radius. Permission inheritance Asana e private-by-default tiers Tencent limitam quem pode ler poisoned/stale memory. Nenhum trata o que acontece depois que bad one foi lido.

Minha leitura: correction/conflict resolution acaba funcionando como em todo shared information system, socialmente. Named owner por asset, review habit, expiry norm. Tools vencedoras serão as que tornam processo social fácil, não as que prometem automatizar para fora. Vi filme com wikis, CRMs, feature flags. Governance features são produto, mesma conclusão do agent governance piece, e razão por que "just add memory" não é plano em agentic architecture.

Practitioners reagindo ao launch Team Memory flagaram correction, expiry e conflict resolution como gaps não documentados, segundo VentureBeat. Paper "Governed Memory" de março 2026 identifica mesmos riscos como estruturais, e OWASP agentic AI threat guidance classifica memory poisoning como attack class distinta.

O que fazer agora

Se avalia shared agent memory neste quarter, quatro passos, na ordem.

1. Hoje: escreva quatro respostas antes de demo: read scope, correction process, deletion semantics, conflict rule. Vendor que não match feature por feature mostra onde roadmap acaba.

2. Esta semana: rode M&A test. Crie memory em projeto confidential, depois pergunte ao mesmo agent como user sem acesso ao projeto. Asana foi designed explicitamente; todos outros devem demonstrar.

3. Este mês: poison algo deliberadamente em sandbox. Escreva fact plausível errado no shared store, deixe dois agents consumir, tente retrair. O que aprende sobre propagation/cleanup em uma tarde vale mais que architecture diagram.

4. Contínuo: atribua owners. Memory asset sem human nomeado responsável pela correção é technical debt com vector index.

Se memory needs ainda single-agent, cálculo é diferente e mais leve; self-hosted agent piece cobre esse trade-off.

FAQ

O que é shared agent memory, em uma frase?

Store persistente de facts, procedures e context que múltiplos agents, e humanos, leem e escrevem, para time parar de re-briefing cada agent do zero e começar a herdar erros uns dos outros.

Team Memory Tencent ou AI Teammates Asana é mais secure?

Respondem perguntas diferentes. Tencent oferece access model mais granular/explícito, quatro tiers, per-agent loadouts, private by default, e pode self-host, então data location é escolha. Asana é mais coarse, mas battle-tested porque herda workspace permissions que já governam trabalho confidential. "Secure" aqui é "scoped corretamente para org chart", só você sabe.

O que acontece quando shared memory está errada?

Hoje, quase nada automático. Tencent track versions/status, sem correction/expiry documentado para consumed facts. Asana corrige behaviour via human feedback loops sem documentar memory correction. Graphiti invalida stale facts com timestamps, melhor primitive disponível, mas governa graph de one agent. Reserve manual review process em qualquer escolha.

Duas memórias contraditórias de agents podem ser reconciled automaticamente?

Não em qualquer shipping system que eu consiga evidenciar. Behaviour atual é retrieval ranking escolher uma, então conflict é resolvido invisivelmente, por query, por similarity score. Se use case tem facts importantes, regulatory, financial, safety, trate "whose memory wins" como policy question sua, não feature esperando.

Em resumo

Shared memory é direção certa e produto incompleto. Tencent e Asana provaram independentemente que metade access-control é buildable, uma aberta/portable, outra fechada/permission-native, suficiente para agosto ser milestone. Mas correction, expiry, conflict não são documentados por ninguém e por default são seus. Compre access controls, planeje corrections, trate cada shared memory como fact sobre o qual time inteiro já agiu, porque quando notar, provavelmente agiu.

Se está decidindo onde shared memory cabe no agent stack, é conversa que tenho regularmente com clientes. Entre em contato.

Fontes

• Tencent Cloud, "TencentDB Agent Memory Releases Team Memory": https://www.tencentcloud.com/dynamic/news-details/101465 (publicado 2026-08-13, consultado 2026-08-29)

• VentureBeat, "Tencent's Team Memory shares AI agent memory across a team, with no governance yet for when it's wrong": https://venturebeat.com/data/tencents-team-memory-shares-ai-agent-memory-across-a-team-with-no-governance-yet-for-when-its-wrong (publicado 2026-08-07, consultado 2026-08-29)

• VentureBeat, "Asana's AI agents share memory across your company, but not your secrets": https://venturebeat.com/orchestration/asanas-ai-agents-share-memory-across-your-company-but-not-your-secrets (publicado 2026-08-03, consultado 2026-08-29)

• Asana, Inc., "Asana Announces New AI Teammates": https://investors.asana.com/news-releases/news-release-details/asana-announces-new-ai-teammates-collaborative-agents-deliver/ (publicado 2025-09-25, consultado 2026-08-29)

• TencentCloud, TencentDB-Agent-Memory repository: https://github.com/TencentCloud/TencentDB-Agent-Memory (consultado 2026-08-29)

• Zep, Graphiti repository: https://github.com/getzep/graphiti (consultado 2026-08-29)

• Mem0 repository: https://github.com/mem0ai/mem0 (consultado 2026-08-29)

• OWASP, "Agentic AI Threats and Mitigations": https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/ (consultado 2026-08-29)