Varför beslut i AI-chattar går förlorade, och var du ska spara dem

Beslut som fattas i ett samtal med ChatGPT eller Claude går förlorade eftersom en chatt inte har något tillstånd. Ingenting i den märker en rad som ”det här bestämde vi”, ingenting knyter raden till arbetet den påverkar, och en ny chatt börjar tom. Lösningen är att låta AI:n skriva ner beslutet där arbetet finns, som en kort post med skälen, och att låta nästa session läsa de posterna innan den agerar.

Vi gör Weft. Fakta om andra produkter kommer från deras officiella sidor och kontrollerades den 27 oktober 2026. Idén att en tråd ”saknar tillstånd” kommer från Hypertasks artikel om Slack-trådar. Den här guiden tillämpar den på AI-chattar.

Varför försvinner beslut som fattas med ChatGPT eller Claude?

Du lägger fyrtio minuter med en assistent på att väga två databasleverantörer, två prismodeller eller två sätt att strukturera ett API. Du bestämmer dig för ett. Resonemanget är bra, assistenten håller med, och du går vidare till nästa sak.

En vecka senare finns slutsatsen fortfarande i den chatten, någonstans ovanför tvåhundra andra meddelanden. En ny chatt vet ingenting om den. En kollega såg den aldrig. Och om du öppnar en annan AI-klient nästa dag, till exempel en kodagent i terminalen, börjar den klienten från noll och kanske glatt föreslår det alternativ du valde bort.

Det här är inget disciplinproblem. Ett samtal är en följd av meddelanden. Det har inget fält för ”beslutat”, ingen ägare, ingen länk till en uppgift och inget sätt att säga ”det här ersatte det vi sa i tisdags”. En avgjord fråga och en övergiven fråga ser likadana ut när de har scrollat förbi.

Löser inte chattminnet redan det här?

Inte för det här jobbet. Många assistenter kan nu komma ihåg saker om dig mellan chattar, och det är användbart för preferenser och bakgrund. Men det minnet tillhör en produkt och ett konto. Det är skrivet för att den assistenten ska använda det, inte som en post som en person kan granska rad för rad, och en annan AI-klient kan inte läsa det. Det säger inte heller vilken uppgift ett val gällde eller vilket tidigare val det ersatte.

En beslutslogg har andra krav. Den måste gå att hitta för de människor och agenter som jobbar med projektet, gå att läsa för vilken AI-klient som än tar över arbetet härnäst, vara knuten till det arbetet och vara ärlig om historiken: när ett beslut ändras ska det gamla synas kvar med skälet till att det ersattes.

Vad räknas som ett beslut värt att spara?

Spara ett val när någon rimligen kunde ha valt annorlunda och valet kommer att forma senare arbete. Bra exempel:

• Att välja ett verktyg, en leverantör eller ett bibliotek framför ett annat.
• Att medvetet släppa något (”inget värvningsprogram det här kvartalet”).
• Att sätta en regel som arbetet måste följa (”alla priser visas med moms inräknad i EU”).
• Att ändra ett tidigare val, med skälet.
• En läxa som lärts den hårda vägen (”kör inte migreringen under kontorstid”).

Spara inte:

• Idéer som du bollade men inte antog.
• Steg i själva arbetet (de hör hemma i uppgiften och dess resultat).
• Något som personen inte har gått med på än, om det inte tydligt är markerat som förslag.
• Fakta som vem som helst kan slå upp igen på en minut.

Ett användbart test: om en ny AI-session var på väg att göra om det här valet, skulle du vilja att den stannade och läste varför? Om ja, spara det.

Hur ser en bra beslutspost ut?

Håll den kort och behåll skälen. Formatet nedan är en lätt version av MADR (Markdown Architectural Decision Records), som är vad Wefts verktyg record_decision använder:

Titel:        Filuppladdningar: objektlagring, inte databasen
Utfall:       Uppladdade filer läggs i objektlagring; databasen sparar
              bara filnyckeln och metadata.
Status:       accepted
Sammanhang:   Användare bifogar filer på upp till 50 MB. Att spara dem i
              databasen skulle göra säkerhetskopiorna långsamma och stora.
Alternativ:   1. Objektlagring   + billigt, säkerhetskopiorna förblir små
                                 - en tjänst till att konfigurera
              2. Databaskolumn   + ett ställe för allt
                                 - säkerhetskopiorna växer med varje uppladdning
