Lore Blog

The Agentic Memory Trap

Burak Yigit Kaya — Thu, 30 Jul 2026 00:00:00 GMT

In April, Harrison Chase wrote an essay called Your harness, your memory. He named what the AI tooling industry has been circling for a year. Memory is the new lock-in. The harness owns it by default, and the harness is what every platform is racing to be.

He was right about the diagnosis. He was not entirely accurate with the prescription. He builds LangChain, so he is primed to think in terms of harness-first. Broaden your thinking and there is a better, more independent way, and Lore is the proof.

“There is sometimes sentiment that memory is a standalone service, separate from any particular harness. At this point in time, that is not true.” — Harrison Chase, Your harness, your memory

The analogy is wrong on the merits too. Memory is part of your brain. Agent harnesses are like your body, the limbs and everything. You don’t move your memory to your limbs. You move your memory to your brain.

Our argument is equally self-serving as LangChain’s. The difference is: you can move away from Lore and keep your organized SQLite database to yourself. That is true open memory.

The time has come. Lore is the standalone memory service, and it is the architecture that gets you out of the trap.

The platform owns your data. You should.

When a closed platform builds “agent memory,” it stores your team’s decisions in a proprietary database behind an API. Retrieval shapes the agent, and the shape of the agent is the shape of the moat. Switch IDEs, switch models, switch anything, and the team rebuilds months of context from scratch. The lock-in is the product.

Harrison names three levels. The mild one stores state on the provider’s server so you cannot move threads between models. The bad one runs a closed harness that interacts with memory in ways you cannot see, and the artifacts are not portable. The worst one puts everything behind an API, including long-term memory, and you own none of it. Anthropic’s Claude Managed Agents lives in that worst camp. Codex’s open-source harness produces an encrypted compaction summary nothing outside OpenAI can read, so it creeps toward the worst too. The incentive is everywhere, and it points the same way.

Six months of careful work, six months of capturing a team’s taste, and a vendor change returns the team to zero.

Lore is local-first and we want to keep it that way

Lore is a vendor-neutral proxy that sits between your harness and your model. The whole engine runs on your machine. The memory lives in your repo and your local machine as plain Markdown and an open SQLite database. You can read, query, and edit it with or without Lore.

flowchart LR
    H["<b>Harness</b><br/>Claude Code · OpenCode · Pi · Codex"]
    L["<b>Lore</b><br/>local-first, vendor-neutral<br/>.lore.md + lore.db<br/>local, sqlite & markdown"]
    A["<b>Model Provider API</b><br/>Anthropic · OpenAI · Google · others"]

    H --> L
    L --> A

    classDef lore fill:#c4ddc7,stroke:#1a3320,stroke-width:2px,color:#1a3320
    classDef ext fill:#ececec,stroke:#888,color:#333
    class L lore
    class H,A ext

The LLM is the cognition, Lore is the memory layer. They form the brain. The harness is the body, the actuator.

.lore.md at the root of your repo. The curated knowledge the team has reviewed and merged. Version-controlled, PR-reviewable, human-readable Markdown.
A local SQLite database at ~/.local/share/lore/lore.db. The full record: raw conversations, distillations, long-term memory, entities. Open schema, queryable with sqlite3, exportable.

The engine that ties them together is fair source (FSL-1.1-Apache-2.0). The code that touches your tokens is right there to read, and it turns into Apache 2.0 on a timer.

The SQLite file is the vector database. The vectors ride alongside the temporal messages, the distillations, and the long-term memory entries, in one open file. No separate vector store, no separate process, no separate bill. When a team changes a memory entry, the engine picks up the change on the next session and re-embeds the affected entries. Fast and transparent, on your hardware.

A few months after that initial post, Harrison himself claimed that memory systems sit beside the harness. In Wiki Memory, he wrote:

“This pattern also sits adjacent to memory systems like LangMem, Letta, Mem0, and Zep. Those systems attack the broader agent-memory problem, while wiki memory is notable because it often uses the simplest possible substrate: files.”

All these systems, including Mem0, don’t really solve the immediate context problem. Lore unifies this and, unsurprisingly, by fusing two approaches together: locality & files along with long-term memory.

The vendor route vs the local-first route

Harrison is right. You shouldn’t put your memory into a vendor’s hands. The lock-in is real, and the way to escape it is to keep the data on your machine, local, sqlite & markdown, where you can read with sqlite3 and edit with any text editor. To change a memory entry, you edit the file. To delete an entry, you delete the row. To export the corpus, you copy the file. To move to a different vendor, you point the new tool at the same files.

The same logic applies to the harness. You wouldn’t lock yourself into a single LLM provider, and you shouldn’t lock yourself into a single harness either. Claude Code today, Pi tomorrow, Codex next quarter, something new next year. The memory should outlast the harness. The harness is the part you swap; the artifact is the part that stays.

When your team is ready to share, the sync engine works the way a good group chat does: end-to-end encrypted, scoped to the entries you explicitly approve, and the relay never sees plaintext. The keys stay with the participants. Sharing is opt-in, per entry, and reversible.

Why this matters

We have talked before about why knowledge lives in token space, not in weights. The same logic applies to where the token-space lives. A database in someone else’s cloud is halfway there. A database or engine tied to your harness might be better. A replaceable middle layer for memory, all data local and owned by you, is the rest of the way.

Models will keep changing. They always do. Every part of the AI tooling stack above the model is genuinely up for grabs right now. The part that should not be up for grabs is who owns your team’s data. That belongs to the team, on infrastructure the team controls.

Lore is local-first. We aim to keep it that way.

Try it

curl -fsSL https://withlore.ai/install | bash
lore run

After a few sessions, open .lore.md and the database at ~/.local/share/lore/lore.db. Read what your agent has written down. Open a PR when it gets something wrong. That is the workflow.

The Semantic Linter: Automating reviews without losing touch

Burak Yigit Kaya — Sun, 26 Jul 2026 00:00:00 GMT

About ten years ago, when machine learning got good enough that you could train a real classifier without a research lab, I had a specific project in mind. I wanted to train something that reviewed code the way I did, so I could step back from reviewing every change without the codebase drifting. I never built it. I never had enough of the right data, and I never had the time.

