Keep the Why vs. past.dev vs. Agent Memory Repo vs. agentmemory

This is the third dated comparison. The first looked at Claude Code auto memory, MemoryCustodian and AgentsRoom. The second compared OKF Agent Memory and RepoWise, the two that work closest to the repository.

Since then, more names have joined the "memory for agents" lists. One I'll leave outside this table: WikiKB from GitHub Next is a knowledge base built from ingested sources and published to a repository wiki. Interesting work, but a different comparison.

Three stay. past.dev is a memory API that launched at the end of September. Agent Memory Repo is the Git-backed memory format Cognition released as an open standard in October. agentmemory, no space, is a local memory server that can capture coding-agent activity through hooks. They overlap in places, but they make different choices about what to preserve.

I built Keep the Why, so this isn't a neutral review. I've tried to be fair about the boundaries, including where the other tools are better. The questions are mostly the same ones I've used before, with one added.

Where does it live? On a vendor's server, on your own machine, in a Git repository of its own, or in the code repository itself. This decides who gets it with a clone, and whether the pull request changing the code can include the memory that explains it.

What does it hold? Facts that change over time. What an agent did in a session. Preferences and findings that should survive into the next one. Or the reasoning behind the code: the decision, the alternative that lost, the constraint the diff cannot show. These are layers, not rivals.

What happens to the old value? When a fact, memory or entry changes, can the next reader still find what came before? And can they find out why it changed?

The table

Checked on 2026-10-12 against past.dev, its launch post and docs; the Agent Memory Repo page, README and SPEC.md; the agentmemory site, docs and repository; and the Keep the Why specification. This is a snapshot, not a claim about what any project will support next month.

One example

A coding agent suggests replacing a retry wrapper with a plain loop. The team rejects it because the service returns a per-request Retry-After, and ignoring that header caused repeated 429s under load. Three months later, a fresh agent suggests the same simplification.

All four systems could help, but through different paths. past.dev might retrieve the decision if someone ingested the review discussion. Agent Memory Repo might have a note if an agent saved it. agentmemory might find the old session if the relevant activity was captured and retained. Keep the Why is built to put the rejection and its reason in context/, next to the code, so a new agent can find it before making the same suggestion.

That is the case I tested with fresh agent sessions. It doesn't prove the other systems would fail. I didn't test them against each other. It shows what keeping the rejected alternative in the repository can change.

Where the others are better

past.dev puts time into the data model itself. A claim has a value, a date and the source behind it. A recall can ask what was known on a given day, not just what is current now. Git gives Keep the Why a different kind of history: you can inspect an earlier revision of context/, and a superseded decision can point to its successor. But that's not the same as querying a timeline of individual facts across a year of emails. past.dev can do that across sources that never entered a repository. If that's what your agent needs, Keep the Why isn't trying to replace it. The trade is that you now depend on a service, in past.dev's cloud or in yours, outside the code review. The source may explain why a fact changed, but recording a decision rationale isn't the service's specific job.

Agent Memory Repo is the closest neighbour in form: Markdown, Git, wiki-links, no server, and a skill in the same Agent Skills format Keep the Why uses. Its README describes personal memory, team memory and agent swarms. It also makes an important distinction: memory is data, not instructions. I agree. Its design keeps the memory in a separate repository. That works well when the same person or swarm moves between projects. For code decisions, I prefer the opposite boundary. A memory edit in another repository won't automatically show up in the pull request that changes the code. Its format uses one-line entries, which is fine for "prefers concise summaries" but less useful for "we tried parallel replay, it corrupted state, and this is why we serialize". When an entry becomes stale, the spec says to update or remove it. Git keeps the earlier version, but the next reader doesn't normally see it. That's a reasonable trade for preferences and changing facts. It's not the one I want for a rejected technical decision.

The Agent Memory Repo README also describes a periodic Dreaming agent that merges duplicates, removes stale entries and finds patterns. Its local trial does not set up automatic startup or scheduled Dreaming, so I wouldn't count that as maintenance you get just by installing the skill.

agentmemory is one of the more ambitious session-memory systems I've looked at. Hooks capture supported events and tool activity without asking the model to decide what deserves a permanent note. It can search observations, derive summaries and lessons, link related memories and track versions. It also has a commit-context skill that runs git blame, looks the commit up, and shows the agent session that produced it. I like the rule behind that skill: don't invent intent that the observations don't support.

