Yesterday, you spent dozens of turns working with an Agent.

You clarified the request, changed the code, and ran tests. The entire conversation is still there. So is the commit history. Yet when you reopen the project today, you still have to ask:

Where exactly did we stop? Which conclusions were verified, and which were only discussed? What remains risky or unfinished? What should happen next, and what must not be changed?

If answering those questions requires scrolling through a long conversation and reconstructing the context, you saved history—not project memory.

Chat history tells you what was said. Project memory tells you how to continue.

Chat history is useful. It preserves exploration and helps explain why a particular sentence appeared.

But a conversation is organized by time. The information required for the next action is usually scattered:

  • A verified fact may appear near the beginning.
  • A test result may be buried in the middle.
  • An unresolved risk may be mentioned once at the end.
  • The most important boundary may be a three-day-old instruction: “Do not change this.”

A longer chat does not automatically create a clearer project. Complete storage prevents loss; project memory makes resumption possible.

There is one practical test:

Could another person, another Agent, or your future self safely take the next step without repeating the old work?

If not, the record is still an archive.

Useful project memory needs only four things

Project memory does not need to be long. It should be short enough to update and precise enough to trust.

1. Verified facts

Record only what has been confirmed in code, a real interface, logs, tests, or an actual result.

“It should work” is not a fact. “The import entry is visible and one real import completed” is a fact.

This tells the next operator which ground is solid.

2. The change and its evidence

Do not write only “fixed the import issue.” Say what changed and what proves it.

For example:

Empty files now return a traceable error; the import-empty.csv case passed.

The change explains what happened. The evidence keeps it from becoming an unsupported claim.

3. Unfinished risks

The dangerous part of a handoff is often not forgetting completed work. It is forgetting what remains unproven.

Write it plainly:

Large-file performance has not been verified.

That sentence prevents one passing case from being mistaken for a reliable import path.

4. The next action and its boundary

“Continue optimizing” is not a next action. A useful next action has an object, an action, and a completion signal.

For example:

Complete one real import with a 10 MB sample. Do not change the existing field mapping.

The first sentence starts the work. The second prevents the work from drifting.

A 150-character relay card can be more useful than 150 chat turns

Put those four elements together:

Goal: help a new user finish the first import. Confirmed: the CSV entry works. Changed: empty files now show a traceable error; import-empty.csv passed. Open risk: large-file performance. Next: run a real 10 MB import. Keep field mapping unchanged.

It does not repeat the entire discussion. It keeps what the next action needs:

  • why the work exists;
  • what is already true;
  • what is still unknown;
  • what happens next;
  • which boundary must hold.

That is the difference between a conversation summary and project memory.

A summary asks, “What did this conversation discuss?” Project memory asks, “How can this project move forward?”

Better me…[truncated 23 chars]