Indexed Session Logs Recall What You Said, Not What Is Still True (2026)

The diagnosis is right, and the project says so first

funes opens by crediting an earlier argument and then qualifying it, which is a better start than most tools manage:

"While the diagnosis is correct, traces are only potential memory. The session logs of an agent are still just an archive. You cannot grep your way to 'why did we move off the streaming parser?' across ten thousand turns. For an agent to use those traces while it works, they need indexing, retrieval, ranking, and exact provenance."

Every clause of that is true. An archive is not memory. Grep does not scale to ten thousand turns. And the four things it names — indexing, retrieval, ranking, provenance — are exactly what turns a pile of logs into something usable.

The mechanism, as documented

The write path is deterministic: "one deterministic pipeline parses every supported trace into the same turn-and-block shape, chunks it, embeds it with a pinned local model, and writes it to a local Lance dataset."

The read path is a hybrid: "A query combines vector and BM25 search, fuses their rankings, reranks the candidates with a cross-encoder, reweights them by recency, and attaches neighboring chunks."

Setup is one command per agent, which "builds the first index, gives the agent recall and get tools, and installs the automation that indexes each completed turn." Indexing is incremental — "new runs adding new turns rather than embedding the whole history again" — with older content able to "backfill in bounded steps."

What comes back is unprocessed: "recall returns the original text, not a summary, and shows exactly where it came from (the agent, timestamp, session, and turn)."

Three properties worth granting

The project lists three, and all three are real.

Cross-agent coverage. "Claude Code, Codex, pi, and Hermes all write to the same shape. recall spans their histories, and every hit says which agent produced it." One normalized shape across four agents is genuinely useful, and it is the same instinct behind cross-agent memory as a category.

Local by default. "No account or Hub repository is required. A hosted model does not process your sessions for indexing; embedding and reranking run on your machine, and your coding agent does the reasoning." For anyone who cannot send transcripts to a third party, that is not a preference, it is a requirement.

Ownership. Bind a memory to a dataset and "Run the same command on another machine and the memory follows you there," with the Hub supplying "the ownership, access control, versioning, and distribution it already supplies for other datasets."

There is also a credential-handling step, described specifically: "Before anything reaches the Hub, credentials have already been redacted during indexing. Publishing then scans every chunk again and withholds anything that still looks like a secret." The project points to its own SECURITY.md for "what it does and doesn't cover," which is the right way to document a scanner.

It does solve one problem completely. "What did we say about the streaming parser?" is now answerable in seconds instead of not at all. If your question is about the record — what was discussed, when, by which agent, in what words — an indexed archive is the correct tool and there is no substitute for it.

It does not answer a question that looks nearly the same. "What is our convention for parsers?" is a different query. The archive contains every statement anyone ever made about parsers, including the enthusiastic three-hour exploration of the approach you abandoned. Relevance ranking does not know which of those is still in force, because nothing at write time recorded that one superseded the other.

Recency reweighting helps and does not resolve it. The pipeline "reweights them by recency," which is the right heuristic and a partial one. A decision reversed in four terse messages carries less textual weight than the long, detailed, wrong discussion that preceded it. Recency nudges; volume still argues.

It does not distinguish a decision from a musing. A transcript records "maybe we should switch to X" with the same fidelity as "we are switching to X." Both are turns. Both are indexed. Neither is labeled.

It does change where the curation work happens, not whether it happens. With no write-time distillation, the resolution — this is current, that was replaced — has to occur at read time, in the agent's reasoning, on every query. That can work. It is also work being repeated indefinitely rather than done once.

It is honest about its own scope. "The agent as a stranger problem is already solved on one machine. But memory gets more useful when the next agent is running somewhere else." That is an accurate description of what the local tier does and does not cover.

"My logs were already my memory, I just needed to index them." Half right, and the project itself is more careful than this: "traces are only potential memory." Indexing makes the archive queryable. It does not make it authoritative.

"Provenance means I can trust the answer." Provenance means you can verify where a claim came from, which is valuable and different. A perfectly sourced quote of a decision you later reversed is perfectly sourced and wrong for today.

"No distillation means no information loss." No loss of evidence, and no capture of judgment. The knowledge that one statement replaced another is information too, and write-time distillation is where that normally gets recorded.

"A dataset instead of a service settles it." The project makes this positioning explicit — "Your memory does not become an account in a separate memory service, and you do not rent it back" — and it is a legitimate design stance. It is also answering a question about ownership, not about currency. You can own an archive completely and still not know which of its contradictions holds.