The debate about review has finally caught up with the project I never built, and I think both sides are half right.

The same complaint from two sides

One camp says the whole point of writing code with agents is that a human still reads every line before it ships. Slow down, look closely, stay in control. The other camp, often the same people on a different day, says the job has turned into something worse: you don’t write much anymore, you sit and read change after change the machine produced, and it is dull and a little soul-crushing. Reviewing slop, they call it.

Those are two views of one loss. Review used to be where judgment happened and where the team learned how the codebase was meant to work. Now it has shrunk to a checkpoint you sign off on. The “read every line” camp wants to protect what review was. The “this is soul-crushing” camp is telling you it has already gone. Both are reacting to one loss.

A colleague told me the human side of this a few months ago. When he joined the team, he said, he learned a lot from getting detailed reviews from me, the kind where you explain not just what to change but why the team works this way. What he picked up wasn’t a list of rules. It was a way of working. Now we mostly work on our own, agents write and review most of the code, and he misses it. He wasn’t complaining about speed. He was noticing that something had stopped passing between us.

Armin Ronacher wrote about this from the other end. The shared understanding a team keeps of its own system used to be a byproduct of the friction in working together, and agents have quietly removed the friction. My colleague felt that up close.

What review was really passing along

A review was never only a gate. It was how one person’s standard reached everyone else. You don’t mock the database in integration tests, and here’s the migration bug that taught us why. Deploys go from the release branch, because of the time they didn’t. The standard arrived with its reason, at the moment it mattered, to whoever was on the change.

When that stops, the standards don’t disappear. They stop showing up when they’re needed, and six months later a pull request quietly brings back the exact thing the team decided against. Nobody used bad judgment. The change looks reasonable on its own. What was missing was a reviewer who knew the standard and noticed, right then, that the change cut against it.

You are what you do, not what you write down

That is the hard part, and it’s why the project I never got to needed data I never had. A review teaches the person reading it, but it’s a poor thing to learn from at scale. It’s the verdict, not the reasoning: “don’t do this here” lands, and the thinking that led me there stays in my head. Most of what makes a good reviewer good is taste, built from years of doing the work, and you can’t write it down. Ask someone to put their standards in a document and you get a thin, lifeless version of what they actually do. But you keep doing it, review after review, and the standard is real even when the document isn’t.

That’s the shift that makes this possible now. Lore watches the work the way an apprentice does. It sits alongside your sessions, distills what you decide and why, and writes it down for you as .lore.md, a version-controlled file of the team’s decisions and gotchas, reviewed in pull requests like any other file. We’ve written before about why knowledge lives in text. You don’t write docs that go stale in a few weeks. You work, and it learns.

An apprentice is not you, and I want to be honest about the ceiling. It won’t learn your deepest judgment, the calls that come from taste you couldn’t explain if you tried. But it learns the standards you set often enough, and that turns out to be a lot of them.

The apprentice reviews the code

This is the thing I wanted ten years ago, and it turns out the achievable part was the part that mattered. Not a machine that thinks like me. One that learned the standards and speaks up when a change goes against one.

So we built a check that reads the diff against what Lore has learned. On every pull request, the semantic linter takes the changes and the standards from .lore.md and asks, for the pairs that look related, one question: does this change go against something the team decided? When the answer looks like yes, it says so, as an annotation next to the line, with the reason attached. The reason is the point. It’s the part of the review that used to pass from person to person and stopped.

It’s a judge, not a rule engine. “Never mock the database in integration tests” isn’t a pattern you can match with a regex, and any lint rule that tried would be brittle and easy to route around. It’s a meaning, and you can only check it by understanding what the change does and what the standard intends. The honest cost is that a judge produces suspicions, not verdicts. It can be wrong, and we designed around that instead of pretending otherwise.

The boring part, handled

If you’re in the “read every line” camp, what you’re rightly afraid of is a noisy check that blocks work on a bad guess. We share that fear, so the linter ships advisory only. It never fails a build. It leaves a note and a human decides. A check that guesses and can break CI would teach everyone to ignore it inside a week.

And if you’re in the “this is soul-crushing” camp, look at what it takes off you: the dull part, checking every change against every standard the team ever set, which is the work no human does well or enjoys. What’s left is the judgment, the taste, whether this is even the right change. The part worth doing.

A ladder above advisory is designed in. Once a team has watched how often the check is wrong, a rule can graduate to a gate, with an override for the author who knows better. That part is still coming. Today everything stays advisory on purpose, because the system should earn trust before it can block anything.

Where’s the limit?

I’m not claiming the reviewer goes away. On the contrary, we’re lightening the reviewer’s load so they can do more of what’s valuable: real judgment and taste. Here’s the line: no reviewer can hold every standard the team ever set and apply the right one at the right moment. That one job a system does well, and handing it over costs you none of the taste you were afraid to lose. It gives you back the attention for the parts that need a person, and brings back, a little, what used to pass between people when they reviewed each other’s work.

That’s the version of automated review I’d ask a doubter to try. Not a bot that approves or rejects your PRs. An apprentice that learned how you work and speaks up when a change breaks from that, and otherwise stays quiet.

Try it

Install Lore and let it learn from a few sessions:

curl -fsSL https://withlore.ai/install | bash
lore run

Then run the check against any range and see what it flags:

lore lint --base main --head HEAD

With no arguments it auto-detects the range. When you’re ready for CI, the semantic linter guide has a copy-paste GitHub Action.

The compaction tax

Lore Team — Wed, 22 Jul 2026 00:00:00 GMT

We have made two arguments on this blog. In Why memory is not enough we said a store off to the side cannot save the session overflowing right now, because compaction runs whether or not it is about to drop something you still need. In How Lore remembers, forgets, and changes its mind we said capture has to be automatic, because memory you have to reach for is memory you will forget to reach for.

Arguments are cheap. So we built a benchmark and ran it, and this post is the receipts.

Agents pay two taxes on memory today. The machine charges one, in dollars and lost context. You charge yourself the other, in attention. We can now put a number on both.

