Blog

Waarom beslissingen in AI-chats verloren gaan, en waar je ze bewaart

Beslissingen uit ChatGPT of Claude verdwijnen als de chat wegscrolt; leg ze vast op het bord, gekoppeld aan de taak, zodat de volgende AI-sessie ze eerst leest.

Weft is het AI-takenbeheer voor solo-oprichters en kleine teams.

Alle artikelen

Door Andrei Finogeev ·

Beslissingen die je in een gesprek met ChatGPT of Claude neemt, gaan verloren omdat een chat geen toestand heeft. Niets erin markeert een regel als "dit hebben we besloten", niets koppelt die regel aan het werk waar hij over gaat, en een nieuwe chat begint leeg. De oplossing: laat de AI de beslissing opschrijven waar het werk staat, als kort record met de redenen, en laat de volgende sessie die records lezen voordat hij iets doet.

Wij maken Weft. Feiten over andere producten komen van hun officiële pagina's, gecontroleerd op 27 oktober 2026. Het idee dat een draad "geen toestand heeft" komt uit het artikel van Hypertask over Slack-draden. Deze gids past het toe op AI-chats.

Waarom verdwijnen beslissingen die je met ChatGPT of Claude neemt?

Je bent veertig minuten met een assistent bezig om twee databaseproviders, twee prijsmodellen of twee manieren om een API op te zetten tegen elkaar af te wegen. Je kiest er één. De redenering is goed, de assistent is het ermee eens, en je gaat door naar het volgende.

Een week later staat de conclusie nog steeds in die chat, ergens boven tweehonderd andere berichten. Een nieuwe chat weet er niets van. Een teamgenoot heeft hem nooit gezien. En open je de volgende dag een andere AI-client, bijvoorbeeld een codeeragent in je terminal, dan begint die bij nul en stelt hij misschien vrolijk de optie voor die je hebt afgewezen.

Dit is geen kwestie van discipline. Een gesprek is een reeks berichten. Het heeft geen veld voor "besloten", geen eigenaar, geen koppeling met een taak, en geen manier om te zeggen "dit vervangt wat we dinsdag zeiden". Een beantwoorde vraag en een opgegeven vraag zien er hetzelfde uit zodra ze weggescrold zijn.

Lost het geheugen van de chat dit niet al op?

Niet voor deze klus. Veel assistenten kunnen tegenwoordig tussen chats dingen over je onthouden, en dat is nuttig voor voorkeuren en achtergrond. Maar dat geheugen hoort bij één product en één account. Het is geschreven voor die assistent, niet als record dat een persoon regel voor regel kan nalopen, en een andere AI-client kan het niet lezen. Het zegt ook niet over welke taak een keuze ging of welke eerdere keuze hij verving.

Een beslissingslog heeft andere eisen. Hij moet vindbaar zijn voor de mensen en agents die aan het project werken, leesbaar voor welke AI-client het werk ook oppakt, gekoppeld aan dat werk, en eerlijk over de geschiedenis: als een beslissing verandert, hoort de oude zichtbaar te blijven met de reden waarom hij werd vervangen.

Wat telt als een beslissing die het vastleggen waard is?

Leg een keuze vast wanneer iemand redelijkerwijs anders had kunnen kiezen en de keuze later werk zal bepalen. Goede voorbeelden:

  • Eén tool, leverancier of bibliotheek verkiezen boven een andere.
  • Bewust iets laten vallen ("dit kwartaal geen referralprogramma").
  • Een regel vastleggen die het werk moet volgen ("in de EU worden alle prijzen inclusief btw getoond").
  • Een eerdere keuze wijzigen, met de reden.
  • Een les die je op de harde manier hebt geleerd ("draai de migratie niet tijdens kantooruren").

Leg niet vast:

  • Ideeën die je opperde en niet hebt overgenomen.
  • Stappen van het werk zelf (die horen in de taak en het resultaat ervan).
  • Alles waar de persoon nog niet mee heeft ingestemd, tenzij het duidelijk als voorstel is gemarkeerd.
  • Feiten die iedereen binnen een minuut opnieuw kan opzoeken.

