Warum Entscheidungen aus KI-Chats verloren gehen und wo du sie festhältst

Entscheidungen aus einem Gespräch mit ChatGPT oder Claude gehen verloren, weil ein Chat keinen Zustand hat. Nichts darin markiert eine Zeile als „das haben wir entschieden“, nichts verbindet diese Zeile mit der Arbeit, die sie betrifft, und ein neuer Chat startet leer. Die Lösung: Lass die KI die Entscheidung dort aufschreiben, wo die Arbeit lebt, als kurzen Datensatz mit Begründung, und lass die nächste Sitzung diese Datensätze lesen, bevor sie handelt.

Wir entwickeln Weft. Angaben zu anderen Produkten stammen von deren offiziellen Seiten, geprüft am 27. Oktober 2026. Die Idee, dass ein Thread „keinen Zustand hat“, stammt aus dem Artikel von Hypertask über Slack-Threads. Dieser Leitfaden wendet sie auf KI-Chats an.

Warum verschwinden Entscheidungen, die du mit ChatGPT oder Claude triffst?

Du verbringst vierzig Minuten mit einem Assistenten und wägst zwei Datenbankanbieter ab, zwei Preismodelle oder zwei Arten, eine API aufzubauen. Du entscheidest dich für eins. Die Begründung ist gut, der Assistent stimmt zu, und du machst mit dem Nächsten weiter.

Eine Woche später steht die Schlussfolgerung immer noch in diesem Chat, irgendwo über zweihundert anderen Nachrichten. Ein neuer Chat weiß nichts davon. Eine Kollegin hat sie nie gesehen. Und wenn du am nächsten Tag einen anderen KI-Client öffnest, etwa einen Coding-Agenten im Terminal, startet der bei null und schlägt womöglich fröhlich genau die Option vor, die du verworfen hast.

Das ist kein Disziplinproblem. Ein Gespräch ist eine Folge von Nachrichten. Es hat kein Feld für „entschieden“, keinen Verantwortlichen, keine Verbindung zu einer Aufgabe und keine Möglichkeit zu sagen „das ersetzt, was wir am Dienstag gesagt haben“. Eine entschiedene Frage und eine liegen gelassene sehen gleich aus, sobald sie weggescrollt sind.

Löst das Gedächtnis des Chats das nicht schon?

Nicht für diesen Zweck. Viele Assistenten können sich inzwischen zwischen Chats Dinge über dich merken, und das ist nützlich für Vorlieben und Hintergrund. Aber dieses Gedächtnis gehört zu einem Produkt und einem Konto. Es ist für den Assistenten geschrieben, nicht als Nachweis, den ein Mensch Zeile für Zeile prüfen kann, und ein anderer KI-Client kann es nicht lesen. Es sagt auch nicht, um welche Aufgabe es bei einer Wahl ging oder welche frühere Wahl sie ersetzt hat.

Ein Entscheidungsprotokoll hat andere Anforderungen. Es muss für die Menschen und Agenten am Projekt auffindbar sein, für jeden KI-Client lesbar, der die Arbeit als Nächstes aufnimmt, mit dieser Arbeit verknüpft und ehrlich mit seiner Geschichte: Wenn sich eine Entscheidung ändert, sollte die alte sichtbar bleiben, mit dem Grund, warum sie ersetzt wurde.

Welche Entscheidung lohnt sich festzuhalten?

Halte eine Wahl fest, wenn jemand vernünftigerweise anders hätte wählen können und die Wahl spätere Arbeit prägt. Gute Beispiele:

• Ein Tool, einen Anbieter oder eine Bibliothek einer anderen vorziehen.
• Etwas absichtlich streichen („kein Empfehlungsprogramm in diesem Quartal“).
• Eine Regel setzen, der die Arbeit folgen muss („in der EU alle Preise inklusive MwSt. anzeigen“).
• Eine frühere Wahl ändern, mit Begründung.
• Eine Lektion, die man auf die harte Tour gelernt hat („die Migration nicht während der Geschäftszeiten laufen lassen“).

Nicht festhalten:

