Your Agent's Memory Is a Dataset Not a Service

funes dropped this week on Hugging Face, and almost nobody covered it. It is a memory layer for coding agents, built for Claude Code, Codex, pi, and Hermes, and it is built out of the session traces already sitting on your machine. One command and your agent stops forgetting everything at the turn boundary.

The number that matters: recall was 8x cheaper than a written handoff on one task and 4x on another, measured on a handoff-versus-recall benchmark. You are currently paying engineers to write handoffs. That is the most expensive memory system in your building.

Here is the real story. Memory stopped being a context-window problem the day your agent started running across days and machines. Note 171 covered the compaction cliff, your agent losing 53% of its safety rules in one compaction. Note 170 covered memory as an attack surface. This note closes the triangle: memory is now an infrastructure problem, and the question is who owns the dataset.

MEMORY IS NOT A FEATURE. IT IS A DATASET.

Let me define the shift for anyone new to this. Agent memory is not a chat history. It is not a bigger context window. It is a durable, queryable, versioned dataset that your agent reads and writes like any other data system. The funes pipeline makes this concrete. One deterministic parser turns every supported agent 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.

Deterministic means the same input always produces the same memory. That is a data engineering property, not an LLM property. If you run the pipeline twice on the same trace, you get the same chunks and the same embeddings. That is exactly what you want from a storage layer, and it is exactly what most memory products do not give you.

For the professionals in the room: this is the same design discipline you already apply to event logs, provenance, and schema versioning. Your agent's memory deserves the same rigor, because it is the same class of artifact. You version your schemas so a downstream consumer can trust the shape of the data. Your agent's memory needs that same trust, because the downstream consumer is an autonomous process making decisions on top of it.

The moment you stop thinking about agent memory as a service you rent and start thinking about it as a dataset you own, every engineering decision changes. Where does it live. Who can read it. Can you export it. What happens when the vendor changes the format. Those are the questions of an owner, not a tenant.

THE RETRIEVAL STACK IS WHERE MEMORY LIVES OR DIES

A dataset only matters if you can get the right thing out of it. This is where most memory systems fail in practice, and it is where you should focus your attention when you evaluate one.

Walk the funes query path as an architecture lesson. 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. That is a five-stage pipeline. Each step exists because single-method retrieval fails in a known way.

1. Vector search misses exact identifiers. Your function names, variable names, and class names are the highest-signal tokens in a codebase, and dense embeddings are terrible at exact matches.
2. BM25 catches exact terms but misses meaning. If two sessions describe the same decision in different words, lexical search will not connect them.
3. Fusion runs both and combines their rankings, so a result does not have to win on one method alone.
4. The cross-encoder rerank kills the noise, scoring each candidate against the actual query instead of relying on a broad similarity score.
5. Recency reweighting stops yesterday's bug from overriding today's fix, because the most recent decision is usually the one that governs.
6. Neighboring chunks attach context, so a retrieved block arrives with the turns around it instead of as an isolated sentence.

This is the citable core of the piece. You can name it and repeat it back. Hybrid retrieval beats any single method for code memory, and it beats it for a specific set of reasons. If a memory layer uses one retrieval method, it is missing at least one of these failure modes. If it uses vector search alone, it will miss your exact function names. If it uses lexical search alone, it will miss meaning. The systems that hold up combine both, then rerank and reweight.

THE MEMORY OWNERSHIP TEST

Here is a framework you can run on any agent memory layer today. Call it the Memory Ownership Test. Five questions.

1. Where does the data physically live, and can it leave your machine? If it lives only inside the vendor's cloud, your answer to the rest of the test does not matter.
2. Can you export it in an open format? A proprietary format that only the vendor's tools can read is not your data. It is a hostage.
3. Is the embedding model pinned, so memories do not rot when the model updates? If the vendor swaps the embedding model out from under you, every stored memory changes meaning overnight. Pinning the model version means a memory stored last year retrieves the same way this year. An unpinned update silently moves every stored vector in space, and because each embedding shifts, the cosine distances you query against those historical vectors are recomputed on the fly, so older memories stop ranking the way they did and neighbors drift from the turns they used to sit beside.
4. Does retrieval fuse multiple methods or rely on one? You already know the answer to this one matters.
5. Who else can read it? The vendor, the model provider, nobody?

Score a hosted vendor memory against funes on each question. funes gives you a local Lance dataset, private by default, exportable to a Hugging Face dataset you own, a pinned local embedding model, and hybrid retrieval. The vendor layer fails at least three of the five on most days. It cannot name the file on disk where your memory lives, because there is no file on your disk. It cannot export in an open format, because the format is closed. And somebody else can read it, because that is the business model.

The rubric, not the product, is the takeaway. Products churn. Rubrics compound. A named framework you can apply to the next product and the one after that is worth more than a review of any single release.

WHY THIS IS 2026'S BREAKOUT INFRASTRUCTURE CATEGORY

Look at how the frontier question moved this year. It stopped being about which model wins and became about how the agent remembers, persists, and is trained. The model is becoming commoditized at the application layer. The memory layer is not. It is the thing every agent runs on, the thing that spans machines and teams, and the thing nobody has solved cleanly yet. That is the definition of a breakout infrastructure category.

As agents span machines and teams, the memory layer becomes shared infrastructure with real security weight. This connects directly to Note 170's Memory Trust Boundary. The same persistence that makes memory useful makes poisoning it the highest-value attack in your stack. An agent that remembers everything you tell it forever also remembers everything anyone tells it forever. Ownership and defense are the same design decision. If you do not control who can read and write your agent's memory, you have handed an attacker the highest-value target in your system.

This is not theoretical. The supply-chain attacks this year showed what happens when agents trust unverified data as ground truth. The memory layer is the same trust boundary, running permanently. A poisoned memory does not fail once. It fails on every future turn, because the agent keeps reading the poisoned state. Defending the memory layer is not a security afterthought. It is the security decision.

WHAT TO DO TODAY

Here is your checklist. Run it this week.

1. Inventory where your agent's memory currently lives. If the answer is inside the vendor's context window, that is not memory. That is a lease.
2. Run the Memory Ownership Test on whatever you use today. Write down which of the five questions it fails. That list is your migration trigger.
3. Export one week of your agent session traces and look at them as data. Chunks, identifiers, timestamps. If you cannot read them as a dataset, you do not own them.
4. Try a local-first memory layer on a non-critical project. One command is the bar. If it takes longer than that to install, that is a signal too.
5. Pin your embedding model version. Note it in the same place you note your lockfile hashes. A memory with an unpinned embedding model is a time bomb.

THE UNCOMFORTABLE QUESTION

Every conversation your agent has ever had is training somebody's product. If you cannot name the file on disk where your agent's memory lives, whose dataset is it?