Du startest ein Feature in Claude Code. Es hängt an einem kniffligen Typfehler fest, also übergibst du dasselbe Repo an Codex, das für diese Art von Schwerarbeit besser geeignet ist. Codex behebt ihn, aber jetzt hat es keine Ahnung, wofür das Feature gedacht war, welche Dateien du bereits als tabu markiert hattest oder was hier „fertig" bedeutet. Du erklärst die ganze Sache erneut aus dem Gedächtnis. Zehn Minuten später wechselst du zurück, und Claude Code hat es ebenfalls vergessen. Der Code ist vorangekommen. Der Kontext nicht.
Das ist der Preis dafür, mehr als einen Coding-Agent zu betreiben. Jedes Tool führt sein eigenes Gedächtnis in seinem eigenen Format und seiner eigenen Session, sodass in dem Moment, in dem die Arbeit von einem Agent zum anderen wandert, alles außer dem Diff auf der Strecke bleibt. Kontext beim Wechsel zwischen Coding-Agents zu erhalten, bedeutet, diesen Kontext außerhalb jedes einzelnen Agents anzusiedeln – in einer Form, die der nächste lesen kann, ohne dass du ihn erklären musst.
Dieser Artikel zeigt, wie das geht – mit Sharkly als Workflow: die Ebene, die über deinen Coding-Agents sitzt und Kontext, Fortschritt, Blocker, Ergebnisse und menschliche Review von der Anfrage bis zum Release sichtbar hält. Coding-Agents hast du bereits. Das Problem hier ist die Nahtstelle zwischen ihnen, und sie wird mit jedem Agent, den du hinzufügst, breiter.
Warum Kontext nicht zwischen Agents wandert
Der Kontext für eine Coding-Aufgabe lebt an drei Orten, und nur einer davon ist portabel.
Der erste ist die Instruktionsdatei: CLAUDE.md, AGENTS.md, GEMINI.md. Feste Regeln, Konventionen, die Befehle zum Ausführen von Tests. Der zweite ist der Session-Zustand: der Scrollback dessen, was du und der Agent gerade gesagt habt, was er versucht und was er ausgeschlossen hat. Der dritte ist das Artefakt selbst, der Diff auf der Festplatte oder der Branch.
Nur der dritte reist kostenlos mit. Ein anderer Agent kann den Code lesen, aber er kann keine Konversation lesen, an der er nicht beteiligt war, und er wird keine Instruktionsdatei lesen, die an ein anderes Tool adressiert ist. Das ist die Grenze, die man klar benennen sollte: Ein Agent-Wechsel bewahrt den Code und lässt die Begründung fallen. Der Commit überlebt. Das „Warum" steckte in einem Scrollback-Puffer, den ein Agent gesehen hat und der nächste nie sehen wird.
Kontext über einen Wechsel hinweg zu erhalten, sind also eigentlich zwei Aufgaben: die festen Regeln für jeden Agent lesbar machen und den Live-Zustand der Aufgabe als etwas anderes als das Gedächtnis eines einzelnen Tools existieren lassen. Die nächsten Abschnitte gehen sie der Reihe nach durch. (Wenn dein Schmerz darin liegt, Kontext zwischen Runs des selben Agents zu verlieren, ist das ein verwandtes, aber separates Problem, das in Kontext über KI-Sessions hinweg erhalten behandelt wird.)
Mach die festen Regeln zu einer Datei, die jeder Agent liest
Fang mit dem günstigen Gewinn an. Claude Code liest CLAUDE.md, Codex liest AGENTS.md, Gemini CLI liest GEMINI.md. Dieselbe Aufgabe, drei Dateinamen. Wenn du sie getrennt pflegst, driften sie auseinander, und der Agent, zu dem du gewechselt bist, folgt jetzt veralteten Regeln, während du annimmst, dass er es nicht tut.
Schreib die Regeln einmal und lass die anderen Dateinamen darauf zeigen. Unter macOS oder Linux:
# AGENTS.md is the source of truth; the others are aliases
ln -s AGENTS.md CLAUDE.md
ln -s AGENTS.md GEMINI.md
git add AGENTS.md CLAUDE.md GEMINI.md
Jetzt liest jeder Agent, der das Repo öffnet, dieselben Konventionen, und es gibt nur eine Datei zu aktualisieren, wenn sie sich ändern. Halte sie kurz und sachlich: der Test-Befehl, die gesperrten Verzeichnisse, die Review-Regel, wie Commits aussehen sollen. Das ist der gemeinsame Vertrag, den jeder Agent in dem Moment erbt, in dem er startet – egal, zu welchem du gewechselt bist.
Der Fehlermodus, auf den du achten solltest: aufgabenspezifische Details in diese Dateien zu schreiben. Die Instruktionsdatei ist für Regeln, die für jede Aufgabe im Repo gelten. „Wir nutzen Vitest, nicht Jest" gehört hierher. „Beende die Checkout-Retry-Logik und fass die Auth-Middleware nicht an" gehört nicht hierher; das gilt für eine Aufgabe diese Woche und ist bei der nächsten falsch. Beides zu vermischen bedeutet, dass jeder Agent Anweisungen liest, die für eine bereits ausgelieferte Aufgabe gedacht waren.
Trag den Arbeitskontext mit, nicht nur die Regeln
Die Regeln-Datei bringt einen neuen Agent an die Startlinie. Über die laufende Aufgabe sagt sie nichts: was entschieden wurde, was halbfertig ist, was noch unklar ist. Genau dieses Wissen verdampft beim Wechsel, weil es immer nur in der Session des vorherigen Agents gelebt hat.
Die manuelle Lösung ist eine Übergabenotiz. Bevor du den Agent wechselst, lass den aktuellen aufschreiben, wo er steht: das Ziel, die geänderten Dateien, was er verifiziert hat und die eine Sache, bei der er sich nicht sicher war. Füge das beim nächsten Agent als erste Nachricht ein. Es funktioniert, und für einen einzelnen Wechsel reicht es. Das Muster ist es wert, für sich verinnerlicht zu werden; wie eine gute aussieht, wird in Agent-Übergabevorlagen behandelt.
Der Fehlermodus ist, dass die Notiz nirgendwo dauerhaft lebt. Sie ist ein Absatz in einem Terminal, das du schließen wirst, oder eine Nachricht, die du jedes Mal neu tippst. Wechsle zweimal hin und her, und du pflegst die Übergabenotiz von Hand, in deinem Kopf, über drei Tools hinweg. Der Kontext existiert, aber du bist die Datenbank geworden, in der er gespeichert ist. Das trägt für eine Aufgabe. Es trägt nicht, wenn du mehrere laufen lässt – und da stößt der DIY-Ansatz an seine Grenzen.
Wo das DIY-Setup nicht mehr skaliert
Symlinkte Regeln plus eine eingefügte Übergabenotiz bringen dich weit mit einem Repo und zwei Agents. Füge einen dritten Agent, ein zweites Repo oder eine Aufgabe hinzu, die sich über einen Tag erstreckt, und die Rechnung kippt gegen dich. Jeder Wechsel ist ein manueller Export und Re-Import. Jede Aufgabe hat ihren eigenen Faden von „was ist erledigt", der nur dort lebt, wo der letzte Agent ihn hinterlassen hat. Nichts sagt dir, dass ein Backend-Agent den Endpoint fertiggestellt hat, auf den der Frontend-Agent wartet, weil „sagen" eine Nachricht in einem Terminal war, das niemand beobachtet.
An diesem Punkt ist die Lösung keine bessere Notiz. Es geht darum, den Arbeitskontext vollständig von den Agents weg und auf eine gemeinsame Task zu verlagern, aus der jeder Agent und jede Person liest und in die sie zurückschreibt. Eine Task in Sharkly hält das Ziel, die Abnahmekriterien, den Diff, die Blocker und die Diskussion in einem Datensatz. Ausführung, Blocker, Ergebnisse und Follow-up fließen in die Task-Timeline zurück, sodass der Agent-Wechsel gar kein Export mehr ist. Du weist die Task neu zu; der nächste Agent liest denselben Datensatz, in den der letzte geschrieben hat.
Hier wird auch die Aufteilung zwischen Mensch und Agent sauber. Agents recherchieren, führen aus, testen und berichten an die Task. Menschen geben die Richtung vor, erteilen die Befugnis und nehmen das Ergebnis ab. Die Automatisierung endet dort, wo Team-Urteilsvermögen gefragt ist, und der Datensatz, den der nächste Bearbeiter liest, ist derselbe, den ein Reviewer liest. Das funktioniert nur, weil der Kontext nicht mehr in einer Session gefangen ist.
Hier ist das ehrliche Entscheidungspaar. Wenn du einen Agent in einem Terminal auf einem Repo laufen lässt, brauchst du nichts davon; der Kontext verlässt nie den Raum, also gibt es nichts zu bewahren. Greif nach einer gemeinsamen Task, sobald der Kontext einen Wechsel überleben muss – ob dieser Wechsel von Agent zu Agent, von Agent zu Mensch oder einfach zu dir morgen früh geht. Wenn du weiter mehrere Coding-Agents nutzen willst, statt dich auf ein Ökosystem festzulegen, ist genau diese Portabilität der Punkt: Dein Workflow überlebt, egal welchen Agent du als Nächstes wählst, weil der Kontext nie in einem von ihnen gespeichert war. Das ist auch das Setup, mit dem du Claude Code und Codex gemeinsam auf einer Codebasis laufen lassen kannst, ohne dass einer bei der Übergabe blind wird, und es passt natürlich zu Worktrees, einem Checkout pro Aufgabe, damit parallele Agents nicht kollidieren.
Die Checkliste, die du heute durchgehen kannst
Arbeite das der Reihe nach durch. Die ersten drei kosten nichts; die vierte ist das, wozu du übergehst, wenn die ersten drei nicht mehr mithalten.
- Vereinheitliche die Regeln-Datei. Verlinke
CLAUDE.md,AGENTS.mdundGEMINI.mdper Symlink auf eine Quelle. Beschränke sie auf repo-weite Konventionen, keine Aufgabendetails. - Schreib vor jedem Wechsel eine Übergabenotiz. Ziel, geänderte Dateien, was verifiziert wurde, offene Frage. Der aktuelle Agent kann sie entwerfen; du fügst sie beim nächsten ein.
- Entscheide den Wechsel anhand der Aufgabe, nicht aus Gewohnheit. Wähle den Agent passend zur vorliegenden Arbeit, mit einem Routing-Leitfaden, statt dich auf das gerade offene Terminal zu verlassen.
- Verlagere den Kontext von den Agents weg, wenn Notizen nicht mehr skalieren. Sobald du mehr als ein paar Agents oder Repos jonglierst, lege Ziel, Zustand und Review auf eine gemeinsame Task, damit ein Wechsel eine Neuzuweisung ist und keine erneute Erklärung.
Wenn du bereits mehrere Agents laufen lässt und jedes Mal denselben Kontext neu erzählst, wenn du wechselst, ist das genau das Problem, um das herum Sharkly gebaut ist: ein Ort, an dem die Tasks, Fortschritte und Ergebnisse jedes Agents sichtbar bleiben, sodass der Kontext den Wechsel überlebt.
