Why ChatGPT Forgets Your Architectural Decisions — and How to Fix It (2026)

A decision is a constraint plus a reason

"We don't share the database between services" is half a decision. The other half is because the migration ordering caused two outages and the team owning the schema can't gate every deploy. Without the second half, the first half is a preference — and a preference loses to a plausible-sounding alternative every time.

This is why the architecture-decision-record practice exists at all: an ADR pairs the decision with the context that forced it and the consequences that follow, precisely because teams kept rediscovering that a bare decision doesn't survive contact with new people or new circumstances. An assistant is a new person every session.

The reason is what gets summarized away

Here's the mechanism that makes this worse than ordinary forgetting. ChatGPT's saved memory is short by design, because it's carried alongside every prompt. And since the memory rebuild OpenAI announced in June 2026, what you get is a memory summary — a synthesized account of what the system concluded about you, kept current over time — rather than a transcript of what you said.

Synthesis is the right trade for keeping a small memory useful, and the wrong one for decisions. Compress "don't share the database because migration ordering caused two outages" and the natural output is "prefers service-owned databases." The constraint is gone; the preference remains; the preference is overridable. You get an assistant that half-remembers your architecture as a style choice.

Rejected options are never written down

The most valuable content in an architectural discussion is the list of things you ruled out and why. It's also the content nobody records, because at the moment you rule something out it feels obvious and not worth writing.

Nothing in a chat workflow captures it. So the same three alternatives get proposed every quarter, and each time you spend twenty minutes re-deriving why they don't work — the pattern behind an assistant repeatedly resurfacing ideas you already rejected.

There's no file for it, unlike in a coding agent

Coding agents solved the availability half of this problem with files loaded on every request — which is why Cursor forgetting architectural decisions is usually fixable by writing a better rules file.

ChatGPT has no equivalent. There's no path it reads before answering. Custom instructions are small and global. A Project's attached files are scoped to that Project. Memory is a page or two. None of those is a decision log, so your architecture lives in whichever conversation you last discussed it in.

Decisions change and the old one doesn't get retracted

Architecture is versioned whether you version it or not. You revise the tenancy model in Q3, and every design done under the Q2 model was correct at the time. A chat-based workflow has no place to record that a decision superseded another one on a date — so you end up unable to interpret your own past work, which is the failure mode ADRs exist to prevent with their status field.

Explaining it again each time. Works, degrades. You're restating from memory, so the version you type in September is the punchy half of the version you worked out in July — and the constraint is the boring half.

Putting the top decisions in custom instructions. The right first move for two or three load-bearing constraints, and worth doing. The block is small, so you're choosing which decisions matter most, and it applies globally — wrong when you work on more than one system.

Saving decisions to memory. Fine for a couple of stable ones, and then you hit both walls: the space runs out — memory fills up and stops accepting new entries — and what survives is a synthesized paraphrase rather than the reasoning.

A Project with the architecture doc attached. The best built-in option. Scoped correctly, holds a real document rather than a summary. It's ChatGPT-only, files don't stay reliably in context across long sessions, and it doesn't help the quick question you ask in a normal chat.

Writing ADRs in the repo. The professional answer, and it deserves to be stated plainly rather than buried: a numbered docs/adr/ directory with decision, context, consequences, and status, committed and reviewed, is how architectural rationale is supposed to be preserved. It survives people leaving, it's diffable, and it doesn't depend on any vendor. If your team doesn't do this, start — it's more valuable than anything else in this piece.

The gap is that an ADR in your repo is invisible to the assistant you're actually thinking with. You wrote the reasoning down and ChatGPT still can't see it, so you paste the relevant one in, or more often don't.

Two moves, in this order.

Write decisions in the ADR shape, even informally. Title, status, the context that forced it, the decision, what it rules out, the consequences you accepted, and the date. The shape matters more than the tooling — it's what keeps the reason attached to the constraint, which is the whole failure this piece is about. Alternatives-considered is not an optional section; it's the part that stops re-litigation.

Then make the record reachable from the assistant. Not pasted — retrieved. A store the assistant reads from on every request means the decision arrives with its reason, its date, and its rejected alternatives, in the form you wrote them rather than a synthesis of them.

