Portables Agenten-Gedächtnis: Kontext über Claude Code, Cursor, Codex & Gemini hinweg mitnehmen

Wechseln Sie mitten im Projekt von Claude Code zu Cursor, vergisst Ihr Agent alles: die Architekturentscheidung von letzter Woche, den Bug, den Sie bereits behoben haben, und die Art, wie Sie Commits formulieren möchten. Der Kontext ist nicht mitgereist — er blieb im ersten Tool gespeichert. Portables Agenten-Gedächtnis ist das Muster, das dieses Problem löst: eine gemeinsame Gedächtnisschicht, die alle Ihre Agenten nutzen, sodass der Kontext Sie über Claude Code, Cursor, Codex und Gemini CLI hinweg begleitet, anstatt bei jedem Toolwechsel von vorne zu beginnen.

Dieser Leitfaden erklärt, was portables Agenten-Gedächtnis ist, welche Hauptansätze es gibt, wie diese sich abwägen lassen und wie Sie vermeiden, erneut in einen Lock-in zu geraten.

Was ist portables Agenten-Gedächtnis?

Portables Agenten-Gedächtnis ist ein Speicher für dauerhaften Projektkontext — Entscheidungen, Bugfixes, Konventionen und Fakten — der außerhalb eines einzelnen Agenten lebt und von allen gelesen werden kann. Anstatt dass jedes Tool seine eigenen isolierten Notizen führt, lesen und schreiben Ihre Agenten in einen gemeinsamen Pool.

Das Problem, das es löst, ist der Lock-in. Eingebautes Gedächtnis bindet Ihren Kontext an einen einzigen Coding-Agenten, und er bleibt zurück, wenn Sie das Tool wechseln. Eine gut gepflegte CLAUDE.md nützt Cursor nichts; Cursors Notizblöcke nützen Codex nichts. Die meisten Teams nutzen heute mehr als einen Agenten, sodass dieser verlorene Kontext eine echte, wiederkehrende Belastung darstellt.

Portabilität bedeutet zweierlei:

• Toolübergreifend: Dasselbe Gedächtnis funktioniert in Claude Code, Codex, Cursor, Gemini CLI und allem anderen, das es lesen kann.
• Kein Vendor-Lock-in: Sie können ein Tool — oder die Gedächtnisschicht selbst — verlassen, ohne Ihr Wissen neu aufbauen zu müssen.

Warum Kontext beim Toolwechsel verloren geht

Jeder Agent speichert Gedächtnis in seinem eigenen Format und an seinem eigenen Ort. Claude Code hat ein Gedächtnissystem; Cursor hat ein anderes. Wenn verschiedene Agenten unterschiedliche Dinge wissen, stellt die nächste Sitzung eine Frage erneut, die Sie bereits beantwortet haben, oder wiederholt einen Fehler, der schon einmal gemacht wurde.

Das eigentliche Problem ist, dass flaches, toolspezifisches Gedächtnis nicht über mehrere Agenten hinweg skaliert. Eine Notiz, die für einen Client geschrieben wurde, ist für den nächsten unsichtbar. Multipliziert man das mit jedem Toolwechsel, jedem neuen Chat-Fenster und jedem Teammitglied mit einem anderen Setup, wird derselbe Kontext immer wieder neu aufgebaut.

Die wichtigsten Ansätze für portables Gedächtnis

Es gibt heute drei grundlegende Muster. Sie unterscheiden sich hauptsächlich darin, wie sie Kontext speichern und wie sie sich mit Agenten verbinden.

1. MCP-basierte Gedächtnisserver

Der verbreitetste Ansatz verbindet einen Gedächtnisserver über das Model Context Protocol (MCP) mit jedem Agenten. MCP bietet jedem Tool eine standardisierte Möglichkeit, sich mit einem beliebigen Agenten zu verbinden, sodass eine Gedächtnisschicht viele Clients über dasselbe Protokoll bedienen kann.

Open-Source-Projekte wie agentmemory und Memorix verfolgen diesen Ansatz. agentmemory beschreibt sich als persistentes Gedächtnis für Claude Code, Cursor, Gemini CLI, Codex CLI und jeden MCP-Client, das global installiert und als MCP-Server registriert wird. Memorix ist eine local-first (lokal-zuerst) gemeinsame Gedächtnisschicht, die Projektgedächtnis im Git-Projekt statt in einem einzelnen Chat-Fenster oder Tool speichert.

Der Vorteil: Einmal einrichten, und jeder MCP-fähige Agent sieht dasselbe Gedächtnis. Der Nachteil ist ein laufender Dienst und eine Abhängigkeit von der MCP-Unterstützung in jedem Client.

