Shared Agent Memory hat ein Access-Control-Problem, und niemand hat es gelöst

Hier ist eine Behauptung, gegen die ich mich vor einem Jahr gewehrt hätte: Der schwierige Teil von Agent Memory war nie, einen Agenten dazu zu bringen, sich zu erinnern. Er ist zu entscheiden, was passiert, wenn fünfzig Agenten dieselbe falsche Sache erinnern. Single-agent Memory ist ein Convenience-Problem. In dem Moment, in dem Memory über ein Team geteilt wird, wird es zu einem organisatorischen Access-Control-Problem, mit Correction-, Deletion- und Conflict-Semantics, und genau dort sind die aktuellen Produkte am dünnsten.

Zwei Anbieter haben innerhalb weniger Wochen Antworten darauf ausgeliefert. Tencent Clouds Team Memory Release, das ich in einem separaten Stück zum Launch behandelt habe, hat am 13. August einen governed Memory Hub als Open Source veröffentlicht. Asana betreibt seit Ende letzten Jahres still die geschlossene, platform-bound Version, Agentic Work Management, mit seinen AI Teammates. Dieses Stück ist kein weiterer Announcement Recap. Es ist der Vergleich, den die Announcements auslassen: Was jedes System tatsächlich tut, wenn ein Memory korrigiert, gelöscht oder adjudicated werden muss, und wer innerhalb einer Organisation entscheiden darf.

Wichtigste Erkenntnisse - Shared Memory verwandelt einen falschen Fakt von der Irritation eines Users in das Erbe jedes Agenten. Die Governance Layer, nicht die Retrieval Quality, ist jetzt das tragende Feature. - Tencents Team Memory liefert das expliziteste Access Model, vier Visibility Tiers, per-agent Loadouts, private by default, aber keinen dokumentierten Correction- oder Expiry-Prozess für einen Fakt, den andere Agents bereits konsumiert haben. - Asanas Agentic Work Management löst den Confidential-leak-Fall korrekt, indem es die bestehenden Permissions des Work Graph übernimmt, aber das Memory lebt innerhalb Asanas Plattform und seine Correction Semantics sind undurchsichtig. - Zeps Graphiti ist die einzige Mainstream Implementation mit einer prinzipiellen Antwort auf stale Facts: Es invalidiert statt zu löschen und behält die History. Aber es governed das Memory eines einzelnen Agenten, nicht das eines Teams. - Niemand liefert bislang Conflict Resolution für den Fall, dass zwei Agents widersprüchliche Facts über dieselbe Sache geschrieben haben. Diese Frage wird derzeit durch "retrieval ranking" beantwortet, und das ist keine Antwort.

Was passiert ist

In den ersten zwei Augustwochen wurde Shared Agent Memory von einem Research Topic zu einer Shipping Category. Zwei Events sind der sinnvolle Anker:

• Am 13. August kündigte Tencent Cloud Team Memory an, die teamweite Erweiterung des Open-Source-Projekts TencentDB Agent Memory. Conversations, Documents, Code Graphs und distilled Skills werden governed Team Assets mit Owners, Versions und einem vierstufigen Visibility Model, zusammengestellt pro Agent Role.

• Eine Woche früher lieferte VentureBeats Fireside Chat mit Asana CPO Arnab Bose die ersten echten technischen Details zu Agentic Work Management, AWM, dem Shared-Memory-System hinter Asanas AI Teammates, das laut Asana bereits bei Kunden wie FedEx in Production läuft.

Darum herum liegt die Open-Source-Single-agent-Memory-Layer, Mem0, Zeps Graphiti, Letta, in der der Großteil der tatsächlichen Memory Infrastructure von Teams noch lebt. Die interessante Verschiebung ist, dass all diese Systeme jetzt anhand derselben vier Fragen bewertet werden. Wer darf ein Memory lesen? Was passiert, wenn es falsch ist? Was passiert, wenn es gelöscht wird? Und was passiert, wenn zwei Memories widersprechen?

