How do you get an AI to remember what it needs to know about a project?

The question usually arrives after an assistant has forgotten something it was told two days earlier, and the instinct is to look for a memory setting. That is the wrong layer. Whatever retention a given product offers, it is opaque, it varies, and it is not inspectable — you cannot open it, read what it thinks it knows, or correct an entry that is wrong. Anything load-bearing needs to live somewhere you can read.

The mechanism that works everywhere is a plain file that gets supplied at the start of a session: project instructions, a brief, a context document, whatever the tool calls it. Its job is not to describe the project. It is to record the things that would otherwise be re-explained, re-decided or re-litigated. Decisions that have been made and are closed. Constraints that are not negotiable. Names and identifiers that are easy to get wrong. Conventions the work must follow.

What does not belong is anything the system can find out for itself, and this is where these documents go bad. A file listing what every folder contains is duplicating something inspectable, and it will drift out of date silently while continuing to be believed. The same applies to status, progress and anything with a date attached. The test is whether the fact is discoverable: if the system could establish it by looking, leave it out, and if it could not, write it down.

The second failure is accumulation. These files grow because adding a line is the obvious response to any mistake, and nothing ever gets removed. A long instruction file dilutes itself — every instruction competes for attention with every other one — and past a certain length the system follows the document approximately rather than exactly. Pruning is maintenance, not tidying, and the practical rule is that an instruction which has not been needed for a month is a candidate for deletion.

The third is that written decisions rot. A constraint recorded in March may have been reversed in June by a conversation nobody wrote down, and the file will keep asserting it with total confidence. Dating entries helps. Recording why a decision was made helps more, because a reader can then tell whether the reason still holds, which is not something the decision alone can tell them.

For work that spans several sessions there is a second document doing a different job: what is currently in progress and what the next step is. Keeping that separate from the durable decisions is worth the small overhead, because the two have opposite lifespans. Mixing them produces a file whose stale half discredits the reliable half, and readers cannot tell which half they are looking at.