Why does my AI keep forgetting how my app works?

Because each new conversation starts with only what the AI is given. Your earlier chats don’t come with it unless something saves them. The fix is a short file of decisions, kept with your code: (1) write down the decisions that must survive, (2) keep them in one file in your repository, (3) keep that file short, (4) ask the AI which rules apply before it changes anything, and (5) update the file at the end of every session. A founder can do all five, with no developer and no code.

Why it gets worse as your product grows

Early on, forgetting costs little. The product fits in a few files, and you can explain it again in a minute.

Months later, your product depends on dozens of choices you made along the way. Prices round down, not up. Trial accounts last 14 days. Refunds over a certain amount go to you, not to an automatic rule. Most of these aren’t obvious from the code, and each one was agreed in a chat the AI no longer sees.

A session is one sitting of work with the AI. Each new one starts with you explaining the product again. Leave out one choice, and the next change can undo it.

What the AI carries from one session to the next

An AI starts each conversation knowing only what it is given. That means the files it reads, any instructions saved for it, and what you type.

Your earlier chats aren’t part of that unless your platform saves something from them. Even within one long conversation, the earliest messages can fall outside what the AI takes in at once. Some products shorten an old conversation into a summary, and details can be lost.

The code does carry over. But code shows what was built, not why. A price that rounds down looks like a mistake unless something says it was chosen.

How to tell the AI has lost track

It asks questions you’ve already answered. You explained last week how trial accounts work, and today it asks again.

It brings back something you removed. A page or an option you took out returns in a later change.

It “corrects” a choice you made on purpose. A shortcut you agreed to, such as skipping a login on the pricing page, is reversed as if it were a bug.

Each of these means a decision lived only in a conversation, not in anything the AI reads.

Five steps to keep your decisions from getting lost

1. Write down the decisions that must survive

Start a plain-language file and give it an obvious name, such as “product decisions.” List the choices that aren’t obvious from the code.

• Business rules. “Prices round down to the nearest cent.” “A refund over $100 needs my approval.”
• Deliberate exceptions. “Anyone can see the pricing page without signing in. Keep it that way.”
• What was removed, and why. “We removed guest checkout in March because of fraud. Don’t add it back.”
• The services you rely on. “Card payments use our existing payment provider. Don’t add a second one.”
• Words with a specific meaning. “A workspace is a team account, not a single user.”

Write each line as an instruction the AI can follow. A list with one decision per line is easier to check than a paragraph.

2. Store the file with your code

A repository holds your code and the record of every change made to it. Save the decisions file there, beside the code.

Any AI that opens the project can read the file, and a developer you hire later sees it on their first day. Each edit to it is recorded too, so you can see when a decision changed. A product without a repository needs that move first, and moving to a normal GitHub workflow describes it step by step.

At the start of each session, ask the AI to read the file before it does anything else. Some platforms can be set to read a named file automatically, so check your settings.

3. Keep it short enough to be read

One development team that keeps such a file warns that if it turns into a 500-line manifesto, the AI starts ignoring parts of it (opens in a new tab). Their advice is to keep it sharp and prune it regularly.

Aim for about a page. When a rule no longer applies, delete it. When two rules say the same thing, merge them. Put the rules that are costly to break at the top: anything about money, logins, or customer data.

4. Ask which rules apply before any change

A file helps only if the AI has read it. Before a change, ask: “Which rules in the decisions file apply to this change?”

If the answer leaves out a rule you expected, point to it before any code is written. A missed rule costs a minute to catch here and much more after the change reaches your users.

5. Add today’s decisions before you stop

Most decisions are made during the work. Before you close a session, ask: “What did we decide today that isn’t in the decisions file yet?” Read the answer, keep what’s true, and add it.

Remove the rules you’ve changed your mind about in the same step. An outdated rule can do more harm than a missing one, because the AI will follow it.

What to keep out of the file

Passwords and keys. Everyone who works on the code can read the file, and so can any AI that opens the project. Keys for paid services belong in the separate settings your platform provides for secrets, not in a text file.

Customer details. Names, email addresses, and orders don’t belong there. Describe the rule, not the customer it came from.

Long explanations. If a decision needs a page of background, put that page in its own file. The decisions file then names it in one line. A short reason, such as “because of fraud,” still fits on the line itself.

How Forged handles this

Forged keeps a written record of your product as it works, and each plan and build starts from it.

Dimension	The Forged approach
Your decisions	Your answers, choices, and Forged’s assumptions, listed on one Decisions page
Your own documents	Files such as pricing rules or specs, read each time Forged plans, builds, or reviews
Where your documents live	As files in your own repository, beside your code
What Forged learns as it works	Short notes about your code, each showing when it last changed
Keeping those notes current	When a feature is merged in Forged, its notes are usually compared with the code
When a new plan conflicts	Forged asks about the earlier decision first

Your decisions are kept in one place. The Memory page in Forged opens on Decisions. It lists your answers to a plan’s questions, the options you picked, and the assumptions Forged made while building, newest first. Each row opens the plan or feature where the decision was made. When a new plan contradicts one of your decisions, Forged names the earlier decision and asks about it first.

Your rules are read every time. On the Documents tab, you add files such as pricing rules, product specs, or notes about how your customers work. Forged reads them each time it plans, builds, reviews, or answers in chat. A document of up to about 8,000 characters is read in full. The files are kept in your own repository, so they stay with your code.

Its notes are compared with the code. As it works, Forged writes short notes about your code, listed on the Forged’s notes tab. When a feature is merged in Forged, Forged usually compares its notes with the code, then keeps, rewords, or drops each one. You can remove any note, and Ask Forged, the chat within Forged, can save one you want kept.

Your questions, answered

Should I keep one long conversation going?

No. Start a new one for each change.

A long conversation can lose its early messages, and it mixes many changes together. A fresh session that starts from the decisions file is easier to keep on track.

Is a decisions file the same as documentation?

No. A decisions file is much shorter.

Documentation explains how the product works. A decisions file lists only the choices the AI must not undo. Start with the file. Documentation can come later.

How much should I write down?

About a page, to start.

Add a line each time you settle something that isn’t obvious from the code. Read it through once a month, and delete what no longer holds.

What if my platform already has a memory feature?

Use it, and keep the file too.

A memory feature usually stays with the platform that provides it. A file in your repository goes wherever your code goes, including to a developer or to a different platform.

Give Forged the decisions your product depends on

Connect your repository and add your decisions file on the Documents tab.

Forged reads it every time it plans or builds. Each change then arrives in your repository as a pull request, a proposed change that shows what it does and how it was checked.