How we measured it

The full protocol is in the repo (see the methodology), and you can reproduce it with lore eval. The short version:

Every run drives a real OpenCode agent, turn by turn, against a real model. We plant four values, stated once in passing, that you cannot guess from the code: an order status, a sales channel, a region, a warehouse. If they show up in the file the agent writes at the end, something carried them. The scorer checks for those four values by hand, so no model grades its own homework. We ran it across three models, from cheaper everyday ones (MiniMax-M3 and DeepSeek V4 Flash, capable but not frontier) up to a frontier flagship (Claude Sonnet-5), because that split is where the two approaches part ways.

This is not the first version of the benchmark. Like any real task, we had to iterate to get numbers that were accurate, reliable, and realistic, especially when a result looked too good for us. An early cut had the competitors at a flat zero everywhere; the cause turned out to be ours, not theirs, and once we fixed it they tied us on the frontier model. So now, before every run, we health-probe each memory backend: if it fails to come up we drop the run as a harness artifact, and if it comes up fine but the model never calls it, we count that as the real zero it is. The numbers below are the corrected ones.

For the record, so you can reproduce it or pick it apart: we ran this in July 2026 on a nightly Lore build (off main, well ahead of the 0.37.0 release) driving our OpenCode fork built on OpenCode 1.18.5. The models were MiniMax-M3, DeepSeek V4 Flash, and Claude Sonnet-5 (claude-sonnet-5). The memory competitors were mem0 (mem0 cloud, via the official mem0-mcp-server) and mnemonic 2.0.2 (the mnemonic-ai package), each given both a light “keep notes” instruction and a heavy mandatory-workflow one, and we report the better of the two.

The first tax: compaction

Put the agent in one long session and keep working until the window fills. Every major client does the same thing at that point: it compacts, crushing the older turns into a lossy summary and dropping the originals. That is the moment the facts you mentioned an hour ago quietly fall out.

One thing to be upfront about, because it shapes every token number in this post: we do not wait for a real workload to slowly fill the window. We force it, by piping a large reference blob into most turns, roughly 90K tokens a turn in this single-long task and a somewhat smaller 64K a turn in the cross-session one (where it is the accumulation across sessions, not the per-turn size, that fills the window). Think of each blob as one large tool result, a big file the agent reads, a long log it pulls in, which is exactly the kind of thing that fills a real context window. We do it this way because reproducing a genuine multi-hour session that overflows on its own is slow and hard to hold steady across runs; forcing the fill gives every arm the identical pressure on a benchmark timescale. The consequence is that the absolute token and cost figures below are a product of that forced fill, not a measurement of what a typical session costs, so read them as relative comparisons between arms under identical load, not as a bill you would see in normal use.

Here is that session, sixteen scripted turns, with the four facts mentioned once near the start, on the frontier model. The “steps” column is the agent’s own work, the model calls and tool round-trips it took to get through those sixteen turns, so fewer is more efficient:

Sonnet-5, one long session	retention	compactions	steps	cost
vanilla	20%	7	56	$9.79
Lore	100%	0	53	$9.54

Two things are happening at once. The vanilla agent compacts seven times and keeps one probe run in five; the retention it does have is noisy, some runs recover a fact from their own summary, most lose all four. Lore never compacts, because it manages the window on every turn instead of waiting for it to overflow, and it keeps all four facts every run, in fewer steps.

The cost here is close to a tie, and that is the honest read: Lore lands just under vanilla, about a quarter under a percent, not a headline saving. Lore’s figure is the whole of its bill, the conversation plus the background distillation that captures memory; the background worker is a small slice of the run (about nine cents here), and this benchmark is part of why it is small. An earlier version showed the worker re-reading whole reference blobs it did not need, so now Lore trims an oversized user blob down to the part that carries meaning before it ever distills, and that trimming is in these numbers. Two further savings are not: in real use the worker runs on a cheaper model than the conversation, and against Anthropic or OpenAI its calls go through the batch API at half price, but this harness pins one model per run and turns batching off so it can finish distilling before the next session (more on that below). Even so, the point of this table is not the dollar column, it is the other two: Lore keeps every fact and compacts zero times, where vanilla compacts seven and keeps almost nothing. A compacting agent that loses the facts is not a cheaper way to succeed, it is a more expensive way to fail.¹

The pattern holds on a cheaper model, where the dollars are small enough to see the shape plainly:

DeepSeek Flash, one long session	retention	compactions	steps
vanilla	0%	5	47
Lore	100%	0	36

The loss is quiet, which is what makes it easy to miss. Independent research on context rot (Chroma’s report, and the contextrot tool that measures it on your own sessions) shows models degrade as their window fills. Compaction does not announce itself. The agent keeps going, confident, having quietly forgotten.

The second tax: remembering to remember

Now the cross-session case, what most people mean by memory: something said in one session, needed in a later, separate one. That is the job a memory store is built for, so we put Lore next to two good ones: mem0 (cloud) and mnemonic (a local SQLite store, the closest analogue to how Lore keeps things on your own disk).

On the frontier model, every system with memory carried the facts, and Lore and vanilla mark the two ends of the range:

Sonnet-5, cross-session	retention
vanilla	0%
Lore	100%
mem0	92%
mnemonic	67%

That is the honest headline: a good store works, and on a capable model it works well. We will not pretend otherwise. Every system had captured the facts; where the competitors miss here it is the model failing to recall on a given run, not the store failing to hold. Even so, on the frontier model the gap is narrow, and we would rather show the spread than round it up to a tie.

The difference shows up on the cheaper, everyday models, the kind you actually run at scale:²

cross-session, cheaper model	retention
vanilla	0%
Lore (DeepSeek Flash)	100%
mnemonic (DeepSeek Flash)	0%
mem0 (DeepSeek Flash)	0%
Lore (MiniMax-M3)	100%
mnemonic (MiniMax-M3)	0%
mem0 (MiniMax-M3)	33%

