Discussion on "Session memory is not project memory. It fixes the same complaint."

Oliver Zehentleitner · 2026-09-23T10:46:30.427Z

The most common complaint about coding agents is the same on every forum: a new session starts from nothing. The explanation you gave yesterday is gone, the decision you made together is gone, the wro

I'd add validity metadata to promoted knowledge: source or commit, scope, owner, and what superseded it. An architectural decision can be durable but apply only to one module or version. Without scope and freshness, project memory becomes another stale source of truth. Agents should revalidate older notes against the current code and tests before treating them as constraints.

there's a third one hiding in between: memory inside one long session. both of yours cover the gap between sessions, but compaction eats stuff mid run too. building grunz (coding agent on open models) the worst case we hit was the goal itself getting summarized into something vague, and the agent restarting the plan like it was a brand new task. keep the why would probably catch the decisions, but does it also pin what the user originally asked for?

That's a good third layer: working memory inside the current session.

Keep the Why deliberately wouldn't pin the original prompt verbatim - that would turn project memory into a session log.

But if part of the request becomes durable project intent, a constraint, or a decision, that distilled part should survive in context/.

If compaction loses the current task goal before that point, I'd treat that as a session/runtime problem rather than project memory.

The live graph is a good illustration of what happens after something crosses that durability threshold: it becomes connected repository knowledge rather than another isolated session note.

https://keepthewhy.com/dashboard/live/#graph

Grunz's example is a really good illustration of the boundary.

This split matches what I’ve seen building agent tools. Personal memory is useful, but anything the whole project needs should live with the code.

Exactly. Personal memory and project memory solve different problems.

If the knowledge should survive people, sessions and tools, keeping it with the code gives it the same ownership, history and review process as the project itself.

That's the core idea behind Keep the Why.

The distinction also makes me think about how information should move between the two layers. Not everything an agent learns during a session deserves to become project memory. A temporary workaround, one-off debugging observation, and an architectural decision have very different lifetimes. A useful pattern could be to treat promotion into project memory as an explicit step: the agent identifies a finding, captures the evidence and scope, and only then proposes it as durable project knowledge. That would reduce the risk of turning every session observation into repository noise while still making important reasoning available to future sessions and teammates.

I like that framing a lot - especially the idea of a durability threshold between session observations and project knowledge.

If you ever feel like exploring this further, contributions and discussions are very welcome here:

github.com/oliver-zehentleitner/keep-the-why

This is exactly the kind of edge case I want the project to get better at.

A rejection made only in PR review seems to miss both the clone and session memory. Does Keep the Why pick it up, or does someone carry it in?

Good edge case.

If the rejection exists only in PR review comments, Keep the Why cannot magically see it from the clone.

It gets picked up when an agent with access to that review context processes the feedback - for example during review, revision, or merge work - and records the rationale into context/.

Otherwise someone has to carry it in.

That is actually the boundary I care about: PR comments are transient discussion; once a rejection matters to future work, the reasoning should become repository knowledge.

Makes sense to me. The case I'd watch is a PR a person rejects and simply closes, since no agent reviews, revises or merges it, and I suspect that's how many rejections end.

Logging every tool call as a receipt changed how I debug agents. When a run goes sideways I replay the receipt trail instead of guessing from chat. Cheap to store and it cuts the mystery hours.

Yes - I’d put that in a third bucket: execution trace.

Session memory helps the agent continue. Project memory preserves what the project must not forget. Receipts preserve what actually happened during a run.

All three reduce different kinds of forgetting, and the receipt trail is invaluable when you need evidence instead of reconstruction.

Search Hashnode

Session memory is not project memory. It fixes the same complaint.

Responses12