Brokentooth.io / 06 Writing / SessionMunch, jCodeMunch, and the Agent Memory Map
SessionMunch, jCodeMunch, and the Agent Memory Map
Code search, documentation search, session history, and stateful agents solve different problems. Here is the distinction that shaped my choice.
“Doesn't another tool already do memory?” is a fair question. I would much rather find a good existing component than become the unpaid custodian of a bad replacement.
The complication is that memory can mean several different things. Remembering a user's preference, finding a function, retrieving an installation guide, and recovering the reasoning behind yesterday's failed deployment all involve context. They are still different retrieval jobs.
My problem was continuity across coding sessions and agents. The important question was which approach gave that particular work a durable home.
Three places the answer might live
Suppose an agent needs to change how authentication works.
The current function tells it what the code does. A documentation section tells it what the intended interface is. A previous session might explain why we rejected a perfectly reasonable alternative after discovering a compatibility problem.
If all three exist, they are complementary evidence. The old conversation should not override current code. The current code may not explain the old decision. A good retrieval workflow lets the agent inspect the relevant source and work out which statement is still true.
The upstream jCodeMunch project focuses on symbol-level code retrieval: asking for a function or structure instead of fetching entire files. jDocMunch uses documentation structure to retrieve relevant sections. SessionMunch's own README makes the code, docs and history analogy.
That analogy is why the names belong in the same conversation. It does not establish a shared implementation, automatic connection, or formal relationship between the projects.
Other memory approaches deserve a fair comparison
Here is the useful map, based on the upstream projects' descriptions checked on 27 October 2026. This is a comparison of emphasis and workflow, not a benchmark or an exhaustive feature matrix.
| Project | Primary emphasis | The question I would start with |
|---|---|---|
| jCodeMunch | Structured, symbol-level code retrieval. | Where is the relevant implementation? |
| jDocMunch | Documentation indexing and section retrieval. | Which part of the docs answers this? |
| Mem0 | Memory infrastructure for agents and applications, with library, self-hosted and managed options. | How do I add memory to the application I'm building? |
| claude-mem | Session observations, AI compression and progressive recall across supported agent integrations. | How do I carry useful session context forward? |
| Letta | Stateful agents and the infrastructure around persistent agent memory. | Do I want a stateful agent platform? |
| SessionMunch | Coding-session evidence, a Markdown knowledge wiki and retrieval shared across connected harnesses. | What happened in this project, and what should the next agent recover? |
There is overlap. Mem0 can be used in agent applications; it is not disqualified from coding history. claude-mem's current scope extends beyond Claude Code, despite the name. Letta is broader than a transcript index. Pretending a neighboring project lacks a feature because its first paragraph emphasizes something else would make for a convenient comparison and a fairly useless article.
I haven't run a controlled retrieval-quality or cost benchmark against these projects. There are no invented victory percentages here.
Why this direction fits my work
I want the accumulated knowledge to belong to the project while I switch agents. I want ordinary files I can inspect. I want a useful deterministic record before an optional model has interpreted it. And when an agent tells me something happened, I want a route back to the evidence.
Those preferences make the ai-memory foundation and the SessionMunch direction a good fit for the system I'm building. They do not prove it is the best choice for every application.
If you're adding personalized memory to your own product, a memory SDK may be the right starting point. If you want to build around a stateful agent, evaluate that platform directly. If your pain is code exploration, improving code retrieval might solve the problem without introducing session memory at all.
My pain keeps arriving between sessions. That is where I want to spend the effort.
The tool earns its place by answering a question I actually have. The number of times its README says “memory” is not a selection criterion.
Provider independence has conditions
Changing the model should not require abandoning the project's stored knowledge. A shared service, open interfaces and inspectable Markdown help with that.
But a particular client still needs a working connection. Capture depends on hooks or readable supported history. Recall depends on the agent being able to call the memory tools or receive a brief. A provider's consumer app is not automatically equivalent to its coding CLI.
That boundary is explained in hooks versus MCP. It is a more useful purchasing distinction than a row of green checkmarks under company logos.
Back to the project · SessionMunch source and lineage
The linked upstream repositories are the primary sources for the comparison above. Their capabilities can change; check their current documentation before choosing an integration.