--- title: "Discussion on \"Session memory is not project memory. It fixes the same complaint.\" | Hashnode" description: "Discussion on \"Session memory is not project memory. It fixes the same complaint.\". \"My coding agent forgets everything between sessions.\" Two different things answer that, and they are not competing." url: "https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586" --- [Feed](https://hashnode.com/feed) / Discussion # [Session memory is not project memory. It fixes the same complaint.](https://blog.technopathy.club/session-memory-is-not-project-memory-it-fixes-the-same-complaint?utm_source=hashnode&utm_medium=feed) "My coding agent forgets everything between sessions." Two different things answer that, and they are not competing. Sep 23 · 6 min read · blog.technopathy.club Read the article - [#documentation](https://hashnode.com/tag/documentation) - [#claude-code](https://hashnode.com/tag/claude-code) - [#opensource](https://hashnode.com/tag/opensource) - [#developer-tools](https://hashnode.com/tag/developer-tools) - [#agents](https://hashnode.com/tag/agents) - [#ai](https://hashnode.com/tag/ai) ## Written by [Oliver Zehentleitner](https://hashnode.com/@oliver-zehentleitner) @oliver-zehentleitner · Vienna, Austria [View profile](https://hashnode.com/@oliver-zehentleitner) DevSecOps · Python · AI-driven Development · Real-world findings from production systems. I build systems that work — technically sound, security-first, and actually useful to the people who depend on them. Creator of the UNICORN Binance Suite — six open-source Python libraries with 3.3M+ downloads and 390+ dependent public projects — and Keep the Why, an open-source agent skill that preserves the reasoning behind engineering decisions alongside the code. Currently pioneering AI-driven open-source maintenance: running a controlled AI agent that maintains production code and documenting what this shift means for engineering teams. Vienna, Austria 🇦🇹 ## Responses 12 Markdown supported · ⌘↵ to post [Vlad Zoff](https://hashnode.com/@vladzoff) [Nov 2](https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586/comment/6ae833e119be44d2c35fb36b) 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. [Grunz\_ai](https://hashnode.com/@grunzai) [Sep 27](https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586/comment/6ab952bf940f275cc5e49e51) 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? [Oliver Zehentleitner](https://hashnode.com/@oliver-zehentleitner) [Sep 30](https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586/comment/6ab952bf940f275cc5e49e51#reply-6abca07f5dc5c2aa8a79f6ce) 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](https://keepthewhy.com/dashboard/live/#graph) Grunz's example is a really good illustration of the boundary. [Julian Neagu](https://hashnode.com/@julianneagulab) [Sep 26](https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586/comment/6ab7c0c6a3af45d6714e8094) 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. [Oliver Zehentleitner](https://hashnode.com/@oliver-zehentleitner) [Sep 27](https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586/comment/6ab7c0c6a3af45d6714e8094#reply-6ab8c851ca90ae391a1aa3a1) 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. [Evelyn Wyatt](https://hashnode.com/@Evelynwyatt) [Sep 24](https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586/comment/6ab4f87b358512f172e0099c) 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. [Oliver Zehentleitner](https://hashnode.com/@oliver-zehentleitner) [Sep 24](https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586/comment/6ab4f87b358512f172e0099c#reply-6ab4fd16401243a8d23820f8) 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](https://github.com/oliver-zehentleitner/keep-the-why) This is exactly the kind of edge case I want the project to get better at. [Rulestack](https://hashnode.com/@rulestack) [Sep 24](https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586/comment/6ab484e00ef27ce72c3ed742) 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? [Oliver Zehentleitner](https://hashnode.com/@oliver-zehentleitner) [Sep 24](https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586/comment/6ab484e00ef27ce72c3ed742#reply-6ab4cfdf06f787c7bd572863) 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. [Rulestack](https://hashnode.com/@rulestack) [Sep 24](https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586/comment/6ab484e00ef27ce72c3ed742#reply-6ab51f7d3c0dacc22af3e80f) 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. [Brian · AI News](https://hashnode.com/@brianainews) [Sep 23](https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586/comment/6ab40930ccfb749535c8dd99) 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. [Oliver Zehentleitner](https://hashnode.com/@oliver-zehentleitner) [Sep 24](https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586/comment/6ab40930ccfb749535c8dd99#reply-6ab4d00f70e99ebf5a3f7b53) 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.