Hvorfor beslutninger i KI-chatter går tapt, og hvor du bør ta vare på dem

Beslutninger tatt i en samtale med ChatGPT eller Claude går tapt fordi en chat ikke har noen tilstand. Ingenting i den merker en linje som «dette er det vi bestemte», ingenting knytter den linjen til arbeidet den påvirker, og en ny chat starter tom. Løsningen er å la KI-en skrive beslutningen ned der arbeidet bor, som en kort registrering med begrunnelsen, og la neste økt lese de registreringene før den handler.

Vi lager Weft. Fakta om andre produkter er hentet fra deres offisielle sider, kontrollert 27. oktober 2026. Tanken om at en tråd «ikke har noen tilstand», kommer fra Hypertasks artikkel om Slack-tråder. Denne guiden bruker den på KI-chatter.

Hvorfor forsvinner beslutninger tatt med ChatGPT eller Claude?

Du bruker førti minutter med en assistent på å veie to databaseleverandører, to prismodeller eller to måter å strukturere et API på. Du lander på én. Resonnementet er godt, assistenten er enig, og du går videre til neste ting.

En uke senere ligger konklusjonen fortsatt i den chatten, et sted over to hundre andre meldinger. En ny chat vet ingenting om den. En kollega så den aldri. Og åpner du en annen KI-klient dagen etter, for eksempel en kodeagent i terminalen, starter den klienten fra null og kan muntert foreslå alternativet du forkastet.

Dette er ikke et disiplinproblem. En samtale er en rekke meldinger. Den har ikke noe felt for «bestemt», ingen eier, ingen kobling til en oppgave og ingen måte å si «dette erstattet det vi sa på tirsdag» på. Et avgjort spørsmål og et forlatt spørsmål ser like ut når de har rullet forbi.

Løser ikke chat-hukommelsen allerede dette?

Ikke for denne jobben. Mange assistenter kan nå huske ting om deg mellom chatter, og det er nyttig for preferanser og bakgrunn. Men den hukommelsen tilhører ett produkt og én konto. Den er skrevet for at den assistenten skal bruke den, ikke som en registrering en person kan gå gjennom linje for linje, og en annen KI-klient kan ikke lese den. Den sier heller ikke hvilken oppgave et valg gjaldt, eller hvilket tidligere valg det erstattet.

En beslutningslogg har andre krav. Den må kunne finnes av personene og agentene som jobber med prosjektet, kunne leses av den KI-klienten som tar arbeidet videre, være knyttet til det arbeidet og være ærlig om historikken: når en beslutning endres, bør den gamle forbli synlig med grunnen til at den ble erstattet.

Hva regnes som en beslutning verdt å registrere?

Registrer et valg når noen med rimelighet kunne ha valgt annerledes og valget vil forme senere arbeid. Gode eksempler:

• Å velge ett verktøy, én leverandør eller ett bibliotek framfor et annet.
• Å droppe noe med vilje («ikke noe vervingsprogram dette kvartalet»).
• Å sette en regel arbeidet må følge («alle priser vises med mva. inkludert i EU»).
• Å endre et tidligere valg, med begrunnelsen.
• En lærdom man har fått på den harde måten («ikke kjør migreringen i arbeidstiden»).

Ikke registrer:

• Ideer du luftet og ikke tok i bruk.
• Stegene i selve arbeidet (de hører hjemme i oppgaven og resultatet).
• Noe personen ikke har sagt ja til ennå, med mindre det er tydelig merket som foreslått.
• Fakta hvem som helst kan slå opp igjen på et minutt.

En nyttig test: hvis en ny KI-økt var i ferd med å omgjøre dette valget, ville du da ønsket at den stoppet opp og leste hvorfor? Hvis ja, registrer det.

Hvordan ser en god beslutningsregistrering ut?

Hold den kort og behold begrunnelsen. Formatet nedenfor er en lett versjon av MADR (Markdown Architectural Decision Records), som er det Wefts record_decision-verktøy bruker:

Title:        Filopplastinger: objektlagring, ikke databasen
Outcome:      Opplastede filer går til objektlagring; databasen beholder
              bare filnøkkelen og metadata.
Status:       accepted
Context:      Brukere legger ved filer på opptil 50 MB. Å ha dem i
              databasen ville gjort sikkerhetskopiene trege og store.
Options:      1. Objektlagring   + billig, sikkerhetskopiene forblir små
                                 - én tjeneste til å konfigurere
              2. Databasekolonne + ett sted for alt
                                 - sikkerhetskopiene vokser med hver opplasting
Consequences: Vi trenger signerte URL-er for nedlastinger.
              Å slette en oppgave må også slette filene dens.