Tencent Cloud hat Team Memory, einen governed Shared-Memory-Hub für Agent Teams, am 13. August 2026 ausgeliefert, laut Announcement. Tage zuvor beschrieb Asanas CPO Agentic Work Management, das Shared-Memory-System hinter AI Teammates, in einem VentureBeat-Interview, veröffentlicht am 3. August 2026.

Die vier Fragen im Vergleich

Das faule Framing für diese Kategorie lautet "Tencent versus Asana", chinesisches Open Source versus amerikanisches SaaS. Das verfehlt die tatsächliche Struktur. Die echte Trennung verläuft zwischen Systemen, die Memory als Documents mit Permissions govern, und Systemen, die Memory als Facts mit Lifecycles govern, und keine Seite hat bisher beide Hälften.

Lesen Sie die Correction- und Conflict-Zeilen herunter und das Muster ist unangenehm: Die zwei Cells, die am meisten zählen, sind genau die zwei, die niemand ausgefüllt hat.

Die eigene Dokumentation von Team Memory unterscheidet "who can use it, which version is valid, and which Agent should receive it", laut Tencents Dokumentation, wie von VentureBeat berichtet. Zeps Graphiti invalidiert stale Facts statt sie zu löschen, laut Project Repository. Weder Tencent noch Asana dokumentieren öffentlich einen Correction- oder Conflict-Resolution-Prozess für Shared Memories, die bereits von anderen Agents konsumiert wurden.

Was jedes System richtig macht

Tencents Beitrag ist das Access Model, und es verdient Credit dafür, explizit zu sein, wo alle anderen vage bleiben. Jedes Memory Asset trägt einen Owner, eine Version und ein Visibility Tier, private, team, restricted, agent, neue Assets defaulten auf private, und Agents erhalten einen "Agent Loadout", der zu ihrer Role passt, statt Zugriff auf den gesamten Hub. Ein Scout Agent für Research bekommt Market-analysis Assets; ein Builder Agent bekommt den Code Graph. Das ist Memory als organisatorische Infrastructure mit Lock Policy, und wie VentureBeats Coverage feststellte, zieht die Dokumentation selbst die Grenze zu plain RAG: Retrieval beantwortet, was gefunden werden kann, Team Memory beantwortet zusätzlich, wer es benutzen darf.

Asanas Beitrag ist die Leak Boundary, und sein Beispiel gehört in jedes Governance Deck. Wenn das AI Teammate eines Executives Memory zu einem vertraulichen M&A Project aufbaut, darf ein Colleague, der später mit demselben Teammate spricht, diesen Context nicht erben. Boses Antwort, laut VentureBeat-Interview, lautet, dass AWM auf Asanas 18 Jahre altem Work Graph sitzt, sodass Memory Access dieselben Permissions wie die zugrunde liegende Arbeit erbt: Wenn Sie das Project nicht sehen dürfen, gehört das Memory des Agents dazu ebenfalls nicht Ihnen. Das ist ein wirklich schwieriges Problem, gelöst durch die Weigerung, ein neues Permission System zu bauen, und es funktioniert nur, weil Asana bereits weiß, wer was sehen darf. Asana spricht seit dem AI Teammates Announcement letzten September über teamweites Memory und Enterprise Controls, aber die M&A Boundary ist der erste konkrete Mechanismus.

Graphitis Beitrag ist der Lifecycle. Die meisten Systeme behandeln einen falschen Fact als Deletion Problem. Graphiti behandelt ihn als Zeitproblem: Wenn ein Fact nicht mehr wahr ist, wird die Edge invalidiert und timestamped, nicht gelöscht, sodass der Agent sowohl "was ist jetzt wahr" als auch "was war im März wahr" beantworten kann. Für alles mit Audit ist das die richtige Primitive, und es ist bemerkenswert, dass sie aus der Single-agent-Welt kommt und nicht aus einem der neuen Team Systems.

