Memories verwalten

Eine Memory ist eine dauerhafte Notiz, auf die deine Agenten zurückgreifen können – eine Konvention, eine Stolperfalle, eine erwähnenswerte Entscheidung. Jede Memory hat einen Scope; Workspace- und Projekt-Memories wandern mit deinem synchronisierten Repository mit und werden so gemeinsam mit deinen Workflows und Scripts versioniert.

Die Memory-Seite findest du unter Intelligence → Wissen. Die Ansicht Liste enthält deine Memories, und ein Editor erstellt und bearbeitet sie zugleich; Governance setzt die Prüfrichtlinie je Scope, und die Versionen und Snapshots jeder Memory liegen in ihrem Detail-Drawer. Entschieden werden vorgeschlagene Memories woanders — in der einen Entscheidungs-Warteschlange unter Posteingang → Entscheidungen (siehe Den Posteingang abarbeiten).

Die Wissens-Oberfläche unter Intelligence mit den Workspace-Memories, ihrem Scope und ihrer Art, über den Ansichten Liste, Graph, Zustand, Erklärung und Governance.

Eine Memory schreiben

Öffne Intelligence → Memory.
Klicke auf Neue Memory. Es öffnet sich ein Editor mit einem vollwertigen Markdown-Editor – verfasse die Notiz wie jedes Markdown, mit Überschriften, Listen und Code.
Wähle den Scope der Memory:
- Workspace – im Workspace geteilt.
- Projekt – an ein Projekt gebunden (wähle das Projekt darunter).
- Persönlich – nur deine eigene.
Wähle die Art der Memory (semantic, episodic, procedural, profile preference oder scratchpad).
Klicke auf Speichern.

Eine Memory in-place bearbeiten

Derselbe Editor bearbeitet eine bestehende Memory – es gibt kein separates Bearbeitungsformular.

Klicke im List-Tab auf eine Memory, um ihren Detail-Drawer zu öffnen.
Klicke auf Bearbeiten. Der Editor öffnet sich erneut, vorbefüllt mit Text, Scope und Art dieser Memory.
Ändere Text oder Felder und klicke auf Speichern. Die Änderung wird in-place in dieselbe Memory zurückgeschrieben und eine neue Version aufgezeichnet.

Vorgeschlagene Memories prüfen

Deine Agenten und das interne LLM des Workspace können Memories vorschlagen – eine neue Notiz oder eine Änderung an einer bestehenden. Vorschläge ändern von sich aus nichts; sie warten darauf, dass eine Person entscheidet — in derselben Warteschlange unter Posteingang → Entscheidungen, die auch Agenten-Freigaben, Skill- und Governor-Vorschläge trägt, nicht auf der Memory-Seite selbst.

Öffne Posteingang → Entscheidungen. Jeder ausstehende Eintrag zeigt seine Aktion, die Quelle, den vorgeschlagenen Scope und die Art sowie den Grund des Vorschlags.
Bearbeitet ein Vorschlag eine bestehende Memory, zeigt der Eintrag ein nebeneinanderliegendes Diff aus Aktuell und Vorgeschlagen, damit du genau siehst, was sich ändert.
Klicke auf Annehmen, um den Vorschlag anzuwenden (er erstellt oder aktualisiert die Memory), oder auf Ablehnen, um ihn zu verwerfen.

Closeout-Memories prüfen

Wenn ein Task abgeschlossen ist, schlägt SupaCloud eine kurze Closeout-Memory vor – einen Verweis auf die gerade erledigte Arbeit. Diese landen unter Posteingang → Entscheidungen als gut lesbare Karten. Nichts wird dauerhaft gespeichert, bevor du es freigibst.

Öffne Posteingang → Entscheidungen.
Aktiviere Nur Closeouts anzeigen, um die Warteschlange auf Closeout-Vorschläge zu filtern (neuester Abschluss zuerst). Jeder trägt das Abzeichen Closeout: Standard.
Eine Karte zeigt die Abschluss-Fakten des Tasks – Pull Request, Branch und Kosten – sowie den vorgeschlagenen Memory-Text.
Freigeben legt die Closeout-Memory an (und schließt bzw. überführt das verknüpfte Issue im selben Schritt, falls vorhanden), Ablehnen verwirft sie.

Öffne den Detail-Drawer einer Closeout-Memory, um zwei zusätzliche Bereiche zu sehen: Abschluss-Fakten (Branch / PR / Kosten) und Kontext-Nutzung (welche Tasks diese Memory gesehen haben, mit Verlinkung zum jeweiligen Task).