But a trace of what an agent did isn't always the reason the team made a decision. If the reason was stated in that captured session, great. If it was settled later in a review, on a call, or by someone using another machine, a local session trace may not contain it. And even with hooks, capture isn't literally everything: coverage depends on the agent integration, filters and delivery. The project documents buffering and retry behaviour, but also limits and failure cases. That's not a criticism of agentmemory in particular. It's a limit of observing activity instead of asking for an explicit decision record.

agentmemory also has lifecycle rules. Version chains preserve superseded memories, and the built-in sweeps for lesson decay and expired memories are enabled by default. That is separate from LLM-backed consolidation, which runs when an LLM provider is configured and can be disabled. These are useful policies for information that may become stale. A rejected alternative in context/ works differently. It stays relevant until someone revisits or supersedes it. Neither policy makes sense for every kind of information.

Where Keep the Why is weaker

There are tradeoffs on my side too.

• It has to notice the decision. Keep the Why doesn't record a complete session and sift through it later. The agent has to recognize a decision or a rejected alternative while it's happening, or reconstruct it later from a trustworthy source. If nobody records it, it can be lost. Hooks give agentmemory a much wider record of observable activity, even if that record has limits too.
• The model matters. The linter can verify structure, not whether a reason was understood or explained well. Different models and agent harnesses still behave differently, which is why I publish the agent and model matrix. I expect this weakness to shrink as models improve. They are getting better at recognizing meaningful decisions and following instructions. But "better models will fix it" isn't a result I can put in a benchmark table today.
• The index isn't a search engine. The agent reads a short index and follows the relevant topic. It works for the scale I've tested. At hundreds of topics, I don't yet have evidence that the same routing stays as reliable. Stronger models may help here as well. For now I don't want to add a search backend just to solve a scaling problem I haven't seen in a real project.

What Keep the Why doesn't do, on purpose

• No transcript capture. No hooks, full session logs or automatic summaries of everything an agent did. An entry is the reason behind a choice, written when it matters or recovered later from evidence.
• No general fact store. The current value of a setting belongs in the code or configuration. context/ holds why it has that value, what was considered instead and what could justify changing it.
• No separate memory repository. The rationale belongs with the code because the person reviewing the diff should be able to review the reason too. The next person cloning the project should get both.
• No background service. No daemon, Dreaming process or decay sweep. Maintenance happens when the project is being worked on, under the same rules as a new entry.

The FAQ and Philosophy pages explain why.

Beyond one repository: a web of context

There's an obvious question about keeping the why next to the code: what happens when the decision affects more than one repository? A shared library, the service using it and the application above it may all depend on the same constraint. I don't want three copies of the explanation that slowly drift apart.

Keep the Why links the entries instead. A See reference can point to a decision in another repository by its canonical URL and entry ID. Each repository still owns its own context/. A family makes the relationship explicit for projects that belong together, like the eight repositories in the UNICORN Binance Suite. Friends are other repositories an entry cites, even if they aren't part of that family. Follow the citations and you get thoughts: chains of decisions connected across repository boundaries.

The live dashboard makes this visible as a graph. Its globe can also discover projects that opt into the registry, including links between them. The registry is for discovery, not the source of the memory. The decisions remain Markdown in their respective Git repositories; the dashboard reads them, it doesn't own them. And a link doesn't bypass access rights: the other repository or its published export still has to be reachable.

That's the web of context I wanted. Not one global memory database, and not a pile of duplicated notes. The reason stays where it belongs, but the trail doesn't have to stop at the repository boundary.

The part that is true of all four

Each tool is answering a different version of "what should the next session already know?"

past.dev: what was true, when, and according to which source. Agent Memory Repo: what earlier sessions and teammates learned. agentmemory: what happened during supported agent sessions, and what can be recovered from them. Keep the Why: why the code is the way it is, including changes that were considered and rejected.

A project could use all four. I wouldn't, unless it actually needed all four, but there's no architectural conflict in doing so.

The traditional memory categories, working, episodic, semantic and procedural, can all contain explanations. I'm not claiming a reason is impossible to store in any of them. The difference is what you choose to make durable, and where you put it.

A codebase already has its implementation, tests, documentation and Git history. Sometimes the reason for a decision is somewhere in an issue, a review comment or an old session transcript. Sometimes it only existed in a conversation and is gone. I built Keep the Why because I want that reason to have a predictable place: a small, reviewable piece of Markdown beside the code it explains. Not a replacement for everything else an agent might need to remember. Just the part I kept seeing us lose.

I hope you found this informative and useful.

Follow me on GitHub, Bluesky, Mastodon, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