Revisit when: Vi trenger å søke i innholdet i filene.
Task:         Filopplastinger

• Title gir beslutningen et navn, så du finner den ved å skumme.
• Outcome er én setning en nykommer kan handle ut fra.
• Context er det som var sant på det tidspunktet. Det er denne delen som forsvinner først fra hukommelsen.
• Options lister bare det som faktisk ble veid, ikke alternativer som er funnet på i etterkant.
• Consequences inkluderer ulempene dere godtok, så ingen «oppdager» dem senere som feil.
• Revisit when sier hva som ville gjort valget feil.

Hvordan tar Weft vare på en beslutningsregistrering?

Weft er en oppgavetavle KI-klientene dine når over MCP på https://letsweft.com/api/mcp. Tre av de 32 verktøyene håndterer beslutninger:

• record_decision tar en tittel og et utfall, pluss kontekst, opptil fem alternativer med fordeler og ulemper, konsekvenser og betingelsen for å se på den igjen. Den kan knyttes til en oppgave (taskId) eller et prosjekt. Registreringene kan ikke endres: for å endre en registrerer KI-en en ny beslutning med supersedesId som peker på den gamle, og den gamle registreringen blir stående, merket som erstattet.
• get_context returnerer arbeidsområdets gjeldende beslutninger og lærdommer, nyeste først, pakket inn i et tokenbudsjett (800 tokener som standard). Den kan avgrenses til et prosjekt eller en oppgave. Hver linje har med datoen, en erstattet beslutning vises aldri, og linjer som ikke fikk plass, telles i stedet for å skjules.
• get_task_history i decisions-modus lister hver beslutning som er registrert om én oppgave, inkludert dommer fra gjennomgang og begrunnelsene for dem.

record_decision har en annen bruk også: å formidle videre en dom personen ga i samtalen om arbeid som venter på gjennomgang (godtatt, omarbeid, forkastet eller utsatt). Verktøybeskrivelsen sier til KI-en at den her er budbringer, ikke den som bestemmer, så den skal aldri bruke dette til å godta sitt eget arbeid.

Fordi registreringene aldri redigeres der de står, forblir historikken ærlig. Bytter du leverandør i mars, ligger beslutningen fra januar der fortsatt, merket som erstattet, og registreringen fra mars sier hvorfor.

Hvordan ber jeg KI-en min om å registrere beslutninger?

Koble Weft til KI-klienten din, og lim så inn en instruks som denne i starten av en chat, eller i klientens egendefinerte instruksjoner eller prosjektfil hvis den har det:

Når vi tar et reelt valg i denne chatten (vi velger ett alternativ framfor et annet,
vi dropper noe, eller vi endrer et tidligere valg), registrerer du det i Weft med
record_decision før vi går videre:
- title: beslutningen, navngitt med noen få ord
- outcome: valget som én setning
- context: det som var sant og tvang fram valget
- options: bare alternativene vi faktisk veide, med fordeler og ulemper
- consequences: hva som følger av det, godt og dårlig
- confirmation: når vi bør se på det igjen
- taskId eller project: oppgaven eller prosjektet dette gjelder
Endrer det en tidligere beslutning, sender du supersedesId i stedet for å redigere.
Ikke registrer småprat, gjetninger eller ting jeg ikke har sagt ja til.
Har jeg ikke bestemt meg ennå, bruker du status "proposed".
Ved starten av alt arbeid som ikke er trivielt, kaller du get_context først og forteller meg
hvilke tidligere beslutninger som gjelder.

Det tar et minutt å koble til. I ChatGPT er Weft en publisert app i plugin-katalogen, tilgjengelig på alle planer, inkludert Free (oppsett). I Claude Code er det én kommando (oppsett). Claude.ai og Claude Desktop legger det til som en egendefinert kobling. Innloggingen er OAuth i nettleseren, så det er ingen nøkkel å kopiere, og Weft utsteder oppdateringstokener, så klienten fornyer innloggingen selv. Oppsettsider for andre klienter, blant dem Cursor og Codex, finner du i dokumentasjonen.

Hva skjer når jeg bytter fra ChatGPT til Claude Code dagen etter?

Her er tilfellet instruksen er laget for.