Konsekvenser: Vi behöver signerade URL:er för nedladdningar.
              Att radera en uppgift måste också radera dess filer.
Ompröva när:  Vi behöver söka i filernas innehåll.
Uppgift:      Filuppladdningar

• Titel namnger beslutet så att du hittar det när du skummar.
• Utfall är en mening som en nykomling kan agera på.
• Sammanhang är det som var sant vid tillfället. Det är den del som försvinner först ur minnet.
• Alternativ listar bara det som faktiskt vägdes, inte alternativ som hittats på i efterhand.
• Konsekvenser inkluderar de nackdelar ni accepterade, så att ingen ”upptäcker” dem senare som buggar.
• Ompröva när säger vad som skulle göra valet fel.

Hur sparar Weft en beslutspost?

Weft är en uppgiftstavla som dina AI-klienter når via MCP på https://letsweft.com/api/mcp. Tre av dess 32 verktyg hanterar beslut:

• record_decision tar en titel och ett utfall, plus sammanhang, upp till fem alternativ med för- och nackdelar, konsekvenser och villkoret för omprövning. Det kan kopplas till en uppgift (taskId) eller ett projekt. Posterna är oföränderliga: för att ändra en registrerar AI:n ett nytt beslut med supersedesId som pekar på det gamla, och den gamla posten ligger kvar, markerad som ersatt.
• get_context returnerar arbetsytans gällande beslut och lärdomar, nyast först, packade inom en tokenbudget (800 token som standard). Det kan avgränsas till ett projekt eller en uppgift. Varje rad har sitt datum, ett ersatt beslut visas aldrig, och rader som inte fick plats räknas i stället för att döljas.
• get_task_history i läget decisions listar varje beslut som registrerats om en uppgift, inklusive granskningsutslag och deras skäl.

record_decision har ett andra användningsområde: att vidarebefordra ett utslag som personen gav i samtalet om arbete som väntar på hens granskning (godkänt, omarbeta, slopat eller uppskjutet). Verktygsbeskrivningen säger åt AI:n att den här är budbärare, inte beslutsfattare, så den ska aldrig använda detta för att godkänna sitt eget arbete.

Eftersom posterna aldrig redigeras på plats förblir historiken ärlig. Om du byter leverantör i mars finns januaribeslutet kvar, markerat som ersatt, och marsposten säger varför.

Hur ber jag min AI att spara beslut?

Anslut Weft till din AI-klient och klistra sedan in en instruktion som den här i början av en chatt, eller i klientens egna instruktioner eller projektfil om den har en sådan:

När vi gör ett verkligt val i den här chatten (vi väljer ett alternativ framför ett annat,
vi släpper något, eller vi ändrar ett tidigare val), spara det i Weft med
record_decision innan vi går vidare:
- title: beslutet, namngivet med några ord
- outcome: valet som en mening
- context: det som var sant och tvingade fram valet
- options: bara de alternativ vi faktiskt vägde, med för- och nackdelar
- consequences: vad som följer, bra och dåligt
- confirmation: när vi bör ompröva det
- taskId eller project: uppgiften eller projektet det gäller
Om det ändrar ett tidigare beslut, skicka supersedesId i stället för att redigera.
Spara inte småprat, gissningar eller saker jag inte har gått med på.
Om jag inte har bestämt mig än, använd status "proposed".
I början av allt arbete som inte är trivialt, anropa get_context först och berätta
vilka tidigare beslut som gäller.

Att ansluta tar en minut. I ChatGPT är Weft en publicerad app i pluginkatalogen, tillgänglig på alla planer inklusive Free (uppsättning). I Claude Code är det ett kommando (uppsättning). Claude.ai och Claude Desktop lägger till det som en egen koppling. Inloggningen sker med OAuth i webbläsaren, så det finns ingen nyckel att kopiera, och Weft utfärdar refresh-token, så klienten förnyar inloggningen själv. Uppsättningssidor för andra klienter, bland dem Cursor och Codex, finns i dokumentationen.

Vad händer när jag byter från ChatGPT till Claude Code nästa dag?

Här är fallet som instruktionen är byggd för.