• Ideen, die du ins Spiel gebracht, aber nicht übernommen hast.
• Schritte der Arbeit selbst (die gehören in die Aufgabe und ihr Ergebnis).
• Alles, dem der Mensch noch nicht zugestimmt hat, außer es ist klar als Vorschlag markiert.
• Fakten, die jeder in einer Minute wieder nachschlagen kann.

Ein nützlicher Test: Wenn eine neue KI-Sitzung gerade dabei wäre, diese Wahl rückgängig zu machen, würdest du wollen, dass sie anhält und liest, warum? Wenn ja, halte sie fest.

Wie sieht ein guter Entscheidungsdatensatz aus?

Halte ihn kurz und behalte die Begründung. Das Format unten ist eine schlanke Variante von MADR (Markdown Architectural Decision Records), die auch das Tool record_decision von Weft nutzt:

Titel:        Datei-Uploads: Object Storage, nicht die Datenbank
Ergebnis:     Hochgeladene Dateien gehen in den Object Storage; die Datenbank
              speichert nur den Dateischlüssel und Metadaten.
Status:       accepted
Kontext:      Nutzer hängen Dateien bis 50 MB an. Sie in der Datenbank
              zu halten, würde Backups langsam und groß machen.
Optionen:     1. Object Storage  + günstig, Backups bleiben klein
                                 - ein Dienst mehr zu konfigurieren
              2. Datenbankspalte + alles an einem Ort
                                 - Backups wachsen mit jedem Upload
Folgen:       Wir brauchen signierte URLs für Downloads.
              Eine Aufgabe zu löschen muss auch ihre Dateien löschen.
Neu bewerten: Wenn wir in Dateiinhalten suchen müssen.
Aufgabe:      Datei-Uploads

• Titel benennt die Entscheidung, damit du sie beim Überfliegen findest.
• Ergebnis ist ein Satz, nach dem jemand Neues handeln kann.
• Kontext ist, was damals galt. Das ist der Teil, der als Erstes aus dem Gedächtnis verschwindet.
• Optionen listet nur, was tatsächlich abgewogen wurde, keine nachträglich erfundenen Alternativen.
• Folgen enthält die Nachteile, die du in Kauf genommen hast, damit sie später niemand als Bugs „entdeckt“.
• Neu bewerten sagt, was die Wahl falsch machen würde.

Wie hält Weft einen Entscheidungsdatensatz fest?

Weft ist ein Aufgabenboard, das deine KI-Clients über MCP unter https://letsweft.com/api/mcp erreichen. Drei seiner 32 Tools kümmern sich um Entscheidungen:

• record_decision nimmt einen Titel und ein Ergebnis entgegen, dazu Kontext, bis zu fünf Optionen mit Vor- und Nachteilen, Folgen und die Bedingung für eine Neubewertung. Es lässt sich mit einer Aufgabe (taskId) oder einem Projekt verknüpfen. Datensätze sind unveränderlich: Um einen zu ändern, hält die KI eine neue Entscheidung mit supersedesId fest, die auf die alte zeigt, und der alte Datensatz bleibt, als abgelöst markiert.
• get_context liefert die gültigen Entscheidungen und Lektionen des Workspaces, neueste zuerst, gepackt in ein Token-Budget (standardmäßig 800 Tokens). Es lässt sich auf ein Projekt oder eine Aufgabe eingrenzen. Jede Zeile trägt ihr Datum, eine abgelöste Entscheidung erscheint nie, und Zeilen, die nicht hineinpassten, werden gezählt statt versteckt.
• get_task_history im Modus decisions listet jede zu einer Aufgabe festgehaltene Entscheidung auf, einschließlich Prüfurteilen und ihrer Gründe.

record_decision hat einen zweiten Zweck: ein Urteil weiterzugeben, das der Mensch im Gespräch über Arbeit gefällt hat, die auf seine Prüfung wartet (angenommen, überarbeiten, verworfen oder verschoben). Die Beschreibung des Tools sagt der KI, dass sie hier der Bote ist, nicht die Entscheiderin, und dass sie damit nie ihre eigene Arbeit annehmen darf.

Weil Datensätze nie an Ort und Stelle bearbeitet werden, bleibt die Geschichte ehrlich. Wenn du im März den Anbieter wechselst, ist die Entscheidung vom Januar noch da, als abgelöst markiert, und der Datensatz vom März sagt, warum.

