Last Tuesday I spent forty minutes that I had already spent. An hour earlier, in one editor, we had decided to route a notification through the retry queue instead of writing it straight to the database: direct writes tied delivery to the request's fate, and a partial failure would have dropped the event with no replay. I typed that constraint into that session's chat, moved on, and switched to another tool to run the backfill migration. The new session started from the files on disk, saw no recorded decision, and calmly proposed the direct write as the obvious clean answer. I re-explained the tradeoff, pushed back, compromised on a half measure, and by lunch the design was weaker than the version I had closed the hour before.
The chat transcript from the first session did not travel with me. The decision did not live anywhere the second session could read. So the second agent treated the question as open and re-answered it from first principles, which usually means it landed on the most visible, most obvious option on screen.
What actually got lost
The rejected alternative vanished. You picked queue B over queue A for a reason that is rarely visible in code: backpressure, replay semantics, a failure mode nobody wants to reproduce. The new session sees queue A on screen and no note saying why it lost, so it looks attractive again.
The forcing constraint disappeared. "Not direct, because a partial failure drops the event" is the load-bearing fact. It lived in a chat bubble that closed when you switched tools. Without it, every option looks equally available and the model reopens the choice.
The session starts from the code, not the conversation. A fresh context window contains files, diffs, and package names. It does not contain the rejected design, the customer constraint, the incident that ruled out an approach, or the two hours you spent debating before converging. It samples from what it can see, and what it can see usually points one direction.
Relitigation ends in compromise, not recovery. When an agent reopens a settled decision in the middle of other work, you usually do not have the energy to defend the full original reasoning. You split the difference, pick a middle option that satisfies nobody, and the constraint quietly erodes.
Why the model defaults to reopening settled choices
The model has no memory of your prior session. Given an open-looking question, it behaves correctly: it proposes a reasonable answer from the current code. It has no signal that the question was already answered and closed, because that signal was never written into a place it reads. This is not stubbornness or overconfidence; it is the honest behavior of a context window that began empty.
The failure is on the persistence side, not the model side. A decision that exists only in a closed chat is, from the next session's point of view, a decision that was never made.
The habits that keep a closed decision closed
Write the decision down where the next session reads. A short note near the code beats a chat history. Three lines are enough: the option chosen, the option rejected, and the forcing constraint that ruled the rejected one out, with a date. Place it beside the module it governs so a fresh agent loads it with the files.
Record the forcing constraint, not just the winner. "Use the retry queue" alone can be re-litigated. "Use the retry queue; a direct write drops the event on partial failure, and we have no replay" cannot, because the reason travels with the choice.
Read the note before proposing. When you hand a new session the task, tell it to read the existing decision block first. If it still proposes the rejected alternative, the note is missing the constraint, not the agent being wrong.
Point it to the artifact instead of arguing in chat. When it reopens a settled choice, do not relitigate from memory; send it to the note and ask whether the forcing constraint changed. Most of the time it did not, and the proposal retracts on its own.
Keep non-goals next to the choice. State what this change must not do, so a fresh session cannot invent a plausible requirement that the original decision explicitly excluded.
Decisions that survive a tool switch live in a durable artifact
The same problem shows up for API behavior. You settle how an endpoint should respond on a missing field, move to another tool to generate a client, and the fresh session re-derives a friendlier status code because the prose in a README drifted and nothing machine-readable carried the contract. The durable answer lives in the spec, diffed against the live endpoint rather than re-explained in every session. That local-first loop is the one we built into Powerduck: the spec stays the source of truth, and a closed contract does not get reopened just because the context window changed.
What I check before I switch tools
- Is the chosen option written down where the next session reads it, or only in this chat?
- Did I record the rejected alternative and the forcing constraint that ruled it out?
- Are the non-goals stated, so the new session cannot invent an excluded requirement?
- When the next agent proposes the rejected option, can I point it to a note instead of re-arguing from memory?
A closed decision stays closed only when it leaves the chat and lands somewhere the next session can read. Otherwise every tool switch starts the debate over, and you pay the same reasoning cost a second time.