1. På måndagen planerar du en funktion i ChatGPT. Du bestämmer att uppladdningar ska sparas i objektlagring i stället för i databasen, och ChatGPT anropar record_decision med sammanhanget, båda alternativen och konsekvenserna, kopplat till uppgiften ”Filuppladdningar”.
2. På tisdagen öppnar du Claude Code i kodförrådet. Om du inte har anslutit den än: claude mcp add --transport http weft https://letsweft.com/api/mcp.
3. Du ber den ta uppladdningsuppgiften. Innan den skriver kod anropar den get_context för uppgiften, eller get_task_history i läget decisions, och får tillbaka måndagens post.
4. Den bygger mot objektlagring i stället för att öppna frågan igen. Om den hittar ett verkligt skäl till att valet är fel kan den föreslå ett nytt beslut som ersätter måndagens, och du bestämmer.

Båda klienterna läser samma tavla och samma beslut, eftersom posten finns i Weft, inte i någon av chattarna. Varje OAuth-anslutning är en egen aktör, och tavlan visar namnet varje klient registrerade sig med, så du kan se vilken anslutning som skapade vilken uppgift. För att köra flera agenter på en tavla utan krockar, se flera AI-agenter, en tavla.

Var ska beslut från ChatGPT hamna?

Fyra vanliga ställen, jämförda utifrån vad en beslutslogg behöver:

Poängen är inte att chatt eller dokument är dåliga. Chatten är där du tänker. Beslutet behöver kopieras ut ur chatten till något med tillstånd, i det ögonblick det fattas, av den part som redan är med i samtalet: AI:n.

Ersätter det här vår dokumentation eller wiki?

Nej. Weft har ingen dokumentation eller wiki, och försöker inte vara det. Långa förklaringar, introduktionsguider och designbeskrivningar hör hemma i ditt dokumentationsverktyg. En beslutspost är medvetet liten: ett val, dess skäl och vad som ersatte det. Om ditt team redan sparar beslutsposter i en wiki och alla AI-klienter du använder kan läsa den, kan det räcka. Weft är användbart när besluten fattas i AI-chattar och nästa läsare ofta är en annan AI. Funderar du på Notion för det här, se alternativ till Notion för AI-uppgifter.

Två andra ärliga begränsningar. Weft läser inte dina chattar: ett beslut sparas bara när AI:n anropar record_decision, och det är därför instruktionen ovan spelar roll. Och AI:n kan missbedöma vad som räknas som ett beslut, så läs get_context då och då och ersätt det som blev fel.

Vad kostar det?

Att spara och läsa beslut fungerar på Free-planen, som innehåller 50 aktiva uppgifter och 200 AI-verktygsanrop i månaden. Varje anrop till record_decision eller get_context räknas som ett anrop. Pro kostar $7 per plats i månaden eller $60 per plats om året, med obegränsat antal uppgifter och anrop (priser). Weft har inga AI-krediter: tänkandet sker i din egen AI-klient, och Weft lagrar bara tavlan och dess poster.

Kan jag inte bara be ChatGPT sammanfatta besluten i slutet av en chatt?

Det kan du, och det hjälper. Men sammanfattningen finns fortfarande i den chatten eller där du klistrar in den. Den är inte knuten till uppgiften, en annan AI-klient kan inte läsa den, och när beslutet ändras finns ingen post om vad det ersatte. Att spara varje beslut när det fattas undviker alla tre.

Sparar AI:n beslut utan att jag ber om det?

Beskrivningen av verktyget record_decision säger åt AI:n att använda det så fort användaren gör ett verkligt val i samtalet, så vissa klienter gör det. Lita inte på det. Den inklistrade instruktionen gör det uttryckligt, och du kan alltid säga ”spara det beslutet”.

Kan ett beslut redigeras om det sparades fel?

Inte på plats. Posterna är oföränderliga. Spara ett korrigerat beslut med supersedesId som pekar på det felaktiga. Den gamla posten ligger kvar, markerad som ersatt, och get_context slutar visa den.

Behöver beslut en uppgift?

Nej. Ett beslut kan kopplas till en uppgift, till ett projekt eller till ingetdera. Att koppla det till en uppgift gör att get_task_history visar det bredvid det arbetet, och get_context kan avgränsas till det.

Är det här samma sak som Wefts arbetsminne?

Nej. Arbetsminnet (korta inlärda anteckningar) är en separat Pro-funktion. Beslutsposter kommer från record_decision, och koden begränsar dem inte till Pro.

Vad gäller om jag använder mer än en AI-klient?

Det är huvudskälet att göra det här. ChatGPT, Claude Code, Cursor eller Codex som är anslutna till samma Weft-arbetsyta läser alla samma beslut via get_context, så den andra klienten öppnar inte frågor som den första redan avgjort.