---
title: "Comment by Grunz_ai on \"Session memory is not project memory. It fixes the same complaint.\" | Hashnode"
description: "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. buil"
url: "https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586/comment/6ab952bf940f275cc5e49e51"
---

[Discussion](https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586)

Comment [Session memory is not project memory. It fixes the same complaint.](https://hashnode.com/posts/session-memory-is-not-project-memory-it-fixes-the-same-complaint/6ab3ae06ab5703ad22d98586)

[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.