2. Flat-File-Vaults (dateibasierte Speicher) ohne Vendor-Bindung

Ein leichtgewichtigerer Ansatz verzichtet vollständig auf Datenbanken und Server. Agent Memory OS ist ein portables Gedächtnissystem, das aus einfachen Markdown-Dateien und einigen kleinen Skripten besteht, ohne Datenbank und ohne laufenden Dienst. Es funktioniert mit Claude Code, Codex, Gemini CLI, Cursor oder allem anderen, das Dateien lesen kann, und pflegt eine bewusst vendor-neutrale Identitätsdatei, sodass ein Toolwechsel kein Neuaufbau des Setups bedeutet.

Der Abruf erfolgt hier meist lexikalisch — ein Router bewertet Markdown-Notizen anhand Ihrer Anfrage und gibt die relevantesten zurück — anstatt auf Embeddings (Vektoreinbettungen) zu setzen. Der Vorteil ist Einfachheit, Portabilität und keinerlei Infrastruktur. Der Nachteil ist eine weniger ausgefeilte Trefferquote als ein vektorgestütztes System bei großen Wissensbasen.

3. Gehostete / protokollgestützte Gedächtnisschichten

Eine dritte Gruppe bietet verwaltetes Gedächtnis mit Funktionen wie Verschlüsselung, verifizierbarem Speicher und SDKs. Diese zielen darauf ab, die dauerhafte, portable Schicht zu sein, in die Agenten sich einklinken, oft mit sowohl einem SDK als auch einer MCP-Integration, sodass Kontext über Apps und Sitzungen hinweg übertragen wird.

Der Vorteil ist weniger Betriebsaufwand und mehr eingebaute Funktionen; der Nachteil ist das Vertrauen in einen externen Dienst mit Ihrem Kontext und die Gefahr einer neuen Art von Lock-in — diesmal auf der Ebene der Gedächtnisschicht selbst.

Wie Sie wählen — und erneuten Lock-in vermeiden

Der Sinn von Portabilität ist die Freiheit zu wechseln. Bewahren Sie diese:

• Bevorzugen Sie offene Formate. Markdown-Vaults und dokumentierte Schemata sind leicht zu lesen, zu migrieren und zu prüfen. Proprietäre Binärformate nicht.
• Behalten Sie einen Exportpfad. Was auch immer Sie einsetzen, stellen Sie sicher, dass Sie Ihr Gedächtnis exportieren und anderswo verwenden können.
• Binden Sie Gedächtnis ans Projekt, nicht ans Tool. Gedächtnis, das unter Ihrem Git-Projekt liegt, reist mit dem Repository und übersteht Toolwechsel, IDE-Änderungen und neue Chat-Fenster.
• Behandeln Sie die „Drittes-Mal"-Regel als Signal. Wenn ein Agent denselben Fehler zum dritten Mal macht, fehlt eine Gedächtnisnotiz — nicht das Modell ist schlecht. Nehmen Sie wiederkehrende Entscheidungen und Bugfixes in dauerhaftes Gedächtnis auf.
• Speichern Sie keine Geheimnisse. Notieren Sie, wo ein Secret gespeichert ist und wie es verwendet wird — niemals den Wert selbst.

Eine schnelle Vergleichsübersicht:

Wohin sich das entwickelt

Portables Gedächtnis wird schnell zur Grunderwartung statt zur Besonderheit. Da Teams mehrere Agenten parallel betreiben — einen für Terminalarbeit, einen in der IDE, einen für Skripte — entwickelt sich die Gedächtnisschicht zu gemeinsamer Infrastruktur, ähnlich wie Versionskontrolle. Die Gewinner werden die Schichten sein, die offen, portabel und leicht zu verlassen bleiben.

Einen Multi-Agenten-Workflow aufbauen, der sich erinnert

Portables Gedächtnis ist am wichtigsten, wenn Sie mehr als einen Agenten gleichzeitig betreiben — was genau das ist, was eine Multi-Agenten-Belegschaft tut. Eigent ist eine quelloffene, lokale „Cowork"-Desktop-App, die ein Team von KI-Agenten bei realen Workflows koordiniert. Sie fügt Gedächtnis hinzu, das Sie auf den Nutzer, den Workspace oder die Sitzung begrenzen können, sowie dauerhafte, mehrstufige Ausführungen, sodass der erhaltenswerte Kontext gezielt weitergegeben wird, anstatt verloren zu gehen. Wenn Sie es satt haben, Ihr Projekt bei jedem Toolwechsel neu zu erklären, laden Sie Eigent herunter und geben Sie Ihren Agenten einen gemeinsamen Ort zum Erinnern.