Ein umfassendes Retro (Badge Closeout: Comprehensive) fasst mehrere abgeschlossene Tasks zu einer vorgeschlagenen Lehre zusammen. Seine Evidenz trägt je Task neben dem, was der Agent geschrieben hat, das, was gemessen wurde: den Endstatus des Laufs, welche MCP-Werkzeuge er aufgerufen hat, welche ihm zur Verfügung standen, und den Stand des Pull Requests. Der Judge bekommt die Regeln mit, dass eine Messung über einer Behauptung steht, dass ein späterer Lauf einen früheren widerlegen kann und dass ein gescheiterter Lauf Kontext liefert, aber nie eine Regel. Ein Widerspruch, den die Messungen nicht entscheiden, bleibt aus dem vorgeschlagenen Text heraus und steht stattdessen in der Evidenz; der Titel des Vorschlags endet dann auf (N unresolved disagreements), damit du ihn entscheidest und nicht der Judge. Die Review-Karte zeigt diese Widersprüche über dem Vorschlagstext und darunter je zusammengeführtem Lauf, was gemessen wurde: seinen Status, die aufgerufenen MCP-Werkzeuge und wie viele ihm zur Verfügung standen (beim Start aufgezeichnet, bei älteren Läufen jetzt gegen das aktuelle Profil aufgelöst). Eine deterministische Prüfung ergänzt einen eigenen Widerspruch, wenn die Verfügbarkeits-Aussagen, die das Retro deklariert, den gemessenen Listen widersprechen; ein Text, der Werkzeuge nennt, ohne eine Aussage zu deklarieren, erhält statt eines Banners einen gedämpften Hinweis. Die Retro-Anfrage nimmt außerdem explizite Task-Ids an, sodass ein bestimmter Satz von Läufen auch dann zusammengefasst werden kann, wenn neuere Ergebnisse existieren.

Memories je Scope steuern

Ein Workspace-Eigentümer oder -Admin legt in der Ansicht Governance unter Intelligence → Wissen je Scope fest, wie neue Memories verwaltet werden:

Bei neuem Eintrag – Prüfung erforderlich (der sichere Standard: Vorschläge warten auf eine menschliche Freigabe) oder Automatisch veröffentlichen (neue Memories dieses Scopes werden sofort aktiv).
Aufbewahrung (Tage) – wie lange Memories dieses Scopes aufbewahrt werden, bevor sie archiviert werden dürfen; 0 behält sie dauerhaft.

Das lässt sich unabhängig für Workspace, Projekt und Persönlich einstellen.

Wenn ein Scope eine Prüfung verlangt, wird jede neue Memory dieses Scopes zur Entscheidung eingereiht statt sofort live zu gehen — egal ob du sie im Editor schreibst oder ein Agent sie vorschlägt. Das Bearbeiten einer live Memory eines prüfpflichtigen Scopes reiht die Änderung ebenso ein; die live Memory bleibt unangetastet, bis eine Person sie freigibt.

Semantisches Retrieval und Embeddings

Das Retrieval ordnet Memories nach Bedeutung, nicht nur nach Wörtern. Der Embedder, der Memories und Prompts in Vektoren verwandelt, wird aus dem aufgelöst, was dein Workspace mitbringt — ein API-Schlüssel für OpenAI, Google, Qwen oder OpenRouter — und unter Einstellungen → Modelle → Memory-Embeddings eingestellt: wähle einen Anbieter (oder lass es auf Automatisch, das den ersten Anbieter mit Schlüssel nimmt); mit festgelegtem Anbieter kannst du zusätzlich die Modell-ID überschreiben (ein Modell ohne Anbieter wird abgewiesen, nicht still ignoriert). Die Karte zeigt, was wirksam ist; ein Workspace ohne nutzbaren Schlüssel behält einen eingebauten Wort-Bucket-Rückfall, das Retrieval hört also nie auf zu arbeiten — es gewinnt nur keine Semantik.

Bestehende Memories werden nach dem Setzen oder Ändern des Modells im Hintergrund neu indiziert (eine frische Memory läuft bis zum nächsten Durchlauf auf dem Rückfall, höchstens wenige Minuten). Der Memory-Block, den ein Agent erhält, wird auf Breite ausgewählt: Fast-Duplikate verdrängen die anderen nützlichen Einträge nicht mehr.

Die Karte sagt außerdem, was der Bestand trägt — wie viele aktive Memories einen Vektor unter dem wirksamen Modell haben — und zeigt den Fehler des Hintergrund-Durchlaufs, wenn er dauerhaft scheitert (falsche Modell-ID, widerrufener Schlüssel), damit „wirksam” nie eine Behauptung ist, die der Speicher nicht deckt.

Automatisch nutzt nur, was der Workspace mitbringt: einen unter Zugangsdaten für den Workspace oder seine Organisation hinterlegten Schlüssel. Ein auf dem Server selbst konfigurierter Schlüssel zählt erst, wenn du diesen Anbieter ausdrücklich festlegst — so kann ein Server-Schlüssel nie still für jeden Workspace der Instanz Embeddings kaufen. Embedding-Aufrufe werden wie jeder andere Modellaufruf gemessen: sie erscheinen in der Monatsausgabe des Workspace (unter system:embedding), und ein Workspace, dessen Hard-Stop-Budget erschöpft ist, bleibt bis zum Monatswechsel oder einer höheren Grenze auf dem eingebauten Rückfall.

Zurückgezogene Memories

Genehmigst du im Review-Posteingang einen Ersatz (Supersede) oder eine Zusammenführung (Merge), wird die alte Memory zurückgezogen statt gelöscht: Sie wird als nicht mehr gültig gestempelt, mit ihrem Nachfolger verknüpft und bleibt im List-Tab und im Detail-Drawer lesbar — Agenten erhalten sie aber nicht mehr. Nichts aus der Historie geht verloren, und die Entscheidung ist nachvollziehbar.