The gap is not about storage quality, we just saw the stores hold the same facts. It is about who has to remember to use it. A store the agent drives only works if the agent decides, on its own, to save the offhand value when it is mentioned, and then to go looking for it later. When we traced the competitors’ misses, the pattern was almost always the same: the agent never called the save step in the first session. The backend was fine, the tool was there, the model just did not reach for it. An everyday model does not reliably reach. Lore does not ask it to. It captures as the conversation happens, with a dedicated background pass that runs whether or not the coding model thinks to, and surfaces what is relevant on its own. So it does not hang on the model’s discipline on any given turn.

That is the attention tax made concrete. Every store the agent reaches for is a store that depends on remembering to reach, and the further a model sits from the frontier, the less reliably it reaches.

What the stores actually held

Because the interesting question is not just the score but what each system extracted, here is the same fact, “every order defaults to channel WHOLESALE, region EMEA, warehouse WH-07,” as each store captured it:

Lore: “Every order built in orderkit carries these fixed metadata fields: channel=‘WHOLESALE’, region=‘EMEA’, warehouse_code=‘WH-07’. These are not optional, always include them when constructing order objects.”
mem0: “User defines that every order in orderkit includes fixed fields: channel set to ‘WHOLESALE’, region set to ‘EMEA’, and warehouse_code set to ‘WH-07’.”
mnemonic: batched into a single note alongside the other conventions, terser, but the values are all there.

All three are correct. Lore’s tends to carry a little more, the rationale, the “not optional,” a cross-reference to the related convention, because a background pass with a dedicated model has room to write more than a tool call squeezed into the coding agent’s turn. It is a real edge, but a modest one. The decisive difference is not what gets written, it is whether anything gets written at all without the agent being told to.

What it costs, honestly

Cost is where memory tools get quiet, so here is ours out loud, including the part that does not flatter us. On the cross-session run with Sonnet-5:

	measured cost	third-party backend cost
vanilla	$3.92	none
mem0	$3.97	mem0 cloud subscription, external
mnemonic	$4.02	Gemini (embeddings + extraction), external
Lore	$4.02	none

Lore lands right on the vanilla line here, within run-to-run noise, and it did not start there. Two things are true at once. The retention win is real: Lore held all four facts on every run while vanilla held none, and on the cheaper models it held them where the stores did not. And Lore gets there on the same bill as an agent that keeps nothing. Both belong in the same paragraph, and the second one only became true because the benchmark forced us to chase it.

Where the cost went is worth being precise about, because the benchmark is what turned it up. Lore’s figure is the whole bill: the conversation plus the background distillation, on one key, about $0.28 of it the worker. The rest was prompt-cache churn, and measuring this run is how we found it. When Lore first injects a session’s recalled memory it rewrites part of the prefix, which busts the cache for that turn; on the single-breakpoint protocol this benchmark runs through, that one rewrite re-priced far more of the prompt than it should have. We landed three fixes off the back of it: one that stops the recalled-memory block from busting the whole system prefix, one that stops the compression layer from oscillating turn to turn, and one that anchors a stable cache breakpoint at the middle of the prompt so an upstream cache eviction re-bills half the prefix at most instead of all of it. Together they cut this cross-session figure from about $6.22 to the $4.02 above, driving the one-turn cache spike that opened the gap down to nothing. We would rather publish the number we now stand behind, and the road we took to it, than a prettier one we could not explain.¹

The competitors’ lines also hide a cost this table cannot show. mem0 runs on a hosted subscription; mnemonic’s extraction and embeddings run on Gemini. mem0’s is a flat monthly fee, near nothing per run if you already pay it, a whole plan if you do not; the Gemini spend is real but small, and lands on a separate bill rather than your model spend. Either way it is off the bill we can show you, and all of Lore’s is on it.

And Lore’s number here is pessimistic in one direction the others are not: as noted above, the harness runs the worker on the same frontier model and with batching off, both of which you avoid in normal use. Point the worker at a cheap model and that $0.28 bucket drops by roughly ten times; run against Anthropic or OpenAI and the batch API halves it again. That does not close the whole gap, but it is real, and it is on our side to keep closing.

So the honest claim is precise. On this benchmark Lore keeps every fact, answers in fewer steps, and puts its entire cost on one visible bill, and on the frontier cross-session case it lands on the same bill as a vanilla agent that keeps nothing. The single-long frontier run reads the same way, near-identical bills, one that keeps every fact against one that keeps a fifth. You do not pay a premium to stop thinking about any of this, and you still get to account for all of it.

What we are not claiming

The benchmark has limits and we would rather say them than have you find them.

Start with the most obvious one: we built Lore, we designed this benchmark, we ran it, and Lore comes out on top. That is a conflict of interest and you should read the numbers with it in mind. The best evidence we can offer that we took it seriously is the audit we mentioned up top: our first cut had the competitors at a flat zero, we did not like how good that looked for us, we dug in, and the zero turned out to be our bug, not their failure. We fixed it and the competitors climbed to near-parity on the frontier model. We still almost certainly did not tune mem0 or mnemonic as well as their own authors would. If you maintain one of these tools and we got your configuration wrong, tell us and we will re-run it and update the numbers.

We did not meter the competitors’ third-party backends ourselves, so their totals are visible cost plus a small off-bill charge, not a full accounting. The reliability gap on cheaper models is real, but on the frontier model it narrows to a near-tie, and we showed that rather than bury it. On cost, Lore lands on the vanilla line on the frontier cross-session run rather than under it; we put the full table up rather than lead with the retention win alone. Where the numbers are noisy, it is the vanilla arm that carries the noise: the frontier single-long baseline swings run to run, some runs recovering a fact from their own compaction summary and some losing all four, the shape of degradation, not a clean failure. Lore’s cells came in at a flat 100% across every model and cap here, which we read as the task being within reach once the facts are in front of the model, not as proof no ceiling exists. A model can still ignore a value in plain sight, the same way it can ignore any instruction; that is a ceiling no memory layer lifts. We kept every valid run in the averages. The only runs we dropped were ones where a memory backend failed its pre-run health probe, a dead server the model could not have called even if it tried; a healthy backend the model simply never reached for is kept and scored as the zero it is, because that behavior is the finding, not an artifact. And we could not run Lore on an anonymous free endpoint, because its background worker needs a real key.

