Part I
The Amnesiac Machine
Why coding agents forget everything, why the standard fix doesn't scale, and the one design commitment from which everything else in lore follows.
Here is a thing that happens if you use a coding agent seriously. On Monday it spends forty minutes discovering that your test suite deadlocks unless a certain environment variable is set, that the ORM silently swallows a class of constraint violations, and that the team never uses barrel imports. On Tuesday it discovers all three again. The model is brilliant and the process is Sisyphean: every session starts from the same blank slate, and everything learned in between evaporates when the context window closes.
The industry's standard fix is the instructions file — CLAUDE.md, AGENTS.md, Cursor rules. You (or the agent) write down the important stuff, and the harness pastes the whole file into context at the start of every session. This works, for a while. Then three failure modes arrive roughly in order. First, the file grows until it costs real context and adherence visibly degrades — models attend poorly to line 340 of a rules file. Second, nothing distinguishes true entries from stale ones; the file says the build takes one command and it's been a different command since March. Third, and most fundamental: everything loads always. There is no notion of relevance, so a note about the deploy pipeline taxes every session including the ones that only touch CSS.
Lore is a response to all three, built by someone who evidently decided that if memory is worth having, it's worth engineering — and that most of the engineering isn't storage. It's a per-project knowledge store plus what its README calls a "multi-agent protocol layer" that rides on top of a coding harness (Claude Code as the reference; OpenCode and Codex CLI as ports). The pitch, from its own protocol text, is one sentence:
Lore is memory by agents, for agents: each cycle records what it found so the next starts there, not from scratch. claude-md/05-system-frame.md
The interesting part is the sentence that follows it. You — the agent reading it — are told you have no standing reason to trust any of this, and are invited to check. That's not rhetorical flourish; it's the system's load-bearing design commitment, and it's worth dwelling on before touching any machinery.
Memory as falsifiable claims
Most agent-memory systems store notes: summaries, extracted facts, embeddings of things that seemed important at the time. Lore stores claims — and a claim, in lore's ontology, is something that carries enough metadata that a later agent (or script) can check whether it's still true. Every knowledge entry is a small markdown file with the insight in prose and a machine-readable footer recording, among other things: who produced it (a worker? a researcher? during which protocol step?), the git branch and commit it was observed at, a confidence level, a scale label, and a status. Claims produced during structured work go further and carry a falsifier — the concrete condition under which the claim should be considered dead — plus a file, line range, and an exact source snippet with a normalized hash, so drift can be detected mechanically when the underlying code changes.
This is the move everything else follows from. If memory is a pile of notes, the only maintenance operation is "reread and prune," which nobody does. If memory is a set of checkable claims, you can build machinery: staleness sweeps, contradiction detection, trust scores that respond to verification events, and an audit loop that punishes memory for being wrong. Lore builds all of it.
The harness is the host coding agent — Claude Code, OpenCode, Codex CLI. Lore is not a harness; it's a parasite (in the ecological, non-pejorative sense) that installs hooks, skills, and instructions into one. The knowledge store is a directory of markdown per project, at ~/.lore/repos/<git-remote>/, shared across clones of the same repo. Logic (scripts, skills) lives in the lore repo; data lives in ~/.lore/; a symlink connects them.
Four substrates, one writer each
Persistent state is divided into four substrates, and each has exactly one sanctioned writer — a rule the codebase calls the sole-writer invariant and takes seriously enough to enforce in code (Part III):
- Knowledge — the durable insights, filed into category directories:
principles/,architecture/,conventions/,gotchas/,workflows/,abstractions/,domains/. One file per entry. Written only throughlore capture. - Work items —
_work/<slug>/directories holding plans, notes, task lists, and evidence logs for in-flight efforts. Written throughlore workverbs. - Threads —
_threads/, conversational memory: evolving preferences and discussion context that isn't a fact about the code. - Scorecards —
_scorecards/rows.jsonl, append-only telemetry about how well the system itself performed. Written only through one shell script, and — critically — never shown to working agents.
The separation matters because each substrate has a different truth model. Knowledge claims can be falsified against code. Work items are plans, which are neither true nor false. Threads are preferences, which only the human can contradict. And scorecards are measurements, which must be protected from the thing being measured — a distinction most memory systems never draw, and the subject of Part III.
The capture gate: writing less on purpose
The failure mode of automatic memory is pollution. Systems that summarize every session accumulate confident garbage, and retrieval then serves the garbage back with the same authority as the good stuff. Lore's counter is an aggressively conservative write policy called the 4-condition gate. An insight is captured only if it is all four of:
- Reusable — applicable beyond the current task;
- Non-obvious — a future agent wouldn't re-derive it from files it already loads (the README, the instructions file, the code itself);
- Stable — unlikely to change soon;
- High confidence — verified by looking, not speculated.
The stated target is one to three captures per substantial session. That's a striking number if you're used to systems that write dozens of memories per conversation. The bet is that memory quality compounds and memory noise compounds faster — and that a store of two hundred verified, non-obvious claims beats a store of five thousand auto-extracted ones. (Whether the gate can be enforced, as opposed to requested, is a genuinely hard problem we'll return to.)
Scale: the altitude problem
The most idiosyncratic idea in lore's retrieval design is that every entry and every query declares an altitude. Entries are labeled with one of four scales — implementation, subsystem, architecture, abstract — and lore search refuses to run unless the caller declares which scale set it wants. Not defaults-to-everything; refuses. The protocol text is blunt about why:
Off-altitude content is harmful, not just useless. Implementation details when designing architecture push toward over-specification; architectural philosophy when fixing a bug makes you over-think a one-line change. claude-md/20-retrieval-protocol.md
This treats a real and under-discussed failure of RAG-for-agents. Relevance scoring answers "is this about the same topic?" but not "is this at the altitude the current task needs?" A grand design principle and a line-level gotcha can both match the query "authentication," and injecting the wrong one doesn't merely waste tokens — it biases the work. Forcing the agent to declare altitude before retrieving is a small, cheap intervention against a bias (grab all plausibly-relevant context, just in case) that the protocol names explicitly: "'Just in case' is recall-bias asking."
Anatomy of an entry
Here's what a captured entry actually looks like on disk — a real-shaped example with every provenance field present. Click the highlighted tokens to see what each one is for.
Instrument · knowledge entry, annotated
# Test suite deadlocks without PG_POOL_MAX
Integration tests hang (not fail) when PG_POOL_MAX is unset, because the
fixture factory opens one connection per parametrized case and the default
pool of 5 exhausts silently. Set PG_POOL_MAX=20 in any test invocation.
**Example:** `PG_POOL_MAX=20 pytest tests/integration -x`
<!-- learned: 2026-06-14 | confidence: high | source: implement |
related_files: tests/conftest.py | producer_role: worker |
protocol_slot: implement.task | template_version: 3f9c02ab54de |
scale: subsystem,implementation | captured_at_branch: main |
captured_at_sha: 27a4ecc | status: current -->Two details are more thoughtful than they look. Omitted fields are dropped from the footer entirely — except the branch/commit trio, which is always written, even as the literal string "null", so that later reconciliation can distinguish "this field didn't exist when the entry was written" from "it existed and resolved to nothing." And the falsifier, though validated at capture time, is deliberately not persisted in this footer (its home is a separate evidence row) because a falsifier containing a pipe character would corrupt the |-delimited parser. Someone debugged that.
So the core ideas, in one breath: memory is a set of provenance-carrying, falsifiable claims, written sparingly through a gate, filed at a declared altitude, and separated into substrates with one writer each — all so that the machinery in the rest of this series has something it can actually audit. Part II covers that machinery: what physically happens when a session starts, how retrieval works, and the four-skill loop that turns work into evidence and evidence into better instructions.
Part II
The Harness
What lore physically consists of — hooks, a CLI, skills, agent roles, and adapters — and the audit loop that connects them.
Strip the ideas away and lore is a surprisingly large pile of very unfashionable technology: 258 shell scripts, 41 Python scripts, a 2,212-line bash CLI dispatcher with about sixty verbs, 25 skill definitions, 13 agent role prompts, and a 62,000-line Go terminal dashboard. There is no server, no daemon, no database beyond SQLite, and no queue beyond files renamed atomically in directories. Every layer communicates with every other layer by reading and writing files. This is a deliberate architectural stance — the coordination docs state flatly that vertical arrows in the diagram are "reads and writes, not calls" — and it buys crash-tolerance, inspectability, and multi-harness portability at the price of some process-spawn overhead.
The pieces sort into five groups.
1. Hooks: the involuntary layer
Hooks are the part of lore the agent doesn't choose to run. The installer writes entries into the harness's settings so that at session start, a chain of seven scripts fires: reindex the store if stale, mine the previous session for retrieval misses (more on this in Part III), assess the previous session's knowledge deliveries, then load knowledge, work items, and threads into the opening context, and extract a session digest. At pre-compaction and session end, a reminder nudges the agent to persist anything ephemeral. Two more hooks are enforcement rather than convenience — a write-guard and a completion-report validator — and they get their own treatment in Part III.
The interesting engineering is in what the session-start loader does with its budget. It gets 8,000 characters and about six seconds, and inside that it runs a strict priority scheme:
Instrument · session-start injection, 8,000-char budget
Priority order in load-knowledge.sh. Signals (pending captures, inbox counts) come first; a compact category index always ships and is deliberately not charged against the budget; backlinks named by the current git branch's work item are resolved to full text; whatever budget remains goes to a relevance search whose results degrade from full entries to titles-only. If the time budget runs out first, the search is skipped with a visible [budget] notice — degrade loud, never silent.
That last clause is a small design signature worth noticing. An earlier version of lore had hooks timing out at five seconds, and a hook that times out in Claude Code kills its payload silently — sessions were starting with zero knowledge and nobody could tell. The fix (raise the timeout, and make every internal degradation print a notice) is recorded in a code comment like a scar. A system whose whole premise is "context injection you can rely on" has to treat silent degradation as its worst enemy, and lore consistently does.
2. The CLI: sixty verbs over two search engines
The lore CLI is the interface both humans and agents use. Most verbs are thin dispatch to a script, and the scripts that matter most are the retrieval stack. The core searcher is SQLite FTS5 with BM25 ranking and Porter stemming — lexical, not embeddings. On top of raw BM25 sit three refinements: a 2× boost for knowledge entries over work-item text; a multiplier folded from each entry's trust score (Part III), so that verified entries outrank contradicted ones at equal lexical relevance; and an optional composite rerank blending BM25 (0.45), recency (0.25), TF-IDF cosine similarity (0.15), and structural importance (0.10). An embedding mode exists — MiniLM vectors cached by content hash — but it's off by default and lazily imported. For a store measured in hundreds of entries, this is probably the right call: BM25 over titled, well-written markdown is hard to beat, and it's fast, deterministic, and dependency-free. It will become the wrong call if stores grow past a few thousand entries; we'll get there in Part V.
Two retrieval verbs matter. lore search returns a ranked list of snippets — discovery. lore prefetch returns a paste-ready context block: full section content resolved for each hit, deduplicated, budget-degraded (full → snippet → backlink-only), annotated with staleness warnings, and always accompanied by a side-channel of user preferences. Prefetch is what gets embedded in subagent prompts; its output is explicitly framed to the receiving agent as "candidates, not answers."
3. Skills: the ceremony layer
Skills are markdown protocols the agent executes — and lore's are not small. /spec is 690 lines, /implement 588, /retro 852. They encode a full development ceremony:
/spec— turns a work item into a plan. In full mode the lead composes an investigation plan (with a user approval gate), then spawns up to four read-only researcher agents, each seeded with a prefetched knowledge block. Researchers return structured assertions — claim, file, line range, falsifier, significance — which flow into the plan and into an evidence log./implement— executes the plan with up to four worker agents. Every task line in the plan must name a deliverable, the files it owns, and a judgment-class marker (mechanical | standard | judgment-dense) that routes it to a different model tier. Workers emit file-anchored evidence rows during the work and end with a structured completion report; a lead-side loop dispatches newly unblocked tasks in batches./retro— after a cycle, reads the evidence bundle and scores how the system (not the code) performed: was delivered knowledge used? harmful? missing? Its headline output is a non-compensatory pass/weak/fail verdict per prompt-template version./evolve— the only path by which those verdicts become edits to the skill and agent templates themselves. Heavily gated; Part III.
Around these sit the memory-facing skills (/remember, /memory, /work), a PR-review family with eight specialized lenses, and /coordinate, which drives whole features across multiple protocol sessions. Together they form a loop — and the loop, not any single skill, is the actual product:
Instrument · the audit loop — click a stage
4. Agent roles: a cast of thirteen
The agents/ directory defines the dramatis personae: workers (implement one task), researchers (read-only investigation), advisors (persistent domain experts workers can consult mid-task, via a formal consultation protocol with turn boundaries), chaperones (cheap agents that shepherd work dispatched to a different harness, like Codex, and relay the bill), plus a back-office of judges and janitors: three correctness gates (one each for assertions, contradictions, omissions), a curator, a reverse auditor, a classifier, a structure analyst, and a crossref scout. The judges are the settlement pipeline — the machinery that decides whether a worker's captured claim graduates into the shared knowledge commons — and they are calibrated before their verdicts are allowed to mutate anything, which is exactly the kind of sentence that shouldn't make sense for a markdown note-taking system and does here.
5. Adapters: capability cells, not framework names
The final layer is what makes lore portable. Nothing in lore branches on "is this Claude Code?" Instead, adapters/capabilities.json declares ~15 capabilities per harness — hooks, subagents, team messaging, transcript access, model routing, completion enforcement — each at one of four levels (full / partial / fallback / none), and each backed by a dated evidence citation in a companion file. Skills declare what they require; when a harness falls below the requirement, the skill degrades along a documented ladder rather than breaking. The clearest example: completion-report enforcement is native_blocking on Claude Code (a hook can reject a bad report before the agent resumes), degrades to lead_validator on OpenCode and Codex (the lead checks post-hoc), and if neither is available the team skills simply refuse to run. On a harness with no subagents at all, /spec quietly collapses into its single-agent short mode.
This is the same discipline as the knowledge entries pointed inward: even claims about what the host platform can do carry provenance and dated evidence. It's also, incidentally, the most reusable idea in the codebase for anyone building multi-harness tooling of any kind.
The question "what does the harness consist of?" has a two-level answer. The host harness supplies primitives: a context window, tools, hooks, subagent spawning, settings. Lore then assembles those primitives into a second-order harness — involuntary context injection (hooks), a shared filesystem substrate (the store), enforced report shapes (validators), and a measurement loop (scorecards → retro → evolve). The host harness runs an agent; lore's harness runs a process across many agents and many sessions.
Part III turns to the question all of this begs. The skills are hundreds of lines of instructions. The gates are conditions written in prose. The model can ignore prose. What actually makes any of this happen?
Part III
Trust, but Verify
LLMs ignore instructions. Lore's answer is a thin layer of hard blocks at write-time chokepoints, a wide layer of soft protocol, a measurement substrate the agents can never see — and one cautionary tale about enforcement that got deleted.
Every agent-protocol system faces the same embarrassing question: you wrote eight hundred lines of beautiful procedure, and the model is a stochastic process that read them once, quickly. What ensures compliance? There are only three honest answers. You can plead (put it in the prompt and hope), you can block (make the harness mechanically reject non-compliant actions), or you can measure (let violations happen, record them, and correct the system afterward). Lore uses all three, and the interesting part is where it draws the lines.
The hard layer: block at the writer, not the prompt
Lore's blocking enforcement is deliberately thin and placed almost entirely at write-time chokepoints — the moments where bad data would become durable. A comment in the scorecard appender states the philosophy: the writer is "the last line of defense"; anything that reaches the file unvalidated "corrupts the signal irreversibly." The inventory:
Instrument · enforcement inventory — filter by kind
| Mechanism | Kind | What it does |
|---|---|---|
| Write guardguard-work-writes.sh · PreToolUse | hard | Intercepts every Write tool call; if the target is a work item's _meta.json, returns {"decision":"block"} with instructions to use lore work create. Forces managed state through the CLI that maintains indexes. |
| Completion-report validatortask-completed-capture-check.sh · TaskCompleted, exit 2 | hard | When a spec/implement team member finishes, its report is schema-checked: researchers must include ≥1 structured assertion (claim + file + line range + falsifier + significance); workers must include observations and an explicit convention-handling section. Malformed reports are rejected before the lead ever sees them. |
| Scorecard appenderscorecard-append.sh · sole writer | hard | The only sanctioned writer of rows.jsonl. Validates schema version, kind, calibration state, and tier enums; auditor rows claiming a score are rejected unless they carry a file/line/snippet anchor ("grounded-or-nothing"). Readers treat rows that bypassed it as corrupt and exclude them. |
| Judge output schemasscripts/judge-schemas/*.json | hard | LLM judges (reverse auditor, correctness gates) emit JSON validated against draft-07 schemas with additionalProperties: false — drifted or legacy fields are mechanically rejected "even when the prompt already forbids them." |
| Review gatesflag / hold on work items | hard | A flagged or held work item cannot be archived until the gate is released. Comprehension gating, not approval gating — the point is that a human demonstrably looked. |
| Evolve citation gateskills/evolve · Step 5 | hard | A suggestion to mutate a skill template is silently dropped unless it cites qualifying scorecard evidence, a verified contradiction, or a two-run, human-accepted failure cluster spanning ≥3 work items. Additions must carry a sunset clause (metric + threshold + horizon) or they're rejected; removals need none. |
| Judge calibrationcorrectness gates · hard-cal | hard | Assertion and contradiction judges must pass calibration before their verdicts are permitted to drive mutations of the shared knowledge commons. A judge returning >80% "unverified" is flagged as broken. |
| Session-start loaders7-hook SessionStart chain | soft | Inject knowledge, work, threads, pending-capture counts. Pure context — nothing stops the agent ignoring all of it. |
| The 4-condition capture gate/remember · prose | soft | Reusable, non-obvious, stable, high-confidence. Entirely advisory: an agent that captures junk faces no block — only downstream trust decay and curation. |
| Commitment protocolclaude-md/25 · prose | soft | Anti-hedging rules for agents inside protocols ("the protocol is the answer"). Prose all the way down. |
| Pre-compaction reminderpre-compact.sh | soft | Nudges the agent to persist progress before context is compacted. A reminder, not a gate. |
The pattern: hard enforcement guards data integrity (what becomes durable); soft protocol guides behavior (what the agent does). Lore almost never hard-blocks behavior — with one instructive exception that no longer exists.
The enforcement that got deleted
Lore used to have more blocking. A Stop hook — code that runs when the agent tries to end its turn — evaluated every session for uncaptured discoveries via a novelty check, and another one blocked session end if an ephemeral plan hadn't been persisted. Both were retired, in May 2026, with their tombstones left in a docstring: stop-novelty-check.py retired 2026-05-06, check-plan-persistence.py retired 2026-05-26. The system's own instructions file still describes the Stop hook as if it exists — the protocol documentation has drifted from the code, in a system whose entire thesis is detecting drift. (We'll bank that irony for Part V.)
Why it was removed isn't recorded, but the shape of the lesson is easy to reconstruct, because everyone who has wired an LLM-judged blocking gate has learned it: a gate that interrupts the end of every session with a judgment call ("did you discover something worth capturing?") is expensive, slow, and wrong often enough to be infuriating. Blocking enforcement survives only where the check is cheap, mechanical, and nearly-always-right — a JSON schema, a path match, an enum. Judgment-shaped enforcement migrated to the third strategy instead: measurement.
The measurement layer, and the anti-Goodhart architecture
This is the part of lore I haven't seen anywhere else. The system continuously measures its own usefulness, and it is architecturally paranoid about the measurement corrupting the behavior being measured.
Start with the data. Every knowledge delivery — session-start injection or subagent prefetch — is recorded as a packet: an append-only JSONL row listing exactly which entries were handed to which agent, at what render tier (full / snippet / backlink), under what character budget, with each entry's live trust score at the moment of delivery. After the session ends, an assessor reads the transcript and files a verdict per packet: which delivered entries went unused, which were harmful, which needed knowledge was missing, and which retrievals bypassed the packet entirely. Empty deliveries must carry an empty_reason — the schema distinguishes "nothing relevant existed" from "the emitter broke."
Then the rules that keep the measurement honest, each of which exists as an explicit written invariant:
- Agents never see their own scores. Scorecard and packet rows are never loaded into any agent prompt, by any skill, hook, or prefetch path. The scorecards README maintains an audited list of every code path that doesn't read the data. The stated reason: reputation must accumulate across template versions "without contaminating the agents it measures." An agent that knew its score would optimize the score.
- Incentive-hazard signals stay off the scored substrate. Retro tracks things like review-gate dwell time and rubber-stamp detection — but routes them to a journal, never to
rows.jsonl, because (verbatim) putting them where/evolvecould consume them "would create a scoring incentive to suppress flags." Someone thought about what happens when a self-modifying system learns that raising fewer concerns improves its metrics. - One writer per file, schema-checked at the door. So that a downstream reader's filter on
kind == "scored"is, in the README's phrase, "a reliable filter rather than a hopeful one." - Unregistered provenance gets zero weight. Rows citing a prompt-template hash that was never registered are displayed but excluded from all rankings until a human fills in the registry entry.
Trust: a published fold, not a stored score
Individual entries accumulate reputation through the trust ledger — append-only verification events written whenever an agent checks a claim against the code (held / contradicted), a mechanical check runs (pass / fail), or a judge adjudicates. Displayed trust is never stored; it's recomputed on demand by one published pure function over the ledger, so anyone can re-derive any score from the raw events. The fold's weights encode a specific epistemology — negative outcomes weigh exactly double their positive counterparts, because "acting on falsified knowledge costs more than re-verifying held knowledge" — and a saturating map bounds any entry's influence. Try it:
Instrument · the trust fold, live — weights from trust-compute.py
Things to notice: one contradiction (−2.0) outweighs two verifications (+1.0 each) — falsification is decisive, confirmation is incremental. The saturating map means the tenth confirmation moves trust far less than the first: an entry can't buy invincibility with volume. Search then multiplies BM25 relevance by (1 + w·trust), so contradicted entries sink without being deleted. The rank-multiplier shown uses an illustrative w = 0.3.
Closing the loop: evolution under discipline
All of this telemetry exists to feed /evolve, the step where the system edits its own prompts. This is the most dangerous capability in any self-improving system — ACE-style research calls the failure mode context collapse; folk wisdom calls it an agent lobotomizing its own instructions — and lore surrounds it with more ceremony than anything else in the codebase. A template edit requires cited, calibrated scorecard evidence or a failure cluster that appeared in two separate retro runs and was accepted by a human in between (an explicit damper: "a same-session burst of similar retros cannot self-amplify into a binding edit"). Additions expire by default — every added instruction carries a sunset clause naming the metric that would justify keeping it. And each applied edit bumps a 12-character template-version hash, which stamps every subsequent scorecard row, so the next retro can compare template versions like an A/B test. Suggest → gate → apply → measure → repeat.
Step back and the design has a legible shape. Hard enforcement where checks are mechanical and data becomes durable. Prose protocol where judgment is required. Measurement everywhere — but hidden from the measured, quarantined from the incentives, and only allowed to change the system through an evidence-gated, human-paced, self-expiring mutation path. It is, quite literally, a small bureaucracy — in the Weberian sense, not the pejorative one: written records, separated powers, and institutional memory that outlives any individual clerk. Whether the paperwork earns its keep is Part V's question. First: is any of this actually new?
Part IV
Is Any of This New?
Lore against the memory-systems landscape: what's convergent, what's borrowed, and the four or five ideas that appear to be genuinely uncommon.
Agent memory in 2026 is a crowded field, and it helps to sort it into three families before placing lore in it.
The platforms. Letta (né MemGPT) gives agents self-editing "memory blocks" in context plus vector-searched archival storage, and lately a second sleep-time agent that consolidates memory during idle periods. Mem0 runs an automatic extraction pipeline — an LLM distills facts from conversation, then emits ADD/UPDATE/DELETE resolutions against the existing store. Zep's Graphiti builds temporal knowledge graphs where contradicted facts are date-invalidated rather than deleted, with hybrid (embedding + BM25 + graph) retrieval and no LLM calls at query time. LangMem ships memory primitives — semantic/episodic/procedural types over LangGraph storage — and leaves policy to you.
The built-ins. CLAUDE.md and AGENTS.md files: load-everything instruction memory, no retrieval, no verification. Claude Code's auto-memory (2026) has the agent write its own notes to a per-project directory with an index loaded each session and periodic consolidation. Codex grew an equivalent. Cursor shipped auto-extracted "Memories" in mid-2025 and removed the feature months later, telling users to export to rules files — the clearest public signal so far that auto-extracted conversational memory tends to be too noisy to justify its context cost.
The research thread. Generative Agents' memory stream with reflection (2023), Reflexion's verbal self-critique buffers, Voyager's skill library, A-MEM's Zettelkasten notes with LLM-generated links, ReasoningBank's distilled strategy items, and — most relevant here — the self-improving-context work: DSPy/GEPA's reflective prompt evolution, and ACE's finding that monolithic rewriting of an agent's context causes collapse, fixed by itemized delta updates.
Here's the comparison in one table, then the honest accounting.
Instrument · design matrix — lore vs. the field
| System | Substrate | Retrieval | Write policy | Verification | Self-improvement |
|---|---|---|---|---|---|
| lore | Markdown files + append-only JSONL ledgers, per repo | BM25 (FTS5) × trust weight, altitude-filtered; embeddings optional | Gated, sparse (1–3/session); demand-led mining of retrieval misses | core falsifiers, trust ledger, calibrated judges, drift sweeps | Evidence-gated template evolution w/ sunset clauses & A/B by version hash |
| CLAUDE.md / AGENTS.md | One markdown file (hierarchy) | None — loads wholesale | Manual | None | None |
| Claude Code auto-memory | Per-project notes dir + index | Index always; topic files on demand | Automatic, agent-judged | None (docs: "context, not enforced configuration") | Periodic consolidation |
| claude-mem | SQLite, compressed observations | FTS5 lexical | Automatic, every session | None | None |
| Letta / MemGPT | In-context blocks + vector archival | Embedding search | Agent self-editing tool calls | None (sleep-time agent rewrites, doesn't verify) | Sleep-time consolidation |
| Mem0 | Vector store (+ optional graph) | Embedding (+ graph traversal) | Automatic extraction, ADD/UPDATE/DELETE | LLM conflict detection at write | None |
| Zep / Graphiti | Temporal knowledge graph | Hybrid: embedding + BM25 + graph, no LLM at query | Automatic entity/relation extraction | partial bitemporal invalidation of contradicted edges | None |
| LangMem | Pluggable (LangGraph store) | Embedding | Hot-path tools + background consolidation | None (left to developer) | Prompt-optimizer utilities |
"Verification" = does the system have a first-class mechanism for discovering that a stored memory is wrong, beyond overwrite-on-conflict. It's the emptiest column in the field, and the one lore is organized around.
What isn't novel
Be clear-eyed first. Markdown-files-as-memory is the community default (basic-memory, a dozen MCP servers, auto-memory itself). Hook-driven capture and session-start injection is exactly claude-mem's architecture. BM25 over SQLite FTS5 is claude-mem's retrieval too. Categories like gotchas and conventions are folk taxonomy. Two-tier capture-then-organize mirrors every inbox system since GTD. Multi-agent spec/implement pipelines are 2025-era standard practice. If you skim lore's directory listing, nothing looks new; the novelty is concentrated in the governance layer, which doesn't show up in a directory listing.
What appears genuinely uncommon
- Falsifiers as a first-class field. Requiring structured claims to name the condition under which they die — and anchoring them to file/line/snippet-hash so drift is mechanically detectable — imports Popper into agent memory. Zep's bitemporal invalidation is the nearest relative, but it's passive (contradiction discovered at ingest); lore's falsifiers are active — they define a check that sweeps and agents can run. I know of no mainstream system that does this.
- A reputation economy for memories. The trust ledger — append-only verification events, one published pure fold, asymmetric weights, saturation, and never storing the score — treats each memory like a scientific claim with a citation record. Retrieval multiplying lexical relevance by earned trust is a quietly excellent idea: wrong entries sink gradually and recover if re-verified, with full audit trail. Nothing in the platform family has an analog.
- Measurement isolation. The rule that agents never see their own scores, plus the off-band routing of incentive-hazard signals, is an anti-Goodhart architecture for self-improving agent systems. The RL community knows this problem as reward hacking; the agent-memory community mostly hasn't noticed it yet. Lore not only noticed, it wrote the invariant down, audited the non-consumers, and documented why each signal is kept off-band.
- Demand-led capture. Every other system decides what to remember at write time, by salience guessing. Lore additionally mines the previous session's transcript for retrieval misses — searches that returned nothing, followed by the agent laboriously re-deriving the answer with grep and file reads — and turns those into capture candidates. Writing memory where demand was observed, rather than where salience was guessed, inverts the standard pipeline. This is the idea I'd most expect to see cited in a paper someday.
- Altitude-typed retrieval. Scale declaration — refusing to search until the caller states whether it wants implementation detail or architectural principle, on the argument that off-altitude context is actively harmful — has no counterpart I can find. Hierarchical memory exists (GraphRAG communities, A-MEM networks), but supply-side hierarchy is different from demand-side declaration.
- Evolution under discipline. GEPA and ACE evolve prompts from execution feedback, so the loop itself is convergent with published research — lore's contribution is the governance: citation-gated mutations, two-run human-paced dampers, sunset clauses on additions, and version-hash A/B accounting. ACE's "incremental delta updates beat monolithic rewrites" finding is independently mirrored in lore's append-and-supersede posture, which is a nice case of convergent evolution.
One more thing deserves the word, though it's engineering rather than science: the capability-cell adapter model — four support levels per capability per harness, dated evidence for every cell, skills that degrade along documented ladders. As multi-harness agent tooling proliferates, someone will reinvent this worse.
The overall pattern: lore's storage and retrieval are deliberately boring; its epistemology is where the innovation lives. Every other system asks "how do we remember more, better?" Lore asks "how do we keep what we remember honest?" — and builds provenance, falsification, reputation, quarantined measurement, and disciplined self-modification around that question. Whether all that apparatus pays for itself is the last part's business.
Part V
What Could Be Better
An honest critique — complexity, drift, retrieval, enforcement gaps, and the evidence problem — and what lore's design suggests about agent memory in general.
Everything in this part is offered in the spirit lore itself asks for: claims with reasons, checkable against the code.
1. The complexity bill is real, and it's paid in context
Lore's deepest tension is that it spends the very resource it exists to conserve. The retro skill is 852 lines. The CLAUDE.md protocol fragments consume thousands of tokens in every session, including trivial ones. The ontology — packets, scorecards, trust events, evidence tiers, sessions, ceremonies, arcs, ledgers — is the vocabulary of a ten-person platform team, maintained and executed by LLMs whose instruction-following degrades with exactly this kind of length. A system whose thesis is "models don't reliably follow long prose" has, as its main interface, very long prose. The mitigations exist (verbs validate what prose requests; hard gates catch the worst), but the honest question is whether a system one-third this size would deliver two-thirds the value. My guess is yes. The counterargument — that the ceremony exists to generate evidence, and evidence is what lets the system shrink itself safely via retro/evolve — is elegant, but only if the loop actually runs often enough to pay rent.
2. The system doesn't audit its own instructions
The sharpest concrete finding in this investigation: lore's installed protocol text still tells every agent that "a Stop hook evaluates every session for uncaptured discoveries." The Stop hook was retired in May 2026. The falsifier machinery — drift sweeps, contradiction gates, status fields — covers knowledge entries, but the protocol fragments and skill texts are plain markdown with no provenance footers, no falsifiers, and evidently no sweep. The fix is almost poetic: eat the dogfood one bowl deeper. Give every protocol claim that names a mechanism ("a Stop hook evaluates…", "a PreToolUse hook blocks…") an anchor to the code that implements it, and run the existing drift sweep over the instructions themselves. The system already owns every tool this requires.
3. Retrieval is the least ambitious layer
Deliberately boring, as Part IV said — but a few choices look more like debt than thrift. Category filing has no classifier: omit --category and the entry lands in conventions/ by silent default, in a system otherwise allergic to silent anything. Scale filtering runs as a post-hoc Python pass over 3× over-fetched results rather than an indexed predicate. A multi-pool search spawns three Python processes inside a six-second hook budget. And lexical search means an agent asking about "auth" won't find the entry titled "session cookie validation" — the exact scenario the miss-miner then has to detect after the fact. Cheap wins, in order: a tiny classifier (or even the capture-time agent) assigning category; scale as an FTS5 column; hybrid retrieval on by default with the already-implemented cached MiniLM embeddings once a store crosses a few hundred entries; one long-lived search process instead of process-per-query.
4. Capture enforcement regressed to vibes
After the Stop hook's retirement, the write side of memory — the 4-condition gate, the 1–3 captures target — is enforced by nothing at all. The system can still measure capture failures after the fact (that's what the miss-miner and packet assessor do), which is the right instinct, but the loop is open: candidates surface at the next session start and rely on the agent dutifully running /remember. Two closures suggest themselves. First, the assessor's "missing knowledge" verdicts could auto-file provisional entries at low trust — quarantined until an agent verifies them — rather than waiting for a ceremony. Second, the sole-writer invariants that are currently social convention ("no other process may append") could become mechanical: a content-hash chain per ledger, or plain filesystem permissions, would make bypass detectable rather than merely forbidden. And the completion-report validator only fires when a report carries a template-version stamp — a legacy escape hatch that means a sufficiently old prompt bypasses the strongest gate in the system.
5. Measurement-rich, evidence-poor
The uncomfortable empirical observation: the knowledge stores on this machine are nearly empty — a bootstrap work item, zero mature entries, packet rows recording deliveries of nothing. The instruments are extraordinary and the data is thin. That's the normal state of a young system observed mid-construction (and other machines may hold real stores), but it points at the real epistemic risk: lore has never proven that lore works. The apparatus for proving it — packets, matched-task graduation experiments with control arms, template A/B by version hash, an eight-dimension self-test — is all built, which is more than any competitor can say. But until those experiments run at volume, the 4-condition gate, the trust weights (why is a contradiction exactly −2.0?), and the scale taxonomy are well-reasoned priors, not results. The single most valuable next artifact isn't a feature; it's a number: "sessions with lore resolve issues N% faster / with M% fewer re-derivations than sessions without."
6. Memory that doesn't travel
Knowledge lives in ~/.lore/, keyed by git remote — per-machine, per-user. Two engineers using lore on the same repo build two divergent stores, and a fresh laptop starts amnesiac again. The single-writer, append-only, files-only design is practically begging for a sync layer (the store is a CRDT-shaped problem), or simply an opt-in in-repo mode where the commons rides along in version control and arrives with git clone. Team memory, with per-claim provenance and trust — who verified this, on which branch — is where this design would get genuinely interesting, and none of the big platforms can offer it in auditable form.
What this says about agent memory in general
Zoom out from lore and the field has three unsolved problems, and lore is a useful lens on each precisely because it's the system that took them most seriously.
The write problem. When should an agent remember something? Salience-at-write-time is a guess, and the guessers are miscalibrated: capture-everything systems (claude-mem, Mem0) drown in pollution, which is plausibly why Cursor pulled Memories entirely. Lore's two answers — gate hard at write time, then mine observed demand for what the gate missed — are the right shape, and the demand-led half deserves wider adoption: the best signal for what's worth remembering is what an agent had to re-derive.
The staleness problem. A wrong memory retrieved confidently is worse than no memory; the literature keeps finding that stale-but-relevant entries are the hardest failure. Zep timestamps facts; everyone else mostly overwrites and hopes. Lore's package — provenance to a commit, falsifiers that define death conditions, trust that decays on contradiction, entries that sink in ranking rather than vanish — is the most complete answer anyone has shipped, and its cost profile (append-only ledgers, one pure fold, no LLM at read time) is modest. If one lore idea escapes into the mainstream, it should be this one.
The adherence problem. Memory is advice, and models take advice probabilistically. The field's honest state is that nobody can make an agent reliably act on what it knows; even Anthropic's docs describe memory as "context, not enforced configuration." Lore's contribution is a taxonomy proven in its own code: block mechanically where checks are cheap and data becomes durable; persuade where judgment is required; measure everything else, and keep the measurements away from the measured. That last clause is the one the coming wave of self-improving agent systems will most need and least want to hear.
The meta-lesson I take from reading this codebase is that agent memory is not a storage problem — vector databases solved storage years ago — but an epistemology problem: what does this system believe, on what evidence, and what would change its mind? Lore is what happens when someone designs for those questions from the start: memories with citations, reputations, and death conditions; instruments that watch the instruments. It's over-built the way a first cathedral is over-built, and its docs have already drifted once, and it has not yet proven its own value — its own retros would say all of this, which is rather the point. The bet underneath it all is that as models get smarter, the scarce resource isn't intelligence but trustworthy accumulated context — and that bet looks better every year.