Tencent liefert die explizitesten Access Tiers mit private-by-default Sharing; Asana scoped Agent Memory an bestehende Work-Graph-Permissions, sodass Confidential-project Memory nicht zu nicht freigegebenen Colleagues leakt, laut Asana CPO Arnab Bose in VentureBeat; Zeps Graphiti invalidiert stale Facts mit Timestamps statt sie zu löschen, laut Repository.

Die ungelöste Mitte: Correction, Conflict, Propagation

Jetzt der Teil, den beide Launch Narratives auslassen. Ein falscher Fact in Single-agent Memory kostet einen User eine wiederholte Correction. Ein falscher Fact in einem Shared Store propagiert zu jedem Agenten, der ihn gelesen hat, bevor es jemand bemerkt, und keines der ausgelieferten Systeme dokumentiert einen Prozess dafür. VentureBeats Launch Coverage sammelte Practitioners, die die Lücke innerhalb von Stunden markierten: Correction und Expiry für konsumierte Facts, die Entscheidung, was überhaupt nie geschrieben werden sollte, und der Fall, in dem die Agents zweier Teammates widersprüchliche Facts über dasselbe Module geschrieben haben und der Shared Store einen Gewinner wählen muss. Single-agent Memory driftet langsam. Shared Memory driftet schnell, weil ein stale Write Menschen erreicht, die die Session, die ihn produzierte, nie gesehen haben.

Das ist kein Implementation Nitpick, den ein Point Release löst. Ein Paper vom März 2026, "Governed Memory: A Production Architecture for Multi-Agent Workflows", identifiziert Governance Fragmentation und Silent Quality Degradation ohne Feedback Loops als strukturelle Risiken von Shared Multi-agent Memory allgemein, eine höfliche akademische Art zu sagen, dass der Failure Mode in die Architektur eingebaut ist, nicht in den Vendor. Und das Security Framing verschärft es: OWASPs Agentic Threat Guidance benennt Memory Poisoning als eigene Attack Class, und ein Shared Store ist ein Shared Blast Radius. Asanas Permission Inheritance und Tencents private-by-default Tiers limitieren beide, wer ein poisoned oder stale Memory lesen kann. Keines adressiert, was passiert, nachdem ein schlechtes gelesen wurde.

Meine Lesart: Correction und Conflict Resolution werden am Ende so funktionieren wie in jedem anderen Shared Information System, nämlich sozial. Ein benannter Owner pro Asset, ein Review Habit, eine Expiry Norm. Die Tools, die diese Kategorie gewinnen, werden diejenigen sein, die diesen sozialen Prozess leicht machen, statt ihn wegautomatisieren zu wollen. Ich habe diesen Film bei Wikis, CRMs und Feature Flags gesehen. Die Governance Features sind das Product, dieselbe Schlussfolgerung wie in meinem Agent-Governance-Stück, und derselbe Grund, warum "just add memory" in Agentic Architecture kein Plan ist.

Practitioners, die auf den Team Memory Launch reagierten, markierten Correction, Expiry und Conflict Resolution als undocumented Gaps, laut VentureBeat. Das Paper "Governed Memory" vom März 2026 identifiziert dieselben Risiken als strukturell für Shared Multi-agent Memory, und OWASPs Agentic AI Threat Guidance klassifiziert Memory Poisoning als eigene Attack Class.

Was Sie jetzt tun sollten

Wenn Sie Shared Agent Memory dieses Quartal evaluieren, vier Schritte, in dieser Reihenfolge.

1. Heute: Schreiben Sie Ihre vier Antworten auf, bevor Sie irgendetwas demoen: Read Scope, Correction Process, Deletion Semantics, Conflict Rule. Jeder Vendor, der diese nicht Feature für Feature matchen kann, sagt Ihnen, wo seine Roadmap endet.

2. Diese Woche: Führen Sie den M&A Test aus. Erstellen Sie ein Memory unter einem Confidential Project, dann stellen Sie demselben Agenten als User ohne Project Access eine Frage. Asana hat explizit dafür designed; alle anderen sollten es demonstrieren müssen.

