Two Ways to Remember
When a developer loses context halfway through a multi-day debugging effort, the loss is not subtle. The next morning, you rebuild what you already built. You re-explain the schema decision you made on Tuesday. You re-establish which approach you already ruled out, and why. The waste is real -- not catastrophic in any single session, but compounding across weeks of daily AI-assisted work until the overhead of context reconstruction starts to feel like the job itself.
Two memory paradigms have emerged as responses to this problem. The first is deliberate curation: you organize your knowledge into a structure, naming the rooms and halls and filing decisions where future-you will think to look. The second is automatic capture: the tool takes notes while you work, and you retrieve them later. These are not variations on the same solution. They are genuinely different answers to genuinely different questions.
The Cost of the Palace Model
The appeal of deliberate organization is real. When you know that API decisions live in one place and architecture decisions live in another, retrieval is fast and browsable. The structure you build is also portable -- a well-organized knowledge base communicates intent to teammates in a way that raw session logs do not.
The cost is maintenance at exactly the wrong time. Every session that produces a decision worth keeping requires you to stop, categorize it, and file it in the right location. The overhead is small per session. Across fifty sessions it is not small, and it requires the kind of reflective, taxonomic attention that is hardest to summon when you are in the middle of a debugging run rather than stepping back from one.
Some developers will make this trade willingly. For knowledge that is genuinely stable -- architectural decisions, research notes, onboarding materials -- the organizational investment pays off. For the day-to-day narrative of what you are doing and deciding, it is a tax on work that is already demanding enough.
What Automatic Capture Looks Like
LoreConvo takes the other bet. When a session ends, it saves what happened: the decisions made, the artifacts produced, the open questions that did not get resolved before you closed the laptop. No filing required. No taxonomy to maintain. The next session, LoreConvo scores that stored context against what looks most relevant and surfaces the top results before you ask for them. If you left a schema edge case unresolved last Tuesday, it will be waiting for you Wednesday morning.
This works because LoreConvo stores sessions as narrative, not structure. The organizing principle is time and project: what were you doing, what did you decide, what remained uncertain. That is a weaker constraint than a multi-level hierarchy, and intentionally so. The goal is continuity. The hierarchy is what you were already building in your head, made persistent so you do not have to rebuild it.
Cross-surface persistence is part of what makes this useful in daily practice. A session saved from Claude Code is readable in Cowork and in Chat. The context you established during a late-night deep dive is available the next morning in whatever surface you open. There is no platform tax on memory.
For teams using LoreConvo's Pro tier, session memory also has a sharing layer. You can export selected sessions to a JSON file and teammates import them with a single command. No server required. The same local-first architecture that keeps individual sessions private can also propagate shared context across a team without a cloud intermediary -- you coordinate through files, not subscriptions.
The system is agent-agnostic. LoreConvo ships as a standard MCP server, which means it works wherever MCP works. The same project-local .mcp.json that Claude Code reads, Codex reads. One configuration file, every AI client.
When Sessions Are Not Enough
Session memory handles the narrative layer well. What it does not handle is reference material -- the kind of knowledge that needs to outlast individual sessions, stay findable by keyword, and be updated as the project evolves.
Architecture decision records, product specifications, operational runbooks, onboarding guides: these are documents that future sessions need to find and cite. Storing them as session logs means they drift toward the bottom of the recency ranking and become harder to surface over time. They are not narrative; they are reference.
LoreDocs fills this gap. Where LoreConvo stores session narrative, LoreDocs stores structured knowledge in named vaults. A project might have one vault for architecture decisions and another for customer-facing specifications. When Claude needs the architecture context for a refactor, it queries the vault directly, getting the right document rather than a session from six weeks ago that happened to mention the relevant constraint.
The result is a two-layer memory system: LoreConvo for what happened and what was decided, LoreDocs for what needs to stay findable indefinitely. MemPalace is a single memory layer. When your project needs both session continuity and durable reference knowledge, a palace does not cover the second half of the problem.
The Retrieval Question
MemPalace has published benchmark numbers. They are credible numbers from a well-designed evaluation. The honest response is not to dismiss them but to be precise about what they measure.
High recall at rank 5 means that if you ask about authentication, you get five results that are probably relevant. The trade-off is precision: some of those results touch authentication at the margins, and you still have to evaluate each one. For a large, browsable knowledge base, that is the right trade-off. You are exploring a space.
LoreConvo's retrieval is optimized differently. FTS5 full-text search returns sessions that contain the terms you searched for. When you search for "database migration," you get sessions about database migration -- not every session that mentioned schema changes in passing. The cost is semantic coverage: FTS5 does not automatically resolve "auth" to "authentication" without additional configuration. The benefit is that the results you get are exactly what you asked for.
For the primary developer use case -- finding a specific session you know you had, about a decision you know you made -- precision over approximate recall is what you want. You are not browsing. You are retrieving.
Which Problem Are You Solving?
Both paradigms solve real problems, and the choice is not about which tool has more stars. It is about what your workflow actually needs.
Deliberate curation is the right tool when the knowledge is worth the organizational overhead and when browsability and shareability matter more than effortless continuity. Auto-capture is the right tool when the primary need is session continuity -- when what you are looking for is something you already know you are looking for, and when the friction of manual filing would erode the habit.
For most developer workflows running daily Claude Code sessions, multi-step debugging efforts, or agentic pipelines that need state across runs, the overhead of maintaining a palace adds friction at every step. LoreConvo removes that friction by making capture automatic. LoreDocs handles the rest.
Both are available now on the Anthropic marketplace and from PyPI. The free tier is enough to see whether persistent context changes how you work.
Visit /tools to see both products, read the installation docs, and find the source code.