Eine archivierte Memory kommt zurück: öffne sie (im List-Tab Archivierte anzeigen einschalten) und drücke im Detail-Drawer Wiederherstellen. Auf dem Weg zurück wird sie neu eingebettet, kehrt also in den lebenden Vektorraum zurück und wird wie jede andere Memory gefunden und verglichen; die Versionshistorie hält den Schritt fest.

Agenten den Bestand korrigieren lassen

Ein Agent kann vorschlagen, eine bestehende Memory zu überarbeiten oder zurückzunehmen — über die zwei Werkzeuge memory.update und memory.supersede. Beide schreiben in den Review-Posteingang, nie in den Bestand, und beide sind standardmäßig aus: Aktiviere allow_self_correction in der Memory-Policy des Agentenprofils (Einstellungen → Profile, Raw-Ansicht) für die Profile, die mit dem Bestand streiten dürfen. Eine nur-lesend gepinnte Sitzung (ein Auditor, ein Konzeptplaner) kann sie nie benutzen.

Auch der Memory-Vorschlag am Task-Ende liest zuerst die nächstliegenden bestehenden Memories und entscheidet, ob ein Lauf einen neuen Fakt hinzufügt, einen überarbeitet, einen ersetzt oder bereits abgedeckt ist — eine Überarbeitung landet im Posteingang gegen genau diese Memory, und das Messfeld der Health-Ansicht zählt die abgedeckten Läufe.

Den Bestand aufgeräumt halten

Zwei Dinge pflegen den Bestand für dich, beide über denselben Posteingang:

Ein täglicher Konsolidierungslauf macht aus Duplikat- und Widerspruchsbefunden Zusammenführen- / Konflikt lösen-Vorschläge — höchstens zehn pro Tag, jedes Paar nur einmal gefragt (eine Ablehnung ist ein „beide behalten”, das nie wiederholt wird) und nur für Paare, die mit echten Embeddings gemessen wurden. Das Panel weist ab 70 % Ähnlichkeit auf ein Duplikat hin; ein Zusammenführungs-Vorschlag entsteht automatisch erst ab 90 %. Ein Widerspruch wird zuerst geprüft, zwei Memories, die sich widersprechen, werden also nie zum Zusammenführen vorgeschlagen.
Jetzt prüfen — ein Workspace-Admin kann den ganzen Hygiene-Durchlauf aus der Health-Ansicht sofort starten: veraltete Vektoren neu indizieren, die Aufbewahrungs-Policy anwenden und die Vorschläge einreichen. Die Ergebniszeile sagt, was jeder Schritt getan hat. Derselbe Durchlauf läuft auch automatisch direkt nach einem Re-Index, der Vektoren hochgezogen hat.
Der Reflexions-Task — in der Governance-Ansicht scharfgeschaltet — ist ein geplanter Task unter eigenem Agentenprofil (memory-reflector, beim ersten Scharfschalten angelegt), der die jüngsten Memories liest und Zusammenführungen, Rücknahmen und höherstufige Lehrsätze vorschlägt. Wähle beim ersten Mal den Agenten und einen täglichen, wöchentlichen oder monatlichen Rhythmus; Pausieren behält das Profil, damit du es wie jedes andere anpassen kannst.

Memories, die ein Agent in einem erfolgreichen Lauf zitiert hat, gewinnen an Gewicht (und ihr Aufbewahrungsfenster beginnt neu); in einem gescheiterten Lauf zitierte verlieren etwas; nur eingespielte, nicht zitierte bleiben unberührt.

Versionen und Snapshots einsehen

Öffne den Detail-Drawer einer Memory (klick sie im List-Tab an), um alles zu einer einzelnen Memory an einem Ort zu sehen:

Ihren Scope, ihre Art, Quelle, Wichtigkeit, Salienz sowie wann sie zuletzt verwendet und aktualisiert wurde.
Ihre Verknüpfungen zu verwandten Memories, Entitäten und Runs.
Ihren Versionsverlauf – jede gespeicherte Revision der Memory, neueste zuerst.
Einen ausklappbaren Snapshots-Inspektor, der die Kontext-Snapshots zeigt, die ein vergangener Task- oder Council-Run ausgewählt hat – nützlich, um zu verstehen, warum eine Memory verwendet wurde.

Pinnen, archivieren und bearbeiten kannst du die Memory aus der Fußzeile des Drawers.

Wie Memories mit dem Repo-Sync mitreisen

Workspace- und Projekt-Memories sind Teil des Repo-Syncs: SupaCloud serialisiert sie in das synchronisierte Repository (unter memories/), neben deinen Workflows, Scripts, Ressourcen und Apps, und gleicht sie wie jedes andere repo-verwaltete Element in beide Richtungen ab. Bearbeitest du eine Memory direkt im Repository, fließt sie beim Pull zurück in SupaCloud; schreibst du sie im UI, landet sie beim Push im Repository.