And, as said above, the window pressure is manufactured: we pipe large reference blobs into most turns to force compaction on a benchmark timescale. That makes the token and cost totals artifacts of the harness, not a forecast of your bill. It is why we lean on the ratios between arms, run under the same forced load, rather than the raw numbers.

All of it, the tasks, the scorer, the raw per-run numbers, is in the repo. Run lore eval and check our work.

Back to the one question

We ended the first post with a question to ask anything sold to you as agent memory: what happens at 200K tokens? Now there is a number on it. The client compacts, you lose most of what mattered, and it takes more steps to get there. A store off to the side does not change that, however good the store is, because it never runs at the moment of overflow. Managing the window in the loop does, and you never have to think about it.

That last part is not hypothetical. Building this benchmark changed the product twice, both times because a result looked wrong and turned out to be our bug. First, an early cut showed cheaper models dropping the incidental facts even when Lore had captured them, so we made Lore fold a session’s own distilled memory into the working context the moment it is written. Then a sharper version of the same symptom: a cheaper-model arm scored zero, and we had a tidy story ready about the model’s ceiling, not our layer. We did not trust our own excuse enough to skip the check, and the check killed it. The facts were captured, embedded, and searchable; the injection path returned nothing whenever a project had no promoted long-term knowledge yet, so on a fresh project it handed the model an empty context. Fixing that flipped the arm from 0% to 100% on both cheaper models. And it did not stop at retention: measuring the cross-session bill turned up three ways Lore was busting the prompt cache more than it needed to, a recalled-memory block that re-priced the whole system prefix on first injection, a compression layer that oscillated turn to turn, and a single cache breakpoint that let one upstream eviction re-bill the entire prompt; fixing all three cut the frontier cross-session cost from about $6.22 to vanilla parity. The benchmark did not just score the product. It kept telling us where it was broken, including the times we would rather have blamed the model.

We have claimed that memory is table stakes and that the real value is active context management. This is the shape of the evidence. On a frontier model, a good store lands near Lore on retention, and Lore’s edge is fewer steps and a bill you can fully account for, now paid at parity with a vanilla agent that keeps nothing. On the cheaper models people actually run at scale, the win is retention itself, because those models do not reliably remember to drive a store by hand, and Lore does not ask them to. We could always feel that difference. Putting a test around it, and being honest when the test caught us, both on what we got wrong and on where we still cost more, is how we keep improving it.

A note on where the dollar figures come from, since the two arms are metered differently. On the Lore arm, Lore manages the window and proxies the model calls, and OpenCode records zero token usage for those turns, so Lore’s dollars come from Lore’s own cost ledger while vanilla’s come from OpenCode’s usage stream. Both meters multiply the same token counts by the same models.dev prices, so the numbers are comparable, but they are two meters, not one, and we would rather you know that than assume otherwise. ↩ ↩²
Our first instinct was that the competitor zeros had to be a harness bug. They are not. We health-probe each memory backend before every run, and every backend here came up fine: mnemonic’s local database initialized with its full schema, mem0’s cloud connected and stored on other runs. The zeros are behavioral. On DeepSeek the model mostly never called the store at all, in either direction; on M3, mnemonic was invoked (three to four calls a run) and still returned nothing usable at recall time. We count these as the real 0% they are rather than excluding them, because “the cheaper model did not reliably drive the store” is the finding, not an artifact to discard. ↩

Distill the knowledge, not the model

Lore Team — Mon, 13 Jul 2026 00:00:00 GMT

The diagnosis is right

Satya Nadella posted this week about what he calls the Reverse Information Paradox, and if you build with these models you already feel it. You pay for intelligence in cash, and then you pay again in the proprietary knowledge you reveal to make it useful. The harder you push the model to perform, the more of yourself you feed it. He’s right, and it’s the cleanest framing of the problem we’ve seen.

The valuable part is everything around a single prompt: how you work a problem, the fixes you apply when the model gets it wrong, the standard you hold it to. Enough of that adds up to a portrait of how your team actually thinks, and the portrait moves in only one direction. The provider gets a little more of it every session. You get an answer to today’s question and nothing about what they kept.

Look closely at the fix

Here’s where we part ways with him, and it’s worth being specific about how. Much of what he prescribes we have no quarrel with, and some of it we already build. This is about one piece.

Nadella’s answer is that enterprises should win “the rights to use model outputs to fine tune and/or train their own models.” Read that twice. The remedy he’s reaching for is the right to train on the exhaust. In the industry that has a name, distillation: using a strong model’s outputs to teach a competing model. Anthropic and the other frontier labs restrict exactly this, which is what he means by “restrictive terms on distillation.”

It’s worth asking who that fix helps most. Training or fine-tuning a model on your own traces is expensive, and it pays off only at a scale and with a purpose most companies don’t have. It reads less like a fix for everyone and more like one sized for large players who want to build or tune models of their own. Microsoft, for its part, has no frontier-class model of its own yet, its bet on a single provider has grown complicated, and it’s now building in-house. We can’t see anyone’s intent and won’t pretend to. But when a fix this specific arrives bundled with the diagnosis, it’s fair to notice that the principle and the interest happen to point the same way.

It also reaches further than the problem needs. Nadella writes that the answer “requires more than data protection,” and leans on that to justify training rights. But look at the leak he actually describes: the provider walks away with a compounding record of how you work, and you walk away with nothing durable. That gap closes the moment you start keeping and compounding the learning on your own side. You do not need the right to train a model to do that. Training rights are a separate, much larger ask, folded into the same sentence as if they were the same need.

Learning doesn’t have to live in weights

The move that dissolves most of the debate is noticing that “learning from your interactions” and “training a model on your interactions” are two different things.

There are two kinds of distillation. One compresses a teacher model into a student’s weights. That’s the kind under dispute, the kind that’s expensive, and the kind the frontier labs forbid. The other compresses your history into a compact, durable record that rides in the context window: the decisions you reached, the conventions you set, the corrections you made. No training run. No weights. No violated terms.

