Funes turned coding-agent traces into a searchable memory layer

The Funes announcement described durable memory built from coding-agent sessions already stored on a user’s machine. It distinguished a pile of logs from a usable system for indexing, retrieval, ranking, and source provenance, with the aim of carrying project context across sessions and tools.

The useful memory is often the reasoning behind a decision, not just the final code change. A retrieval layer can help surface that context, but stale or irrelevant memories can also mislead an agent. Exact provenance matters because it lets the original decision be inspected.

Read the source and linked repository to understand supported agents and storage behavior. Start with one project’s traces, inspect retrieved results, and check data-handling settings before introducing sensitive material or sharing memory between environments.

Memory needs a reason to be retrieved

Keeping a transcript and remembering a decision are different operations. A transcript contains successful solutions, abandoned experiments, incorrect assumptions and temporary instructions. Retrieving any of those passages without its context can make an agent confidently repeat a mistake. The useful unit of memory is therefore not just a sentence; it is a statement with a time, a project and a traceable source.

Consider a team that replaced a parser after discovering a streaming bug. A later agent needs the reason for the replacement, not simply an old command that installs the previous parser. A useful retrieved record should reveal the relevant discussion and make it possible to distinguish a final decision from an early suggestion.

Start with a bounded project

For a first memory experiment, choose one repository and a few past sessions that contain decisions you genuinely expect to revisit. Create questions before inspecting the search results. Examples include why an interface changed, which approach failed, and what constraints led to a particular dependency.

Judge the returned evidence against those questions. A result that contains the right keyword is not necessarily the right explanation. Check whether the passage belongs to the correct project and whether a later session superseded it. This is a retrieval-quality exercise before it is an automation exercise.

Local does not mean indiscriminate

A local archive may still contain credentials, customer information or unrelated conversations. Decide which sessions belong in the collection and what should be excluded before indexing. If the collection is later synchronized, review the destination and its access settings rather than assuming that the original local boundary still applies.

Retention matters as well. It can be reasonable to preserve a decision summary longer than the raw troubleshooting conversation. Being able to remove an indexed item and rebuild the corresponding search state is part of owning the memory, not an optional housekeeping feature.

Teach the workflow to distrust stale instructions

Retrieved text should be treated as evidence about earlier work, not a fresh command. An instruction embedded in a historical log must not automatically override the current task. Similarly, a successful command from months ago may depend on a package version or filesystem layout that no longer exists.

A strong memory-assisted answer identifies the earlier decision, cites where it came from, and checks it against the current repository. That extra verification is the difference between useful continuity and automatic repetition.

The most convincing test is not whether the system can recite a session. It is whether someone can resume a project with fewer repeated investigations while still recognizing when the old answer no longer fits.