"So curated memory is just lossy compression of the archive." The comparison cuts both ways, which is the fair way to read it. An archive keeps everything and resolves nothing. A curated store resolves and can be wrong in its resolution. The mature answer is that these are complementary layers, not competing ones — which is roughly what the RAG-versus-store conversation eventually concluded, as AI memory versus RAG sets out.

"Local-only means nothing to think about." Local avoids sending transcripts to a third party. It does not avoid the fact that transcripts contain whatever was on screen. Credential redaction plus a publish-time scan is a real mitigation with documented limits, and reading those limits is part of adopting any tool in this shape — the concern behind AI memory security.

Step 1: Sort your questions before you sort your tooling

Spend ten minutes writing down the questions you actually ask an agent about your own project, then label each one.

Evidence questions are about the record. "When did we decide this?" "Who raised the objection?" "What was the error we hit last time?" "Show me the turn where we tried this." These want the original text with provenance, and an indexed archive is the right answer.

State questions are about now. "What is our convention here?" "Which service owns this?" "Is that workaround still needed?" These want one current answer, and an archive will hand you a ranked list of everything ever said instead.

Most teams' questions split roughly evenly, and almost nobody notices that they are two categories.

Step 2: Read what recall returns for one state question

This is the cheapest way to see the distinction rather than take my word for it.

Pick a decision your team genuinely reversed. Ask the archive about the topic — not about the decision, about the topic, the way you would in real work. Read the top results.

You will usually get both positions, ranked by textual relevance with a recency nudge. That is the tool working exactly as designed. It is also the moment where an agent, given both, has to decide which one you meant, on every future query, from evidence that does not say.

Note what would fix it: a single line somewhere stating which convention holds and when it changed. That line is not in the archive because nothing at write time was asked to produce it.

Step 3: Write the resolutions down once, and keep the archive for everything else

The layer that answers state questions is small. It is not a copy of your transcripts, and it should not be.

It holds the resolutions: the convention that is current, the decision that superseded the earlier one, the reason a deprecated thing still exists, what your internal terms mean, which team owns which surface. Ten to fifty lines for most projects, and it stops being ambiguous because someone decided rather than because retrieval guessed.

Keep the archive for evidence. When a resolution needs justifying, the transcript with its provenance is exactly the right thing to point at — and the resolution is what your agent reads on Monday morning. MemoryLake sets up in three steps.

Step 1: Create an API key

Sign in and generate an API key from your dashboard. The store is small and readable by design, which is what makes the next step short.

Step 2: Upload your first memories

Write the resolutions, not the history: current conventions, superseded decisions marked as superseded, domain vocabulary, ownership, constraints with their reasons.

Leave the transcripts alone. Indexing them is a separate and worthwhile job, and this layer is not trying to replace it.

Step 3: Connect your AI & agents

Point your agents at the store. State questions get one current answer, evidence questions go to the archive, and neither is asked to do the other's job — which is the version of this argument in why long context isn't memory, one abstraction up.

The first change is that "the agent suggested the thing we stopped doing" becomes explainable. It is not a retrieval failure. The archive contained both answers and nothing marked one as replaced.

The second is that indexing your logs becomes clearly worth doing, because you stop expecting the wrong thing from it. An archive that answers evidence questions well is a real asset.

The third is that the resolution layer stays small enough to review. Fifty lines of current conventions can be read and corrected by a person; ten thousand turns cannot, which is the reason keeping less in agent memory usually beats keeping more.

• Label your questions. Evidence questions want the record; state questions want one answer.
• Expect contradictions in results, not resolutions. With nothing distilled at write time, both sides of a reversal are equally indexed.
• Do not rely on recency alone. It reweights; it does not adjudicate, and terse decisions lose to verbose explorations.
• Use provenance for what it is good at. Verifying a claim's origin, not establishing that it still holds.
• Read the security documentation. Credential redaction and a publish-time scan are real, with documented coverage limits.
• Write resolutions down separately. A superseded decision should say so somewhere outside the transcript that created it.
• Keep the resolution layer short. If it is long enough that nobody reviews it, it will drift the same way an archive does.
• Treat the two layers as complementary. Evidence and current state are different jobs, and one tool doing both does neither well.

Indexing your session logs is a good idea, and the argument for it is stated more carefully by the people building it than by most of the coverage around it. An archive is not memory; indexing, retrieval, ranking, and provenance make it useful.

What they cannot make it is current. "Nothing is distilled into a fact at write time" is an honest description of a real tradeoff: you get every word you ever said, and no record of which words still count. Keep the archive for evidence, write your resolutions somewhere small enough to read, and stop asking either one to do the other's job.