When we say distillation, we mean the second kind. It’s the framing we took from Sanity’s Nuum, distillation, not summarization, and it’s the whole reason Lore can hand you a compounding learning loop without going anywhere near a model’s weights.

What Lore does instead

The learning accumulates in a single file on your own disk. Distillation compresses your sessions into a dense record of what was established. The knowledge layer pulls out the decisions, conventions, and gotchas as they happen, including the ones you only ever expressed by correcting the model. You never have to remember to save anything, and none of it lives in someone else’s tenant. No account, no server, and none of this learning leaves your machine unless you choose to share it with your team.

Be honest about the wire: your prompts still go to whatever model you’re using, because that’s how you get an answer. Lore doesn’t pretend otherwise. What it changes is the other side of the ledger. The distilled history, the extracted knowledge, the patterns, the record of every correction, all of it gets captured and compounded on your side too, in token space, where no distillation rule reaches. The provider still sees each turn. It just stops being the only one that walks away with a durable record.

That seat, seeing every token of every session, only makes sense if it’s yours. It’s why Lore is Fair Source (FSL-1.1-Apache-2.0): the code that touches your tokens is right there to read, and it turns into Apache 2.0 on a timer.

Portability without the weights

Nadella’s sharpest point is about lock-in. If the model you rely on were taken away tomorrow, would your veteran capability go with it, or would it stay with you?

This is the part we already shipped. Lore sits between you and the model, outside any one agent. Your memory doesn’t belong to Claude Code or Codex or OpenCode. It belongs to the file. Switch models, switch agents, run three at once, and the same accumulated context comes along. A generalist model becomes a veteran of your codebase, and that veteran capability is yours to keep. Take the model away and the learning stays. You get the portability he’s asking for without owning a single weight.

You can skip the debate

Whether the frontier labs should loosen their terms on distillation is a real argument, and it’s going to play out over years between companies with far more at stake than you. You’re welcome to watch it.

You don’t have to wait for it. The learning loop Nadella says every organization needs already exists in a form that asks no one’s permission: token-space, local, model-agnostic, running today. In consuming intelligence, you are creating intelligence. That’s his line, and he’s right about it. The only question is who keeps it, and you can answer that one yourself this afternoon.

How Lore remembers, forgets, and changes its mind

Lore Team — Thu, 02 Jul 2026 00:00:00 GMT

Everywhere you look, agents are being taught to fix themselves. Self-healing loops, self-improving memory, a model that reads back its own transcript, rewrites its own instructions, and prunes whatever it decides has gone stale. There is real energy here, and some of it genuinely works.

Here is the catch, and it is an old one. Self-correction is the hardest kind. Whatever made a mistake is usually the worst-placed thing to catch it, because from the inside the mistake still looks like a reasonable call. People hit this constantly, which is why we lean on outside help: an editor for the draft you have read too many times, a reviewer for the code you are sure is fine, a colleague who remembers you already tried that back in March. The whole value is that they are not you. A model sits in the same spot. Once it has written a shaky assumption into its own memory, it is not the thing you can count on to go back and find the error.

Lore takes a different road to the same destination. You never have to manage memory, and neither does the agent. A fixed set of rules, enforced by the layer that sits in the request path, makes the call on every turn instead. That distinction matters more than it sounds. A set of principles written for an agent is guidance, and it holds only when the agent is paying attention. The same principles built into the layer are guarantees. They hold whether or not anyone is paying attention that turn.

And because that layer sits outside the model, a model swap does not take your memory with it. A newer model arrives brilliant and completely unfamiliar with your work, the way a new hire does; the layer is the institutional memory already in the room, so the model is useful on the first turn instead of the fiftieth. Change the engine as often as you like. The assistant, and everything it has learned, stays.

So here are the rules Lore runs on. Not aspirations we hope a cooperative model follows: the actual behavior of the layer that touches every token.

You never have to remember to remember

Capture is automatic. Lore sits between your agent and the model, and it distills your work as it happens. You do not tag a message, save a decision, or file anything away for later.

This is the whole reason capture lives in the layer. Memory you have to reach for is memory you will forget to reach for, right at the moment you are heads-down on the actual problem. The filing was never the hard part, and it should never be your job. If a rule for managing memory depends on you (or the agent) remembering to invoke it, it is already broken.

Getting it back works the same way. When memory only returns because the agent thought to call a search tool, the knowledge can be sitting right there and never reach the model, because nobody went looking. Lore surfaces what is relevant on its own, and keeps a recall tool for when the agent wants to dig deeper, so recall does not hang on the agent’s discipline on any given turn either.

Being surfaced is not being right

When Lore pulls a memory into your context, that is a bet about what might be relevant this turn. It is not a vote on whether the memory is true. Selecting an entry never raises its confidence.

That separation keeps the store honest. A note that keeps getting surfaced but never actually helps does not get more entrenched just for being loud. Confidence is earned somewhere else, by whether the knowledge holds up in practice, and the act of showing it to the model is kept strictly out of that accounting.

Confidence is earned, and it decays

Every entry carries a confidence score. It rises when the knowledge proves useful across sessions and drifts down when it sits untouched. Fall below the floor and the entry is evicted. The store stays bounded by usefulness rather than by a fixed timer that forgets things on a schedule, whether or not you still need them.

There is one deliberate exception. The preferences you state outright, the ones that follow you across every project, are protected from that decay. Those are not guesses Lore made about you, so they are not subject to the same erosion as things Lore inferred.

When two things disagree, you get told, not overruled

Opposing rules are never quietly merged. “Always use tabs” and “always use spaces” are not two versions of one fact, and collapsing them would be Lore deciding for you. Both are kept and ranked by confidence.

Genuine contradictions still need settling, so Lore looks for them in the background and flags each pair for you: on the knowledge dashboard, or from lore data contradictions. You pick the rule that still holds, or you keep both. Lore never merges them and never deletes the losing side on its own. The layer’s job here is narrow on purpose: notice the conflict and hand it to you. Picking a winner silently is exactly the kind of decision a memory system should not be making.

Nothing is really deleted

Knowledge is append-only. An edit writes a new version and keeps the old one; a delete leaves a marker rather than erasing the trail. Because the history is intact, you can diff what your agent has learned and roll it back, the same way you already do with code.