Wie bitte ich meine KI, Entscheidungen festzuhalten?

Verbinde Weft mit deinem KI-Client und füg dann eine Anweisung wie diese am Anfang eines Chats ein, oder in die benutzerdefinierten Anweisungen oder die Projektdatei des Clients, falls er so etwas hat:

Wenn wir in diesem Chat eine echte Wahl treffen (wir ziehen eine Option einer anderen vor,
wir streichen etwas oder wir ändern eine frühere Wahl), halte sie mit record_decision
in Weft fest, bevor wir weitermachen:
- title: die Entscheidung, in wenigen Worten benannt
- outcome: die Wahl als ein Satz
- context: was galt und die Wahl erzwungen hat
- options: nur die Optionen, die wir wirklich abgewogen haben, mit Vor- und Nachteilen
- consequences: was daraus folgt, Gutes und Schlechtes
- confirmation: wann wir sie neu bewerten sollten
- taskId oder project: die Aufgabe oder das Projekt, um das es geht
Wenn sie eine frühere Entscheidung ändert, übergib supersedesId, statt zu bearbeiten.
Halte keinen Small Talk, keine Vermutungen und nichts fest, dem ich nicht zugestimmt habe.
Wenn ich mich noch nicht festgelegt habe, nutze den Status "proposed".
Ruf zu Beginn jeder nicht trivialen Arbeit zuerst get_context auf und sag mir,
welche früheren Entscheidungen gelten.

Das Verbinden dauert eine Minute. In ChatGPT ist Weft eine veröffentlichte App im Plugin-Verzeichnis, in jedem Tarif einschließlich Free (Einrichtung). In Claude Code ist es ein Befehl (Einrichtung). Claude.ai und Claude Desktop fügen es als eigenen Connector hinzu. Die Anmeldung läuft per OAuth im Browser, es gibt also keinen Schlüssel zu kopieren, und Weft stellt Refresh-Tokens aus, der Client erneuert die Anmeldung also selbst. Einrichtungsseiten für andere Clients, darunter Cursor und Codex, findest du in der Doku.

Was passiert, wenn ich am nächsten Tag von ChatGPT zu Claude Code wechsle?

Genau für diesen Fall ist die Anweisung gebaut.

1. Am Montag planst du ein Feature in ChatGPT. Du entscheidest, Uploads im Object Storage statt in der Datenbank zu speichern, und ChatGPT ruft record_decision mit Kontext, beiden Optionen und den Folgen auf, verknüpft mit der Aufgabe „Datei-Uploads“.
2. Am Dienstag öffnest du Claude Code im Repository. Falls du es noch nicht verbunden hast: claude mcp add --transport http weft https://letsweft.com/api/mcp.
3. Du bittest es, die Upload-Aufgabe zu übernehmen. Bevor es Code schreibt, ruft es get_context für diese Aufgabe auf, oder get_task_history im Modus decisions, und bekommt den Datensatz vom Montag zurück.
4. Es baut gegen den Object Storage, statt die Frage neu aufzurollen. Findet es einen echten Grund, warum die Wahl falsch ist, kann es eine neue Entscheidung vorschlagen, die die vom Montag ablöst, und du entscheidest.

Beide Clients lesen dasselbe Board und dieselben Entscheidungen, weil der Datensatz in Weft lebt, nicht in einem der Chats. Jede OAuth-Verbindung ist ein eigener Akteur, und das Board zeigt den Namen, mit dem sich jeder Client registriert hat, sodass du siehst, welche Verbindung welche Aufgabe angelegt hat. Wie du mehrere Agenten ohne Kollisionen auf einem Board laufen lässt, steht unter Mehrere KI-Agenten, ein Board.

Wo sollten Entscheidungen aus ChatGPT landen?

Vier gängige Orte, verglichen nach dem, was ein Entscheidungsprotokoll braucht:

Es geht nicht darum, dass Chat oder Dokumente schlecht wären. Im Chat denkst du. Die Entscheidung muss nur aus dem Chat in etwas mit Zustand übertragen werden, in dem Moment, in dem sie fällt, von der Partei, die ohnehin im Gespräch ist: der KI.