Een handige toets: als een nieuwe AI-sessie op het punt stond deze keuze ongedaan te maken, zou je dan willen dat hij stopte en las waarom? Zo ja, leg hem vast.

Hoe ziet een goed beslissingsrecord eruit?

Houd het kort en houd de redenen erin. Het formaat hieronder is een lichte versie van MADR (Markdown Architectural Decision Records), en dat is wat de tool record_decision van Weft gebruikt:

Titel:        Bestandsuploads: objectopslag, niet de database
Uitkomst:     Geüploade bestanden gaan naar objectopslag; de database bewaart
              alleen de bestandssleutel en metadata.
Status:       accepted
Context:      Gebruikers voegen bestanden tot 50 MB toe. Ze in de
              database bewaren zou back-ups traag en groot maken.
Opties:       1. Objectopslag    + goedkoop, back-ups blijven klein
                                 - nog een dienst om in te stellen
              2. Databasekolom   + één plek voor alles
                                 - back-ups groeien met elke upload
Gevolgen:     We hebben ondertekende URL's nodig voor downloads.
              Een taak verwijderen moet ook zijn bestanden verwijderen.
Herzien als:  We binnen de inhoud van bestanden moeten zoeken.
Taak:         Bestandsuploads
  • Titel benoemt de beslissing, zodat je hem al scannend kunt vinden.
  • Uitkomst is één zin waar een nieuwkomer mee aan de slag kan.
  • Context is wat er op dat moment waar was. Dit deel verdwijnt het eerst uit het geheugen.
  • Opties noemt alleen wat echt is afgewogen, geen alternatieven die achteraf zijn bedacht.
  • Gevolgen bevat de nadelen die je hebt geaccepteerd, zodat niemand ze later als bugs "ontdekt".
  • Herzien als zegt wat de keuze verkeerd zou maken.

Hoe houdt Weft een beslissingsrecord bij?

Weft is een takenbord dat je AI-clients bereiken via MCP op https://letsweft.com/api/mcp. Drie van de 32 tools behandelen beslissingen:

  • record_decision neemt een titel en uitkomst, plus context, maximaal vijf opties met voor- en nadelen, gevolgen en de voorwaarde waaronder je hem herziet. Hij kan aan een taak (taskId) of een project worden gekoppeld. Records zijn onveranderlijk: om er een te wijzigen, legt de AI een nieuwe beslissing vast met supersedesId die naar de oude wijst, en het oude record blijft staan, gemarkeerd als vervangen.
  • get_context geeft de geldende beslissingen en lessen van de werkruimte terug, nieuwste eerst, ingepakt binnen een tokenbudget (standaard 800 tokens). Je kunt het beperken tot een project of een taak. Elke regel draagt zijn datum, een vervangen beslissing verschijnt nooit, en regels die er niet in pasten worden geteld in plaats van verborgen.
  • get_task_history in de modus decisions toont elke beslissing die over één taak is vastgelegd, inclusief oordelen bij beoordeling en hun redenen.

record_decision heeft een tweede gebruik: een oordeel doorgeven dat de persoon in een gesprek gaf over werk dat op beoordeling wacht (geaccepteerd, herwerken, laten vallen of uitgesteld). De toolbeschrijving zegt de AI dat hij hier de boodschapper is, niet degene die beslist, dus hij mag dit nooit gebruiken om zijn eigen werk te accepteren.

Omdat records nooit ter plekke worden bewerkt, blijft de geschiedenis eerlijk. Stap je in maart over op een andere provider, dan staat de beslissing van januari er nog, gemarkeerd als vervangen, en zegt het record van maart waarom.

Hoe vraag ik mijn AI om beslissingen vast te leggen?

Verbind Weft met je AI-client en plak dan een instructie zoals deze aan het begin van een chat, of in de aangepaste instructies of het projectbestand van de client als die er een heeft:

Wanneer we in deze chat een echte keuze maken (we kiezen de ene optie boven de andere,
we laten iets vallen, of we wijzigen een eerdere keuze), leg die dan vast in Weft met
record_decision voordat we verdergaan:
- title: de beslissing, in een paar woorden benoemd
- outcome: de keuze in één zin
- context: wat er waar was waardoor de keuze nodig was
- options: alleen de opties die we echt hebben afgewogen, met voor- en nadelen
- consequences: wat eruit volgt, goed en slecht
- confirmation: wanneer we erop terug moeten komen
- taskId of project: de taak of het project waar dit over gaat
Wijzigt het een eerdere beslissing, geef dan supersedesId mee in plaats van te bewerken.
Leg geen praatjes, gissingen of dingen waar ik niet mee heb ingestemd vast.
Heb ik me nog niet vastgelegd, gebruik dan status "proposed".
Roep aan het begin van elk niet-triviaal werk eerst get_context aan en vertel me
welke eerdere beslissingen van toepassing zijn.

Verbinden kost een minuut. In ChatGPT is Weft een gepubliceerde app in de plugindirectory, beschikbaar op elk plan, ook Free (setup). In Claude Code is het één commando (setup). Claude.ai en Claude Desktop voegen het toe als custom connector. Aanmelden gaat met OAuth in de browser, dus er is geen sleutel om te kopiëren, en Weft geeft refresh-tokens uit, dus de client vernieuwt de aanmelding zelf. Setuppagina's voor andere clients, waaronder Cursor en Codex, staan in de docs.

Wat gebeurt er als ik de volgende dag van ChatGPT naar Claude Code overstap?

Dit is het geval waarvoor de instructie gemaakt is.

  1. Op maandag plan je een feature in ChatGPT. Je besluit uploads in objectopslag te bewaren in plaats van in de database, en ChatGPT roept record_decision aan met de context, beide opties en de gevolgen, gekoppeld aan de taak "Bestandsuploads".
  2. Op dinsdag open je Claude Code in de repository. Heb je het nog niet verbonden: claude mcp add --transport http weft https://letsweft.com/api/mcp.
  3. Je vraagt het de uploadtaak op te pakken. Voordat het code schrijft, roept het get_context aan voor die taak, of get_task_history in de modus decisions, en krijgt het record van maandag terug.
  4. Het bouwt op objectopslag in plaats van de vraag opnieuw open te gooien. Vindt het een echte reden waarom de keuze verkeerd is, dan kan het een nieuwe beslissing voorstellen die die van maandag vervangt, en jij beslist.

Beide clients lezen hetzelfde bord en dezelfde beslissingen, omdat het record in Weft staat, niet in een van beide chats. Elke OAuth-verbinding is een eigen actor, en het bord toont de naam waarmee elke client zich registreerde, dus je kunt zien welke verbinding welke taak aanmaakte. Voor meerdere agents op één bord zonder botsingen, zie meerdere AI-agents, één bord.

Waar horen beslissingen uit ChatGPT terecht te komen?

Vier gebruikelijke plekken, vergeleken op wat een beslissingslog nodig heeft:

Waar de beslissing terechtkomtLater vindbaarLeesbaar voor een andere AIGekoppeld aan het werkTe vervangen met een reden
ChatgeschiedenisAlleen als je weet welke chat het was en zoeken hem vindtNee, een andere client kan hem niet openenNeeNee, een later bericht spreekt hem tegen zonder hem te markeren
Document of notitiepaginaJa, als iemand het heeft uitgeschrevenAlleen als die AI met het document verbonden isLosjes, via linksMeestal door te bewerken, wat de oude redenering vaak uitwist
Reactie op een taakJa, bij die taakAls de AI de reacties in de tracker kan lezenJaNiet expliciet, nieuwere reacties markeren oudere niet als vervangen
Beslissingsrecord op het Weft-bordJa, via get_context en get_task_historyJa, elke client die via MCP met de werkruimte verbonden isJa, per taak of projectJa, supersedesId houdt het oude record, gemarkeerd als vervangen