MemoryLake is a memory layer built for that — the decision records, the constraints, and the source documents in one store, readable from ChatGPT through the API and from MCP-capable tools like Claude and Codex directly. So the same decision reaches the design conversation, the coding agent writing the migration, and the engineer who joined in September.

Two boundaries worth stating. A memory layer does not replace committed ADRs for team governance — a decision record that isn't in version control isn't reviewable, and reviewability is half the point of the practice. And supplying a decision reliably raises how often it's honored; it doesn't guarantee the assistant honors it, because that's model behavior. What changes is that the constraint and its reason are present and current instead of absent or paraphrased.

Step 1: Create an API key

Generate a key and make your first request in about 30 seconds. Keep it in your environment or a secret manager rather than pasting it into a chat.

Step 2: Upload your first memories

Drop in the documents, images, and files where your decisions actually live: the ADRs, the design docs, the incident writeups that caused a constraint, the RFC someone wrote and everyone agreed to. Upload the sources rather than a tidied summary — the summary is where "because of the two outages" becomes "prefers service-owned databases."

Step 3: Connect your AI & agents

Give Claude, Codex, OpenClaw, and other AI agents access to memory via MCP or the API. ChatGPT has no MCP client, so the path there is the API: retrieve the relevant decisions and inject them into the prompt, a custom GPT's instructions, or the workflow that calls the model. Tools that speak MCP read the same store directly — which matters because the agent writing the code needs the same constraints as the assistant designing it.

The first difference is that the rejected option stays rejected. Ask about the reporting service and the shared-schema approach comes back already ruled out, with the outage history attached, instead of being proposed fresh.

The second is that design conversations start further along. You're not spending the first fifteen minutes re-establishing constraints; you're spending it on the actual question. That compounds — the more decisions accumulate in the record, the more each new conversation inherits.

The third is that superseded decisions become readable rather than confusing. A decision with a date and a status lets you say "that service was built under the pre-August tenancy model" instead of wondering why it looks wrong. This is the single property that makes past architecture interpretable.

And it stops being ChatGPT-specific. A tenancy decision constrains the coding agent as much as the design conversation, and an assistant that arrives without your project's context is the same problem in every tool. Once the record is in a shared store, they all inherit it.

Always write the forcing context

"We use event sourcing for orders" invites debate. "We use event sourcing for orders because finance requires a reconstructable audit trail and the previous mutable-state design failed a Q1 audit" ends it. The context is what converts a preference into a constraint, and it's the first thing lost when you restate from memory.

Record what you rejected, not just what you chose

Two lines per alternative: what it was, why not. This is the highest-value and least-written section, and it's the one that prevents the same proposal returning every quarter. If you write nothing else beyond the decision itself, write this.

Date everything and keep superseded decisions

Give each decision a date and a status, and when it changes, add the new one and mark the old superseded rather than deleting it. Deleting the old decision destroys your ability to understand code written under it. Undated decisions that disagree are worse than one honestly marked as of a date.

Keep the always-loaded set small

Whatever gets injected into every request should be your handful of hard constraints — the ones that would make an answer wrong, not merely unidiomatic. The full record belongs in retrieval. A wall of architectural history in front of every question crowds out the question.

Commit the ADRs anyway

Put the records in the repo under version control even with a memory layer in place. The store makes them reachable by your assistants; the repo makes them reviewable by your team, and a decision nobody reviewed isn't really a team decision. Use both for what each is good at.

ChatGPT forgets your architectural decisions because it keeps preferences, not constraints. There's no rules file it reads, its memory is a page or two carried on every request, and the current memory system synthesizes what it stores — so the reason behind a decision, which is the half that makes it binding, is exactly what gets compressed out.

The fix is old advice plus one new step. Write decisions in the ADR shape — context, decision, alternatives rejected, consequences, date, status — and commit them, because that's how architectural rationale survives people. Then put the record somewhere your assistants read from on every request, so the constraint and its reason arrive together instead of waiting for you to remember to paste them. Then the argument you had in July is still settled in September.