--- title: "Multi-Agent Transactive Memory" source: https://arxiv.org/abs/2606.19911v1 plattform: youtube channel: cs.CL duration_seconds: None thema: agent-memory-trajectory-retrieval nutzen: "Konzeptbasis fuer Aria-Trajectory-Memory: Past-Session-Replay statt Cold-Start bei wiederkehrenden Tasks." umsetzungsidee: "Spike: Aria-Trajectory-Store-Design. (1) Definiere Trajectory-Schema (Task, Steps, Tool-Calls, Outcome, Score). (2) Prototyp: letzte 20 Aria-Sessions als JSONL exportieren. (3) Embedding-basiertes Retrieval gegen neue Task-Description testen. (4) Vergleich: mit vs ohne retrieved Trajectory — Token/Steps/Erfolg." prioritaet: P2 klassifikation: Spike confidence: 0.72 status: aktiv tags: [agent-memory, rag, multi-agent, trajectories, transactive-memory, aria-architecture, spike, akp, video, auto-ingested] date: 2026-06-20 akp_run: kar-74 --- # Multi-Agent Transactive Memory **Channel:** cs.CL · **Dauer:** 0 min · **URL:** https://arxiv.org/abs/2606.19911v1 ## Kernaussage MATM (Multi-Agent Transactive Memory) erweitert RAG: statt menschlicher Artefakte werden Agent-Trajektorien in einem geteilten Repository abgelegt, sodass neue Agents prozedurales Wissen anderer Agents abrufen statt neu zu entdecken. Tests in ALFWorld/WebArena zeigen bessere Task-Performance und weniger Interaktionsschritte ohne Joint-Training. ## 7-Punkt Praxisanalyse ### 1. Was koennen wir lernen? Agent-Trajektorien (Tool-Calls, Reasoning-Steps, Outcomes) sind reusable procedural knowledge und sollten nicht nach Single-Use verworfen werden. Population-Level Retrieval >> per-Agent Memory. ### 2. Wie koennen wir es einsetzen? Fuer KADi/MRR: Aria's eigene erfolgreiche Sessions (Issue-Resolutions, Skill-Anwendungen, Debug-Pfade) als Trajektorien in einem durchsuchbaren Store ablegen — neue Aria-Instanzen ziehen relevante Past-Trajectories per Retrieval statt cold-start. ### 3. Konkreter Vorteil fuer Aria / KADi / Supplier Pulse / Workflow / Tools? KADi hat heute fragmentiertes Memory (Brain-Notes + Issues + git log), aber keine strukturierten Trajektorien. Ein MATM-Layer wuerde 'how did Aria solve X last time' direkt abrufbar machen — reduziert Token-Verbrauch und Wiederentdeckung. ### 4. Was koennen wir dadurch besser machen? Paper bleibt bei interaktiven Envs (ALFWorld/WebArena). Fuer KADi-Realitaet: Trajectories ueber MCP-Tool-Calls + Repo-Edits indizieren, mit Outcome-Scoring (Issue closed? Tests green?) als Retrieval-Quality-Signal. ### 5. Lohnt sich die Umsetzung — warum? Direkt anschlussfaehig an bestehende Brain-Note + Issue-Loop-Idee. Konzeptionell sauber, empirisch belegt, low coordination overhead. ### 6. Naechste Schritte Spike: wie sehen Aria-Trajektorien als Artefakt aus? Format (JSONL pro Session?), Storage (existing Brain-Vault vs separater Trajectory-Store?), Retrieval-Signal (Embedding ueber Task-Description + Outcome-Tag). ## Kritik (Pflichtfeld) Paper-Abstract verkauft RAG-fuer-Agents als neuartig, aber Idee 'Agent-Experience-Replay/Memory' ist seit Voyager, Reflexion, Generative Agents bekannt. 'Transactive Memory'-Branding ist hauptsaechlich Re-Framing. Echte Frage — Trajectory-Quality-Filtering, Staleness, Conflicting-Trajectories — wird im Abstract nicht adressiert. Ohne Volltext-Lesen unklar ob mehr als 'embed trajectories, top-k retrieve'. ## Multi-Level-Challenge (inline, KAR-72) **Devils-Advocate:** KADi ist single-agent (Aria), nicht 'population of agents' — Multi-Agent-Aspekt von MATM bringt hier wenig. Bestehende Brain-Notes + Issue-Refs leisten bereits ein simples Trajectory-Memory ohne neue Infrastruktur. **Steel-Man:** Selbst single-Aria profitiert: strukturierte Past-Sessions mit Outcome-Tagging sind eine echte Luecke (Brain-Notes sind narrativ, nicht procedural). Wenn spaeter weitere Agent-Rollen (z.B. Reviewer, Researcher) dazukommen, ist Trajectory-Store ready. **Synthese:** Refine — als Spike ins Backlog, aber erst nach Klaerung: brauchen wir wirklich separaten Trajectory-Store oder reicht ein 'session-log'-Tag auf Brain-Notes mit Outcome-Field? Nicht jetzt bauen, aber Konzept festhalten. ## Adversarial-Critic (separater Call, Cross-Model, KAR-747) **Verdict:** refine · **Confidence:** 0.81 · **Halluzinations-Risiko:** low **Urteil:** Konzeptuell sauber destilliert und ehrlich kritisiert, aber der KADi-Nutzen ist spekulativer Analogieschluss ohne Absicherung durch den Volltext, und Spike/P2 ist leicht ueberprioritisiert angesichts der selbst eingeraeumt unklaren Substanz. **Schwaechen:** - Der Nutzen-Transfer auf KADi (single-agent) ist spekulativ und nicht im Transcript belegt — MATM ist explizit fuer heterogene Agent-Populationen konzipiert, der Analyst ueberdehnt dies auf einen Single-Agent-Use-Case ohne Evidenz aus dem Paper - Die Behauptung 'reduziert Token-Verbrauch' ist nicht im Abstract erwaehnt — dort steht nur 'reduces interaction steps', Token-Verbrauch ist eine Extrapolation - Die Kritik im Analyse-JSON ist akkurat und selbstkritisch (Voyager/Reflexion-Verweis, Re-Framing-Verdacht), aber die Klassifikation 'Spike' mit P2 ignoriert die eigene Kritik teilweise — wenn 'Volltext unklar ob mehr als embed+top-k retrieve', waere Ignore oder P3 ehrlicher - KADi-spezifische Lueckenanalyse ('fragmentiertes Memory') ist plausibel aber intern generiert, nicht aus dem Transcript ableitbar — haengt komplett am Kontext-Wissen des Analysten ueber KADi, nicht am Paper - Confidence 0.72 ist eher zu hoch angesichts der Einschaenkung 'ohne Volltext-Lesen unklar' — relevante Implementierungsdetails (Quality-Filtering, Staleness) sind explizit unbekannt ## Cross-Reference (Brain-Match) - (keine Brain-Matches) ## Klassifikation: **Spike** · Prioritaet **P2** · Confidence **0.72** --- *Auto-generated by aria-akp-deep.py · cost $0.1787 · 2026-06-20T04:09:22.025612+00:00*