Ersetzt das unsere Doku oder unser Wiki?

Nein. Weft hat keine Doku- oder Wiki-Funktion und will keine sein. Lange Erklärungen, Onboarding-Leitfäden und Design-Beschreibungen gehören in dein Doku-Tool. Ein Entscheidungsdatensatz ist absichtlich klein: eine Wahl, ihre Gründe und was sie ersetzt hat. Wenn dein Team Entscheidungsdatensätze schon in einem Wiki führt und jeder KI-Client, den ihr nutzt, es lesen kann, reicht das vielleicht. Weft ist nützlich, wenn Entscheidungen in KI-Chats fallen und der nächste Leser oft eine andere KI ist. Wenn du dafür Notion in Betracht ziehst, siehe Notion-Alternativen für KI-Aufgaben.

Zwei weitere ehrliche Grenzen. Weft liest deine Chats nicht: Eine Entscheidung wird nur festgehalten, wenn die KI record_decision aufruft, deshalb ist die Anweisung oben wichtig. Und die KI kann falsch einschätzen, was als Entscheidung zählt, also lies ab und zu get_context und löse ab, was sie falsch erfasst hat.

Was kostet das?

Entscheidungen festhalten und lesen funktioniert im Free-Tarif, der 50 aktive Aufgaben und 200 KI-Tool-Aufrufe im Monat enthält. Jeder Aufruf von record_decision oder get_context zählt als ein Aufruf. Pro kostet € 7,74 pro Platz und Monat oder € 65,45 pro Platz und Jahr, mit unbegrenzt vielen Aufgaben und Aufrufen (Preise). Weft hat keine KI-Credits: Das Denken passiert in deinem eigenen KI-Client, und Weft speichert nur das Board und seine Datensätze.

Kann ich ChatGPT nicht einfach bitten, die Entscheidungen am Ende eines Chats zusammenzufassen?

Kannst du, und es hilft. Aber die Zusammenfassung lebt weiter in diesem Chat oder dort, wo du sie einfügst. Sie ist nicht mit der Aufgabe verknüpft, ein anderer KI-Client kann sie nicht lesen, und wenn sich die Entscheidung ändert, gibt es keinen Nachweis, was sie ersetzt hat. Jede Entscheidung in dem Moment festzuhalten, in dem sie fällt, vermeidet alle drei Probleme.

Hält die KI Entscheidungen fest, ohne dass ich darum bitte?

Die Beschreibung des Tools record_decision sagt der KI, dass sie es immer nutzen soll, wenn der Nutzer im Gespräch eine echte Wahl trifft, also tun das manche Clients. Verlass dich nicht darauf. Die eingefügte Anweisung macht es ausdrücklich, und du kannst jederzeit sagen „halte diese Entscheidung fest“.

Kann eine Entscheidung bearbeitet werden, wenn sie falsch festgehalten wurde?

Nicht an Ort und Stelle. Datensätze sind unveränderlich. Halte eine korrigierte Entscheidung mit supersedesId fest, die auf die falsche zeigt. Der alte Datensatz bleibt, als abgelöst markiert, und get_context zeigt ihn nicht mehr.

Brauchen Entscheidungen eine Aufgabe?

Nein. Eine Entscheidung kann mit einer Aufgabe, einem Projekt oder mit nichts verknüpft sein. Ist sie mit einer Aufgabe verknüpft, zeigt get_task_history sie neben dieser Arbeit, und get_context lässt sich darauf eingrenzen.

Ist das dasselbe wie das Arbeitsgedächtnis von Weft?

Nein. Das Arbeitsgedächtnis (kurze gelernte Notizen) ist eine separate Pro-Funktion. Entscheidungsdatensätze kommen aus record_decision, und der Code beschränkt sie nicht auf Pro.

Was, wenn ich mehr als einen KI-Client nutze?

Das ist der Hauptgrund, das zu tun. ChatGPT, Claude Code, Cursor oder Codex, mit demselben Weft-Workspace verbunden, lesen alle dieselben Entscheidungen über get_context, sodass der zweite Client keine Fragen neu aufrollt, die der erste geklärt hat.