Every AI coding session starts from zero. Your product shouldn't.

You open a new coding-agent session and explain the product again.

Not the repository. The agent can inspect that. You explain why signup now comes before download. Why a technically simple shortcut was rejected. Why one audience matters more than another. Why a test exists even though the happy path already passes.

The agent understands. The work is good. The session ends.

Two weeks later, another capable agent proposes the same rejected shortcut with complete confidence.

This is usually described as an AI memory problem. That is only partly right. The deeper problem is that teams keep asking one kind of context to do the job of another. Chat history, code context, and product-decision memory are different things — and a useful system needs to know which one it is preserving.

Chat history remembers the conversation

Chat history is chronological. It records what someone asked, what the agent answered, which ideas were explored, and how the conversation moved. That can be useful when you need to reconstruct a recent exchange. It is a poor long-term source of product truth.

The important decision may be buried between discarded options, debugging output, and a plan that changed three messages later. Two conversations may contain conflicting conclusions. A long thread may explain the decision perfectly but never state whether it still applies. More history does not automatically produce more understanding. It can produce a larger search problem.

A recent Hacker News discussion about memory for coding agents made this distinction directly: the useful unit is not the complete transcript, but smaller pieces of knowledge such as decisions, constraints, and recurring principles. The same discussion also surfaced the hard part. Someone still has to decide what deserves to persist.

That is product judgment, not storage.

Code context remembers what exists

Code context is different. It tells an agent how the system works now. The repository can reveal the current route, schema, tests, dependencies, and conventions. Repository instructions can add the rules the code does not express cleanly. GitHub documents repository-wide, path-specific, and agent instructions for exactly this purpose. OpenAI likewise recommends maintaining an AGENTS.md file so Codex can carry naming conventions, business logic, known quirks, and non-obvious dependencies across prompts.

This is valuable. Every agent should not have to rediscover how to build the project or which package owns authentication. But code is strongest at describing the present implementation. It is weaker at explaining the product decision that produced it.

A test can prove that signup happens before download. It cannot tell a future agent whether that order exists to establish account ownership, preserve attribution, support a cross-device handoff, or merely satisfy a temporary launch constraint. A comment can help, but comments scattered across implementation files are not a product decision trail.

Code tells the agent what is true. Product memory tells it why that truth matters.

Product memory remembers the decision

A product decision is bigger than the sentence "put signup before download." Requirements documents get closer, but they only describe what the team intends to deliver. Product memory also preserves why that intent survived its alternatives, which evidence supported it, and what later observation would justify a different call. That makes it useful before implementation, during review, and after the result becomes visible.

The durable record is closer to this:

1. Decision: require a completed signup before showing the desktop download.
2. Intended outcome: establish an account relationship before activation.
3. Evidence and rationale: acquisition is now measured at confirmed signup; download is an activation step.
4. Constraints: mobile visitors can sign up but cannot install the desktop app on that device.
5. Rejected alternatives: direct anonymous download and an email-only gate.
6. Revisit when: qualified signup falls while downstream activation does not improve.
7. Connected work: landing-page changes, cloud account flow, analytics events, Ads conversion, and the release handoff.

That record gives the next agent the reasoning needed to preserve the decision or challenge it responsibly, instead of a frozen instruction to obey forever.

The revisitation condition matters as much as the rationale. Without it, memory becomes dogma. A decision that was sensible during launch may become harmful after the product, audience, or evidence changes.

Good product memory therefore needs two properties that chat archives rarely provide:

• it is inspectable, so a person can trace why the decision exists;
• it is correctable, so new evidence can reshape or replace it without erasing history.

Perfect recall isn't the goal. You want continuity with an audit trail.

What should survive the session?

Not every exchange deserves to become permanent context. Persist information that would change a future decision or implementation:

• the audience and outcome the work serves;
• a product decision and its rationale;
• a hard constraint or risk;
• an assumption that remains unproven;
• a rejected alternative that is likely to return;
• the evidence that would reopen the decision;
• the work and observed result connected to it.

Do not preserve every brainstorm, intermediate answer, or abandoned implementation detail. Long, undifferentiated memory makes retrieval less reliable. It also turns old speculation into apparent fact.

So the useful question stops being "How do we make the agent remember everything?" and becomes "What would we regret having to rediscover?"

A practical decision record for any repository

You do not need a dedicated product-memory system to improve the next session. Start with one short decision record alongside the work — seven fields:

• Decision:
• Outcome we want:
• Evidence and rationale:
• Constraints:
• Alternatives rejected:
• Revisit when:
• Related issue, task, pull request, release, or metric:

Write it when the decision is made, not after the implementation becomes confusing. Link it from the task that changes the code. If new evidence reverses the call, append the new decision rather than rewriting the old one as if it never existed.

Keep repository instructions focused on stable engineering context: build commands, architecture boundaries, security rules, testing expectations, and known operational hazards. Keep product decisions in a trail that can preserve alternatives, evidence, and change over time.

The distinction reduces two common failures:

1. An agent follows an old decision after its assumptions have expired.
2. An agent reopens a settled decision because the current code cannot explain it.

Neither failure is fixed by a larger context window alone.

Where Motriz fits

Motriz does not treat product memory as a transcript to replay. The Journey keeps evidence, assumptions, decisions, and rationale inspectable. The same persistent co-founder remains available while the product moves into Build, carrying journey, task, and repository context. Repository knowledge gives coding agents the current codebase context in the background, while the decision trail preserves why the work exists.

That separation is deliberate. An agent should be able to inspect the repository without inventing product history from code. It should also be able to trace an approved task back to the product decision that created it.

The result is not an agent that remembers everything. It is a product that does not forget why it became what it is.

If you want to see how decisions stay connected to real repository work, see how the Motriz journey works. If the next decision is still unproven, start with how to validate an idea before you build it.