That is not an abstract property. Curated knowledge lands in a plain .lore.md file in your repo, so a change to your agent’s memory shows up in a pull request and gets reviewed by the same people and the same process that review your code. Memory that changes without a diff is memory nobody can audit.

The live edge stays whole

The most recent turns are always protected. Whatever gets distilled or dropped as older context is compressed, the active end of the conversation, where the work is actually happening right now, is never touched. Everything else is negotiable under pressure; the edge you are working on is not.

What’s learned lives in tokens, not weights

Lore learns by writing durable text, not by fine-tuning the model. That is a deliberate choice. Text is something you can read, carry across providers and across model generations, and undo a line at a time. Knowledge baked into weights is none of those things: you cannot inspect it, it does not move to the next model, and you lose it on the upgrade. The model is the part you replace. The knowledge is the part you keep.

Boring on purpose

Making a model better at checking itself is worth doing, and we hope it keeps improving. But the corrections you can lean on are the ones that do not wait for the model to notice, this turn, that it was wrong. Those come from outside it.

Lore’s bet is narrower, and honestly a little boring in the way infrastructure should be: the rules that decide what stays, what fades, and what gets surfaced ought to hold on every single turn, not only when the agent happens to be attending to them. A principle the layer enforces is one you never have to hope about.

And because a layer that sees every token is a lot to ask you to trust, the rules above are not a description you take on faith. Lore is Fair Source (FSL-1.1-Apache-2.0), so the code that decides what your agent remembers and forgets is right there for you to read, and it turns into Apache 2.0 on a timer. Principles you can enforce are better than principles you have to believe.

Why memory is not enough

Lore Team — Fri, 26 Jun 2026 00:00:00 GMT

Ask anyone building agents what “memory” means and you’ll get the same answer: a place to store facts and decisions so the agent can pull them back later. A vector DB, a knowledge graph, a folder of notes, take your pick. It remembers what you discussed last week, and there are good tools that do this well now.

Now ask the harder question. What happens when the session you’re in right now crosses 180K tokens and the agent starts forgetting how it began?

The usual answer is a list of chores. Spin up a background agent. Write the plan to a file, then a second, then a third. Open a trail of GitHub issues. Leave notes in scratch markdown. Keep a tidy AGENTS.md and prompt more carefully while you’re at it. Every one of these is the same move: manually push state out of the window and hope it finds its way back. That’s you doing the filing. Maybe your tools file it for you now, straight from the conversation, so you never lift a finger. Better, but capture was never the hard part. The question is what stays in the window this turn, and saving something to a store, by hand or automatically, doesn’t decide that.

When the filing isn’t enough and the window fills mid-task, the one automatic mechanism every major agent ships kicks in: compaction. The client crushes the older turns into a lossy blob, drops the originals, and hands you back an agent that was a genius a minute ago and now can’t quite remember its own name. We all quietly accepted this for something that happens every session, often more than once: the most predictable failure in agentic coding, answered by a guillotine. So why has nobody built the thing that keeps up?

Two problems hiding behind one word

What you say	What it actually needs
“What did we decide about auth last week?”	A long-term memory store.
“Wait, what was the other thing you said we should do after this?”	Active context-window management.

These are not the same layer. A long-term store sits beside your conversation, like a notebook you keep open on the desk. It only holds what you bothered to write down, and it only helps when you reach for it. That’s exactly right for what carries across sessions: a decision, a preference, a constraint from days ago. This part has had real product attention, and it shows.

The live window is the other half, and it’s the one you’re left to manage by hand, mid-task. People do this well, but it’s a tax: every note you set down pulls your focus off the actual problem, and you have to remember to pick it back up later. And every tool for it is the same shape: static (a markdown file the model may or may not read), offline (an indexer you run between sessions), or just advice (“prompt better”). None of it is in the loop at the one moment that matters, when the window is overflowing while you work. The one mechanism that does fire on its own is compaction.

A store on the sidelines can’t intervene

That compaction step is triage with a blunt instrument: it runs whether or not it’s about to drop something you still need, with no idea what’s worth keeping. Now bolt the best long-term memory store on the planet onto the same session. What changes? Nothing. The store can answer a question if you ask it, but compaction doesn’t ask questions. It just runs. The store never gets a vote on what survives. So you can have flawless recall of last week and still watch the agent get amnesia at 200K tokens.

Some tools go further than a hand-fed store: they keep the entire conversation and let you search over it. That’s genuinely better, and it’s worth saying so. But searching is something you have to do, after you’ve already noticed something went missing, and whatever you pull back lands in the same window that was overflowing in the first place. You found the needle, and the haystack is still on fire. And automating the search doesn’t save it: async, agent-native RAG still drops what it finds into the same window, and still never decides what leaves it.

There’s a deeper reason the window wins. A model uses what’s already in front of it far more reliably than what it has to fetch: hand it the relevant text in context and it beats RAG on the same text (Li et al.), and what it does hold, it reads best at the edges, not buried in the middle (Lost in the Middle).

RAG has one honest advantage: it’s cheaper to pull a few snippets than to carry the whole history. But that only pays off when a small slice can substitute for everything else, and an agent session is the opposite case. RAG can only add to the window, never stand in for it.

What managing the window actually looks like

Two hundred turns deep, that means keeping the auth decision and the path of the file you’re editing while dropping the stale 4,000-token test dump, without anyone having to ask. To make that call on every turn, instead of letting a blunt summarizer maul the whole thing at the boundary, a few things have to be true:

Keep a distilled prefix at the front. Compress the early conversation into a dense, structured record of what was established: the decisions, the shape of the work, the constraints. That record stays pinned to the front of the window where the model can always see it, carrying the load-bearing facts the rest of the work leans on.
Compress gradually, in layers. Full passthrough while there’s room. As pressure builds, compress the raw turns behind the distilled prefix. Under more pressure, strip what ages worst first: stale tool output, redundant dumps. Emergency compression stays the last resort.
Calibrate from the real token counts. The window is a hard budget. What gets cut should follow the actual token counts the API reports back, and what each model’s real context and pricing are. A character cap hardcoded once and forgotten tracks none of that.
Protect the live edge. The most recent turns stay intact, always. Whatever happens upstream, the active end of the conversation is where the work is happening, so it stays whole.