Het punt is niet dat chats of documenten slecht zijn. In de chat denk je na. De beslissing moet uit de chat worden overgezet naar iets met toestand, op het moment dat hij wordt genomen, door de partij die al in het gesprek zit: de AI.

Vervangt dit onze documentatie of wiki?

Nee. Weft heeft geen documenten of wiki, en probeert dat ook niet te zijn. Lange uitleg, onboardinggidsen en ontwerpbeschrijvingen horen in je documentatietool. Een beslissingsrecord is bewust klein: één keuze, de redenen, en wat hem verving. Houdt je team al beslissingsrecords bij in een wiki en kan elke AI-client die je gebruikt die lezen, dan is dat misschien genoeg. Weft is nuttig wanneer de beslissingen in AI-chats worden genomen en de volgende lezer vaak weer een AI is. Overweeg je hiervoor Notion, zie dan Notion-alternatieven voor AI-taken.

Nog twee eerlijke beperkingen. Weft leest je chats niet: een beslissing wordt alleen vastgelegd wanneer de AI record_decision aanroept, en daarom doet de instructie hierboven ertoe. En de AI kan verkeerd inschatten wat als beslissing telt, dus lees af en toe get_context en vervang wat hij fout had.

Wat kost het?

Beslissingen vastleggen en lezen werkt op het Free-plan, met 50 actieve taken en 200 AI-toolaanroepen per maand. Elke aanroep van record_decision of get_context telt als één aanroep. Pro kost $7 per plek per maand of $60 per plek per jaar, met onbeperkt taken en aanroepen (prijzen). Weft heeft geen AI-credits: het denkwerk gebeurt in je eigen AI-client, en Weft bewaart alleen het bord en zijn records.

Kan ik ChatGPT niet gewoon vragen om aan het eind van een chat de beslissingen samen te vatten?
Dat kan, en het helpt. Maar de samenvatting staat dan nog steeds in die chat of waar je hem ook plakt. Hij is niet gekoppeld aan de taak, een andere AI-client kan hem niet lezen, en als de beslissing verandert, is er geen record van wat hij verving. Elke beslissing vastleggen op het moment dat hij wordt genomen, voorkomt alle drie.
Legt de AI beslissingen vast zonder dat ik erom vraag?
De beschrijving van de tool record_decision zegt de AI hem te gebruiken wanneer de gebruiker in een gesprek een echte keuze maakt, dus sommige clients zullen dat doen. Reken er niet op. De geplakte instructie maakt het expliciet, en je kunt altijd zeggen "leg die beslissing vast".
Kan een beslissing worden bewerkt als hij verkeerd is vastgelegd?
Niet ter plekke. Records zijn onveranderlijk. Leg een gecorrigeerde beslissing vast met supersedesId die naar de verkeerde wijst. Het oude record blijft staan, gemarkeerd als vervangen, en get_context toont hem niet meer.
Hebben beslissingen een taak nodig?
Nee. Een beslissing kan aan een taak worden gekoppeld, aan een project, of aan geen van beide. Koppel je hem aan een taak, dan toont get_task_history hem naast dat werk, en kan get_context ertoe worden beperkt.
Is dit hetzelfde als het werkgeheugen van Weft?
Nee. Werkgeheugen (korte geleerde notities) is een aparte Pro-functie. Beslissingsrecords komen van record_decision, en de code beperkt ze niet tot Pro.
Wat als ik meer dan één AI-client gebruik?
Dat is de belangrijkste reden om dit te doen. ChatGPT, Claude Code, Cursor of Codex, verbonden met dezelfde Weft-werkruimte, lezen allemaal dezelfde beslissingen via get_context, dus de tweede client gooit geen vragen opnieuw open die de eerste al had beantwoord.