Why decisions made in AI chats get lost, and where to keep them
Decisions made in ChatGPT or Claude vanish when the chat scrolls away; record them on the board, linked to the task, so the next AI session reads them first.
Weft is the AI task manager for solo founders and small teams.
By Andrei Finogeev ·
Decisions made in a ChatGPT or Claude conversation get lost because a chat has no state. Nothing in it marks a line as "this is what we decided", nothing ties that line to the work it affects, and a new chat starts empty. The fix is to have the AI write the decision down where the work lives, as a short record with its reasons, and to have the next session read those records before it acts.
We make Weft. Facts about other products come from their official pages, checked on 27 October 2026. The idea that a thread "has no state" comes from Hypertask's article on Slack threads. This guide applies it to AI chats.
Why do decisions made with ChatGPT or Claude disappear?
You spend forty minutes with an assistant weighing two database providers, two pricing models or two ways to structure an API. You settle on one. The reasoning is good, the assistant agrees, and you move on to the next thing.
A week later the conclusion is still in that chat, somewhere above two hundred other messages. A new chat knows nothing about it. A teammate never saw it. And if you open a different AI client the next day, for example a coding agent in your terminal, that client starts from zero and may cheerfully propose the option you rejected.
This is not a discipline problem. A conversation is a sequence of messages. It has no field for "decided", no owner, no link to a task, and no way to say "this replaced what we said on Tuesday". A decided question and an abandoned one look the same once they scroll away.
Doesn't chat memory already solve this?
Not for this job. Many assistants can now remember things about you between chats, and that is useful for preferences and background. But that memory belongs to one product and one account. It is written for that assistant to use, not as a record a person can review line by line, and another AI client cannot read it. It also does not say which task a choice was about or which earlier choice it replaced.
A decision log has different requirements. It needs to be findable by the people and agents working on the project, readable by whatever AI client picks up the work next, tied to that work, and honest about history: when a decision changes, the old one should stay visible with the reason it was replaced.
What counts as a decision worth recording?
Record a choice when someone could reasonably have chosen differently and the choice will shape later work. Good examples:
- Picking one tool, vendor or library over another.
- Dropping something on purpose ("no referral program this quarter").
- Setting a rule the work must follow ("all prices shown with VAT included in the EU").
- Changing an earlier choice, with the reason.
- A lesson learned the hard way ("do not run the migration during business hours").
Do not record:
- Ideas you floated and did not adopt.
- Steps of the work itself (that belongs in the task and its result).
- Anything the person has not agreed to yet, unless it is clearly marked as proposed.
- Facts anyone can look up again in a minute.
A useful test: if a new AI session were about to undo this choice, would you want it to stop and read why? If yes, record it.
What does a good decision record look like?
Keep it short and keep the reasons. The format below is a light version of MADR (Markdown Architectural Decision Records), which is what Weft's record_decision tool uses:
Title: File uploads: object storage, not the database
Outcome: Uploaded files go to object storage; the database keeps
only the file key and metadata.
Status: accepted
Context: Users attach files up to 50 MB. Keeping them in the
database would make backups slow and large.
Options: 1. Object storage + cheap, backups stay small
- one more service to configure
2. Database column + one place for everything
- backups grow with every upload
Consequences: We need signed URLs for downloads.
Deleting a task must also delete its files.
Revisit when: We need to search inside file contents.
Task: File uploads- Title names the decision so you can find it by scanning.
- Outcome is one sentence a newcomer can act on.
- Context is what was true at the time. This is the part that disappears first from memory.
- Options lists only what was actually weighed, not alternatives invented afterwards.
- Consequences includes the downsides you accepted, so nobody "discovers" them later as bugs.
- Revisit when says what would make the choice wrong.
How does Weft keep a decision record?
Weft is a task board your AI clients reach over MCP at https://letsweft.com/api/mcp. Three of its 32 tools handle decisions:
- record_decision takes a title and outcome, plus context, up to five options with pros and cons, consequences and the condition to revisit under. It can be linked to a task (taskId) or a project. Records are immutable: to change one, the AI records a new decision with supersedesId pointing at the old one, and the old record stays, marked superseded.
- get_context returns the workspace's live decisions and lessons, newest first, packed to a token budget (800 tokens by default). It can be narrowed to a project or a task. Each line carries its date, a superseded decision never appears, and lines that did not fit are counted rather than hidden.
- get_task_history in decisions mode lists every decision recorded about one task, including review verdicts and their reasons.
record_decision has a second use: relaying a verdict the person gave in conversation about work waiting for their review (accepted, rework, dropped or deferred). The tool description tells the AI it is the messenger here, not the decider, so it should never use this to accept its own work.
Because records are never edited in place, the history stays honest. If you switch providers in March, the January decision is still there, marked superseded, and the March record says why.
How do I ask my AI to record decisions?
Connect Weft to your AI client, then paste an instruction like this at the start of a chat, or into the client's custom instructions or project file if it has one:
When we make a real choice in this chat (we pick one option over another,
we drop something, or we change an earlier choice), record it in Weft with
record_decision before we move on:
- title: the decision, named in a few words
- outcome: the choice as one sentence
- context: what was true that forced the choice
- options: only the options we actually weighed, with pros and cons
- consequences: what follows, good and bad
- confirmation: when we should revisit it
- taskId or project: the task or project this is about
If it changes an earlier decision, pass supersedesId instead of editing.
Do not record small talk, guesses, or things I have not agreed to.
If I have not committed yet, use status "proposed".
At the start of any non-trivial work, call get_context first and tell me
which past decisions apply.Connecting takes a minute. In ChatGPT, Weft is a published app in the plugin directory, available on every plan including Free (setup). In Claude Code it is one command (setup). Claude.ai and Claude Desktop add it as a custom connector. Sign-in is OAuth in the browser, so there is no key to copy, and Weft issues refresh tokens, so the client renews the sign-in itself. Setup pages for other clients, including Cursor and Codex, are in the docs.
What happens when I switch from ChatGPT to Claude Code the next day?
Here is the case the instruction is built for.
- On Monday you plan a feature in ChatGPT. You decide to store uploads in object storage rather than the database, and ChatGPT calls record_decision with the context, both options and the consequences, linked to the "File uploads" task.
- On Tuesday you open Claude Code in the repository. If you have not connected it yet:
claude mcp add --transport http weft https://letsweft.com/api/mcp. - You ask it to pick up the uploads task. Before writing code it calls get_context for that task, or get_task_history in decisions mode, and gets Monday's record back.
- It builds against object storage instead of re-opening the question. If it finds a real reason the choice is wrong, it can propose a new decision that supersedes Monday's, and you decide.
Both clients read the same board and the same decisions, because the record lives in Weft, not in either chat. Each OAuth connection is its own actor, and the board shows the name each client registered with, so you can see which connection created which task. For running several agents on one board without collisions, see multiple AI agents, one board.
Where should decisions from ChatGPT end up?
Four common places, compared on what a decision log needs:
| Where the decision ends up | Findable later | Readable by another AI | Tied to the work | Can be superseded with a reason |
|---|---|---|---|---|
| Chat history | Only if you remember which chat, and search finds it | No, another client cannot open it | No | No, a later message contradicts it without marking it |
| Doc or notes page | Yes, if someone wrote it up | Only if that AI is connected to the doc | Loosely, through links | Usually by editing, which tends to erase the old reasoning |
| Task comment | Yes, on that task | If the AI can read the tracker's comments | Yes | Not explicitly, newer comments do not mark older ones replaced |
| Decision record on the Weft board | Yes, through get_context and get_task_history | Yes, any client connected to the workspace over MCP | Yes, by task or project | Yes, supersedesId keeps the old record, marked superseded |
The point is not that chat or docs are bad. Chat is where you think. The decision needs to be copied out of the chat into something with state, at the moment it is made, by the party already in the conversation: the AI.
Does this replace our docs or wiki?
No. Weft has no docs or wiki, and it is not trying to be one. Long explanations, onboarding guides and design write-ups belong in your docs tool. A decision record is deliberately small: one choice, its reasons, and what replaced it. If your team already keeps decision records in a wiki and every AI client you use can read it, that may be enough. Weft is useful when the decisions are made in AI chats and the next reader is often another AI. If you are weighing Notion for this, see Notion alternatives for AI tasks.
Two other honest limits. Weft does not read your chats: a decision gets recorded only when the AI calls record_decision, which is why the instruction above matters. And the AI can misjudge what counts as a decision, so read get_context now and then and supersede anything it got wrong.
What does it cost?
Recording and reading decisions works on the Free plan, which includes 50 active tasks and 200 AI tool calls a month. Every record_decision or get_context call counts as one call. Pro is $7 per seat a month or $60 per seat a year, with unlimited tasks and calls (pricing). Weft has no AI credits: the thinking happens in your own AI client, and Weft only stores the board and its records.
- Can't I just ask ChatGPT to summarize decisions at the end of a chat?
- You can, and it helps. But the summary still lives in that chat or wherever you paste it. It is not tied to the task, another AI client cannot read it, and when the decision changes there is no record of what it replaced. Recording each decision as it is made avoids all three.
- Will the AI record decisions without being asked?
- The record_decision tool description tells the AI to use it whenever the user makes a real choice in conversation, so some clients will. Do not rely on it. The pasted instruction makes it explicit, and you can always say "record that decision".
- Can a decision be edited if it was recorded wrong?
- Not in place. Records are immutable. Record a corrected decision with supersedesId pointing at the wrong one. The old record stays, marked superseded, and get_context stops showing it.
- Do decisions need a task?
- No. A decision can be linked to a task, to a project, or to neither. Linking it to a task means get_task_history shows it next to that work, and get_context can be narrowed to it.
- Is this the same as Weft's work memory?
- No. Work memory (short learned notes) is a separate Pro feature. Decision records come from record_decision, and the code does not restrict them to Pro.
- What if I use more than one AI client?
- That is the main reason to do this. ChatGPT, Claude Code, Cursor or Codex connected to the same Weft workspace all read the same decisions through get_context, so the second client does not reopen questions the first one settled.