3. Diesen Monat: Poisonen Sie in einer Sandbox absichtlich etwas. Schreiben Sie einen plausiblen falschen Fact in den Shared Store, lassen Sie zwei Agents ihn konsumieren, versuchen Sie ihn dann zurückzuziehen. Was Sie an einem Nachmittag über Propagation und Cleanup lernen, ist mehr wert als jedes Architecture Diagram.

4. Fortlaufend: Weisen Sie Owners zu. Ein Memory Asset ohne benannten Menschen, der für seine Korrektheit verantwortlich ist, ist Technical Debt mit Vector Index.

Wenn Ihre Memory Needs noch Single-agent sind, ist die Rechnung anders und leichter; das Self-hosted-Agent-Stück behandelt diese Seite des Trade-offs.

FAQ

Was ist Shared Agent Memory in einem Satz?

Ein persistenter Store von Facts, Procedures und Context, aus dem mehrere Agents und ihre Humans lesen und in den sie schreiben, sodass das Team aufhört, jeden Agenten von Grund auf neu zu briefen, und stattdessen beginnt, die Fehler der anderen zu erben.

Ist Tencents Team Memory oder Asanas AI Teammates sicherer?

Sie beantworten unterschiedliche Fragen. Tencent liefert das granularere, explizitere Access Model, vier Tiers, per-agent Loadouts, private by default, und Sie können es self-hosten, also ist Data Location Ihre Wahl. Asanas Model ist gröber, aber battle-tested, weil es Workspace Permissions übernimmt, die bereits Confidential Work regeln. "Secure" bedeutet hier größtenteils "korrekt für Ihr Org Chart gescoped", und nur Sie kennen das.

Was passiert, wenn ein Shared Memory falsch ist?

Heute meistens nichts Automatic. Tencent trackt Versions und Status, dokumentiert aber keinen Correction- oder Expiry-Prozess für konsumierte Facts. Asana korrigiert Behaviour über Human Feedback Loops, ohne Memory Correction zu dokumentieren. Graphiti invalidiert stale Facts mit Timestamps, die beste verfügbare Primitive, aber governed den Graph eines einzelnen Agenten. Planen Sie bei jeder Wahl einen manuellen Review Process ein.

Können sich widersprechende Memories zweier Agents automatisch reconciled werden?

Nicht in irgendeinem Shipping System, für das ich Evidence habe. Das aktuelle Behaviour ist, dass Retrieval Ranking eines auswählt, was bedeutet, dass der Conflict unsichtbar, pro Query, durch einen Similarity Score gelöst wird. Wenn Ihr Use Case Facts enthält, die zählen, regulatory, financial, safety, behandeln Sie "wessen Memory gewinnt" als Policy Question, die Sie selbst beantworten, nicht als Feature, auf das Sie warten.

Fazit

Shared Memory ist die richtige Richtung und ein unfertiges Product. Tencent und Asana haben unabhängig gezeigt, dass die Access-Control-Hälfte buildbar ist, eines offen und portabel, eines geschlossen und permission-native, und allein das macht August zu einem echten Milestone. Aber die Correction-, Expiry- und Conflict-Hälfte wird derzeit von niemandem dokumentiert und gehört standardmäßig Ihnen. Kaufen Sie die Access Controls, planen Sie die Corrections selbst, und behandeln Sie jedes Shared Memory wie einen Fact, nach dem das ganze Team bereits gehandelt hat, denn wenn Sie ihn bemerken, hat es das.

Wenn Sie herausarbeiten, wo Shared Memory in Ihren Agent Stack passt, ist das ein Gespräch, das ich regelmäßig mit Clients führe. Kontakt aufnehmen.

Quellen

• Tencent Cloud, "TencentDB Agent Memory Releases Team Memory": https://www.tencentcloud.com/dynamic/news-details/101465 (veröffentlicht 2026-08-13, abgerufen 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 (veröffentlicht 2026-08-07, abgerufen 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 (veröffentlicht 2026-08-03, abgerufen 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/ (veröffentlicht 2025-09-25, abgerufen 2026-08-29)

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

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

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

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