1. På mandag planlegger du en funksjon i ChatGPT. Du bestemmer at opplastinger skal lagres i objektlagring i stedet for i databasen, og ChatGPT kaller record_decision med konteksten, begge alternativene og konsekvensene, knyttet til oppgaven «Filopplastinger».
2. På tirsdag åpner du Claude Code i repoet. Har du ikke koblet den til ennå: claude mcp add --transport http weft https://letsweft.com/api/mcp.
3. Du ber den ta opplastingsoppgaven. Før den skriver kode, kaller den get_context for den oppgaven, eller get_task_history i decisions-modus, og får tilbake registreringen fra mandag.
4. Den bygger mot objektlagring i stedet for å åpne spørsmålet på nytt. Finner den en reell grunn til at valget er feil, kan den foreslå en ny beslutning som erstatter den fra mandag, og så bestemmer du.

Begge klientene leser den samme tavla og de samme beslutningene, fordi registreringen bor i Weft, ikke i noen av chattene. Hver OAuth-tilkobling er sin egen aktør, og tavla viser navnet hver klient registrerte seg med, så du kan se hvilken tilkobling som opprettet hvilken oppgave. For å kjøre flere agenter på én tavle uten kollisjoner, se flere KI-agenter, én tavle.

Hvor bør beslutninger fra ChatGPT havne?

Fire vanlige steder, sammenlignet på det en beslutningslogg trenger:

Poenget er ikke at chat eller dokumenter er dårlige. Chatten er der du tenker. Beslutningen må kopieres ut av chatten og inn i noe med tilstand, i det øyeblikket den tas, av den som allerede er med i samtalen: KI-en.

Erstatter dette dokumentasjonen eller wikien vår?

Nei. Weft har ingen dokumenter eller wiki, og prøver ikke å være det. Lange forklaringer, onboardingguider og designbeskrivelser hører hjemme i dokumentverktøyet ditt. En beslutningsregistrering er bevisst liten: ett valg, begrunnelsen og hva som erstattet det. Har teamet ditt allerede beslutningsregistreringer i en wiki og alle KI-klientene dere bruker, kan lese den, kan det være nok. Weft er nyttig når beslutningene tas i KI-chatter og neste leser ofte er en annen KI. Vurderer du Notion til dette, se alternativer til Notion for KI-oppgaver.

To andre ærlige begrensninger. Weft leser ikke chattene dine: en beslutning blir bare registrert når KI-en kaller record_decision, og derfor er instruksen over viktig. Og KI-en kan feilvurdere hva som regnes som en beslutning, så les get_context av og til og erstatt det den tok feil av.

Hva koster det?

Å registrere og lese beslutninger fungerer på Free-planen, som inkluderer 50 aktive oppgaver og 200 KI-verktøykall i måneden. Hvert record_decision- eller get_context-kall teller som ett kall. Pro koster 72 kr per plass i måneden eller 620 kr per plass i året, med ubegrenset med oppgaver og kall (priser). Weft har ingen KI-kreditter: tenkingen skjer i din egen KI-klient, og Weft lagrer bare tavla og registreringene.

Kan jeg ikke bare be ChatGPT oppsummere beslutningene på slutten av en chat?

Jo, og det hjelper. Men oppsummeringen bor fortsatt i den chatten eller der du limer den inn. Den er ikke knyttet til oppgaven, en annen KI-klient kan ikke lese den, og når beslutningen endres, finnes det ingen registrering av hva den erstattet. Å registrere hver beslutning idet den tas, unngår alle tre.

Kommer KI-en til å registrere beslutninger uten at jeg ber om det?

Beskrivelsen av record_decision ber KI-en bruke verktøyet hver gang brukeren tar et reelt valg i samtalen, så noen klienter vil gjøre det. Ikke stol på det. Den innlimte instruksen gjør det eksplisitt, og du kan alltid si «registrer den beslutningen».

Kan en beslutning redigeres hvis den ble registrert feil?

Ikke der den står. Registreringene kan ikke endres. Registrer en rettet beslutning med supersedesId som peker på den feilaktige. Den gamle registreringen blir stående, merket som erstattet, og get_context slutter å vise den.

Trenger beslutninger en oppgave?

Nei. En beslutning kan knyttes til en oppgave, til et prosjekt eller til ingen av delene. Å knytte den til en oppgave betyr at get_task_history viser den ved siden av det arbeidet, og at get_context kan avgrenses til den.

Er dette det samme som Wefts arbeidshukommelse?

Nei. Arbeidshukommelse (korte lærte notater) er en egen Pro-funksjon. Beslutningsregistreringer kommer fra record_decision, og koden begrenser dem ikke til Pro.

Hva om jeg bruker mer enn én KI-klient?

Det er hovedgrunnen til å gjøre dette. ChatGPT, Claude Code, Cursor eller Codex koblet til det samme Weft-arbeidsområdet leser alle de samme beslutningene via get_context, så den andre klienten åpner ikke på nytt spørsmål den første allerede har avgjort.