What matters here is the loop: something is actively deciding what stays in the window on every turn, instead of a one-shot summarizer flattening the session the moment it overflows.

Two layers, one stack

This isn’t memory versus context management. You need both, and they stack:

Temporal storage. Everything that’s said, captured and indexed, so nothing is truly lost even after it leaves the window.
Distillation. That history compressed into a dense prefix, so the established facts survive context pressure and stay in front of the model.
Long-term knowledge. The durable decisions, patterns, and preferences pulled out and carried across sessions, retrievable on demand.

That store, layer 3, is what people mean today when they say “memory”. It’s the top of the stack, not the whole stack. Without the two layers under it, it’s a filing cabinet next to a conversation that’s quietly falling apart.

The work this is built on

We didn’t invent this architecture, and we want to be clear about that. Two teams got here first and proved it works. Sanity’s Nuum gave us the framing we still use, “distillation, not summarization”, and showed a three-tier memory staying coherent across thousands of messages. (Simen Svale’s description of compaction as “JPEG compression of memory management” is hard to forget once you’ve read it.) Mastra’s Observational Memory worked out the observer/reflector loop and the move from rigid JSON to plain, timestamped observation logs. Lore is built on both, and it’s better for it. Their write-ups are worth your time.

There’s a catch, though. Both teams shipped this architecture inside their own agent. Nuum is a standalone REPL (Anthropic-only, yolo-mode, built to power Sanity’s Miriad). Observational Memory lives inside the Mastra framework. The memory is excellent. The packaging is the constraint. Almost no one is going to replace the coding agent they already rely on just to get a context-management layer.

Unhook it from the harness

So that’s the gap: take the same ideas and unhook them from the harness. Deliver them as a layer that works with whatever agent you’re already using, on whatever provider you’re already paying for.

Here’s the distinction that actually matters, and it’s easy to miss now that everything calls itself memory. A store is a tool the agent reaches for: it sits off to the side and answers when it’s asked, however clever the asking has gotten. A layer sits in the request path. Every turn flows through it, and it can reshape that turn before the model ever sees it. That position is the only one from which you can manage the live window at all.

It’s also the most invasive seat in the system, and that’s worth being honest about. A thing that sees every token of every session only earns that seat if it’s yours: a single file on your own disk, no account to create, no database to run, nothing leaving your machine unless you choose to share it. It’s also why this is Fair Source (FSL-1.1-Apache-2.0): the code that touches your tokens is right there to read, and it turns into Apache 2.0 on a timer. That last part is hard for a cloud service to follow you into. Routing every token through someone else’s box is a lot to ask, and a lot for that box to be responsible for. The seat really only makes sense when you’re the one sitting in it.

That same vantage point, seeing every request as it happens, is also the right home for a lot more than distillation:

Warm the cache automatically, so you’re not paying full price for a cold context at the start of every session.
Extract long-term knowledge on its own: decisions, conventions, gotchas, without you remembering to save anything.
Recognize patterns in how you and your agent actually work, and act on them.
Track token spend day to day, across every agent you run.

That last one is quietly becoming the point. As model and token costs climb, the layer that sees every request is exactly where cost control belongs, and because it runs on your own machine, there’s no infrastructure bill and no per-request meter to feed. A store on the sidelines can’t do any of this. Plenty of them run the other way: a server you’re renting, an extra model call to extract and index every exchange, and a metered fee on top of the requests you were already paying for.

And once memory lives in that layer instead of inside one agent, it stops belonging to any single agent. Your context follows you. Move from Claude Code to Codex to OpenCode, or reach for a different agent on a different task, and the same memory comes along. A team running a mix shares one knowledge base instead of three separate silos. Portability comes free once the memory no longer lives inside the harness.

Memory is the wedge. The layer is the platform.

The one question worth asking

Next time something is pitched to you as agent “memory”, ask one question:

What happens at 200K tokens?

If the answer is some version of “you can search what we stored”, or worse, “write a better context file”, then it’s a storage tool, and the part that actually breaks mid-session is still yours to handle. That’s fine, and a good store is genuinely worth having. But it has no answer for the session that’s overflowing right now, which is the problem you’ll hit today, not next week.

Memory is table stakes. Managing the window, in the loop, while it fills, is the part nobody wants to build. Make sure you know which one you’re being sold.

Introducing the Lore Blog

Lore Team — Fri, 05 Jun 2026 00:00:00 GMT

The Lore blog is ready for longer-form writing: release notes, implementation notes, architecture posts, and the practical lessons that show up when AI coding agents work inside real codebases for days at a time.

Future posts will cover LLM memory architecture, distillation techniques, context management strategies, and engineering updates from the Lore team.

Lore Blog

The Agentic Memory Trap

The platform owns your data. You should.

Lore is local-first and we want to keep it that way

The vendor route vs the local-first route

Why this matters

Try it

The Semantic Linter: Automating reviews without losing touch

The same complaint from two sides

What review was really passing along

You are what you do, not what you write down

The apprentice reviews the code

The boring part, handled

Where’s the limit?

Try it

The compaction tax

How we measured it

The first tax: compaction

The second tax: remembering to remember

What the stores actually held

What it costs, honestly

What we are not claiming

Back to the one question

Footnotes

Distill the knowledge, not the model

The diagnosis is right

Look closely at the fix

Learning doesn’t have to live in weights

What Lore does instead

Portability without the weights

You can skip the debate

How Lore remembers, forgets, and changes its mind

You never have to remember to remember

Being surfaced is not being right

Confidence is earned, and it decays

When two things disagree, you get told, not overruled

Nothing is really deleted

The live edge stays whole

What’s learned lives in tokens, not weights

Boring on purpose

Why memory is not enough

Two problems hiding behind one word

A store on the sidelines can’t intervene

What managing the window actually looks like

Two layers, one stack

The work this is built on

Unhook it from the harness

The one question worth asking

Introducing the Lore Blog