Building Shared Memory for AI Agents in Notion

As software engineering changes, tribal knowledge is increasingly concentrated not only in a single person's mind, but in a single agent session. Here at Notion, we kept having to manually extract experiential learnings as skills or documentation and share them with the team in-repo. But that doesn’t scale. Even as agents got really good at inferring or discovering information in source, this experiential knowledge—which isseparate from user preferences—remained a tangible gap. The inverse is also true: agents would often discover information that is tangential to their current workstream but helpful, and those tasks, refactors, and todos would later get lost (especially if it’s an unattended session!).

We came to realize that every org has its own lore and must be facing similar problems. We decided it was time to fix that with Notion.

Lore is the tool we built for that gap: shared, persistent memory for agents, backed by Notion. It is open source under the MIT license at github.com/makenotion/lore.

The short version is that conversations, decisions, follow-up tasks, procedures, and durable facts become Notion pages that a later session can read. Claude Code, Codex, Cursor, or any MCP host can use the same vault, which is a Notion page with embedded databases. Context can survive /clear, a branch switch, or a handoff to someone else on the team.

This matters because today most agent memory is either too private or too temporary. A scratch file lives on one laptop. A prompt appendix disappears when the context window clears. A transcript is not really knowledge unless a future agent can find the specific thing it needs, see where it came from, and use it without dragging the whole session along for the ride.

We wanted something more boring and more useful: a shared place for the parts of a session that should outlive the session.

A Lore vault is a Notion page with five databases:

They chain together as Projects -> Topics -> Memories -> Entities -> Facts. A fact can point back to the memory that produced it; a memory can hold the richer page body; an entity gives later queries a stable name to attach to. We did not want only a vector pile, and we did not want only a wiki. The useful shape is both: prose for humans and structure for agents.

The same service layer powers all of the surfaces:

Agents use Lore through MCP tools like lore-context, lore-memory, lore-fact, lore-decision, lore-task, lore-query, lore-procedure, lore-pinned, and lore-project. Humans get the same vault through the CLI: lore search, lore status, lore conflicts scan, lore debt scan, and so on. Hooks make the normal path hands-off: wake up with relevant context, work, then save the things worth keeping.

We backed it with Notion because Notion is where the team already lives. Every memory is a page you can open, read, correct, or delete. Version history is already there. Permissions are already there. The vault does not become a hidden sidecar that only an agent can inspect.

One implementation detail ended up being important: Notion API rate limits are per-token. If a team shares one integration token, every agent and every operator share the same bucket. Lore is built around per-user auth instead. External users bring a Notion Personal Access Token; internal users can use ntn. Shared memory should not require shared quota.

One bad version of a memory system is a junk drawer with an API. Lore treats maintenance as part of the product.

Facts carry provenance, confidence, and validity windows. Decisions record the choice, the reasoning, the alternatives, and the affected surface. Follow-up work goes through lore-task instead of living as a forgotten TODO in a transcript. lore conflicts scan looks for memories in tension and asks the agent to classify the relationship with a fixed vocabulary: supersedes, scoped, conflicts_with. lore debt scan looks for orphaned facts, duplicates, stale governance, topic sprawl, weak summaries, and other memory debt.

That might sound fussy, but the benchmark results convinced us that it is necessary. Memory helps when it is available, specific, and retrieved at the right time. It can also distract the agent when it is vague, redundant, stale, or applied outside the task boundary.

We did not want to launch this with "it feels better" as the evidence. We have two relevant benchmark tracks right now, and they answer different questions.

The first is SkillRet, which asks whether an agent can use Lore as a read-only skill-retrieval system. SkillRet's public test split has 4,997 queries, 6,660 skills, and 8,347 relevance judgments. We import the skills into a persistent Notion-backed Lore eval vault as procedure memories, then give a Codex eval agent read-only Lore instructions plus search and expand tools. The agent cannot create, update, archive, mine, autosave, or otherwise mutate the vault. To pass, it has to use Lore, surface the expected memory, expand it, select the right SkillRet target, and apply that target in the answer.

The checkpoint we trust most right now is chunk 001 of a deterministic 5×500 sample plan, generated on June 8, 2026:

That number is useful because it separates the layers. Tool refusal was not the problem: Lore was used in every row. Mutation was not the problem: there were zero write attempts. The failures were more concrete: 41 cases where the target never surfaced, one case where it surfaced but was not expanded, and 38 cases where it was expanded but not selected or applied.

That tells us where to work. The next gap is not “Can we convince the agent to call memory?” It is retrieval headroom and candidate comparison.

We also ran raw SkillRet retrieval diagnostics. The offline keyword control got Recall@10 of 17.51% over the full 4,997-query split. A Notion AI search lane over 3,250 queries got Recall@10 of 23.08% with zero mechanism failures. Those are useful substrate checks, but they are not the headline claim. Raw search recall is not the same thing as an agent using a memory vault correctly.

The second benchmark track is our longitudinal model-hard eval, which asks a harder question: when the right memory is available, does it improve actual agent work?

That harness runs real OSS repos at pinned SHAs with hidden patched-command verifiers. The public claim we trust is the paired no-memory versus seeded-lore comparison. seeded-lore means the agent is handed a curated durable memory: the kind of thing Lore is meant to preserve once a team has learned it.

The paired result is the honest version:

That is the cleanest agent-lift evidence we have: when the right memory exists and is made available, it produces a statistically significant correctness lift. On tasks hard enough to defeat the no-memory agent, seeded memory recovered about 46% of the failures.

That does not mean memory magically fixes agents. It means available, relevant memory changes outcomes. That is the first product claim we wanted to earn.

We also reviewed memory quality in a production Mail vault, because a shared vault only helps if the contents stay usable. Roughly 55–60% of conversation/note memories were experiential and precise enough to keep, 15–20% were semantic near-duplicates, 8–12% were inferable noise, 3–5% were session narration stored as notes, and about 13% had null synopses.

So the benchmark story is narrow, but useful:

• When the right memory is available, agents can use it, and we see real lift

• Retrieval quality and candidate selection are now the main SkillRet bottlenecks

• Memory quality work matters: formation has to reject inferable, vague, duplicate, or session-narration notes before they become future context

That is a much better problem than the one we started with.

Lore is MIT-licensed on GitHub: github.com/makenotion/lore. It is a 20% project, built because we wanted it rather than because it was on a roadmap. We open-sourced it as a starting point, not as a claim that our workflow is the only one worth using.

Install it from npm:

bash npm install -g @notionhq/lore lore --version

Then create a Notion Personal Access Token, point a .lore.yaml at a vault page, and wire it into your assistant. The README covers joining a shared vault and setting up Claude Code, Codex, or Cursor.

After that, the normal path should be boring: restart the assistant, start working, and let the wake-up and autosave hooks do their jobs.

Retrieval is where most of our attention goes right now. A memory the agent cannot find when it needs it might as well not exist. The next eval work is to run more of the 5×500 SkillRet plan, improve over-fetch and reranking, and keep tightening the quality gates around what gets saved.

If you build on Lore, fork it, or take it somewhere we did not expect, we want to see it. Issues and pull requests are open at github.com/makenotion/lore/issues.