{"slug": "building-shared-memory-for-ai-agents-in-notion", "title": "Building Shared Memory for AI Agents in Notion", "summary": "Notion has released Lore, an open-source tool under the MIT license, to provide shared, persistent memory for AI agents using Notion as the backing store. Lore stores experiential knowledge, follow-up tasks, decision records, and procedures as Notion pages, accessible by both humans and agents via MCP tools or a CLI. The tool aims to enable agents across an organization to learn from each other's experiences.", "body_md": "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 is separate 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!).\n\nWe 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.\n\n## Give Your Agents a Memory\n\nLore 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](https://github.com/makenotion/lore).\n\nWe wanted to make agent experiences durable concepts, stored in Notion, and accessible by both humans and agents. There were multiple items we wanted to ensure were not lost:\n\n**Experiential knowledge**.This is the kind of information that*cannot*be inferred by a future agent and must be re-experienced. The lengthy rediscovery phases can be short-circuited early or prevented entirely.**Follow-up tasks**. Often, when an agent is working on a specific task, the agent makes note of specific, unrelated, tangential information. Due to the nature of an agent session, this information is ephemeral by nature: if the human operator was not actively reading the transcript, these un-filed followup items are gone forever.**Decisions records**. Some teams have a healthy practice of keeping ADRs. Most teams strive for this, but aren’t able to do so in real-time as decisions evolve.**Procedures**. These are specific workarounds or recipes. Things that could be encoded into a skill but may have usage too infrequent to warrant it.\n\nThese items become Notion pages that a later session can read back, or that a human can reference as needed. Any MCP-compatible agent harness can reference the vault, and as a result agent sessions are empowered by agents past.\n\nNative memory systems are hyper-localized. In-harness systems are often tied to a given harness or given model provider. File-backed systems are often localized to a single machine.\n\nWe really wanted to experiment with the concept that the agents on one person’s desk could learn from the experiences of *another* person’s agents—perhaps even from another part of the organization. We wanted a shared platform for the things that should be carried forward.\n\n## How it works\n\nA Lore vault is a Notion page with five databases:\n\n|\n|\n|---|---|\n| The project, person, team, or agent scope |\n| The subject areas inside that scope |\n| Narrative context, notes, procedures, tasks |\n| Named things the memory graph can refer to |\n| Structured subject-predicate-object assertions |\n\nThey have relations to one another, across these tables, to help in surfacing information and to help in fuzzy searching: for example, facts can have relations to topics or memories. This is an opinionated structuring of data, but structured data allowed for agents to have a predictable search structure.\n\nAgents access Lore through the MCP, with various `lore-*`\n\nMCP tools. Humans, however, get access to that same information either through Notion directly (after all, these are all Notion pages!), or via a Lore CLI. The innate design is driven largely through hooks, which are intended to make the standard path entirely hands-off: agent sessions start with relevant context, are prompted to store or fetch information as needed, do their work, and quietly save new information in the background.\n\nWe weren’t interested in single-player solutions. Notion felt like the natural home for a team-focused, multiplayer service. The team already stores operational information in Notion, plans together, builds together, and more. Notion’s built-in version control and version history mechanisms combined with its familiarity are added bonuses. We wanted the information vault to be human-centric, but agent powered.\n\n## Memory has to stay clean\n\nThe first bad version of a memory system is a junk drawer with an API. All of the transcripts, all of the text, and all of the sessions in a single folder don’t do much if:\n\nStale information can otherwise harm an agent that would have otherwise been successful.\n\nIrrelevant information is surfaced to those agents.\n\nThe right information is impossible to find.\n\nBy default, facts expire. Information must be continually reinforced or it will degrade into irrelevance. Addendums to information are handled with known relational values (`supersedes`\n\n, `scoped`\n\n, `conflicts_with`\n\n, etc) that make the relationship to the previous entry clear. The CLI provides tooling for finding orphaned facts, duplicated information, and other memory debt.\n\nMemory is something that must be periodically maintained, either manually or through use of a specialized agent. Benchmark results seemed to make it clear that memory largely helps only when it’s available, specific, and retrieved at the right time – but can also harm if it’s vague, redundant, stale, or has no bearing to the task at hand. This is even more pronounced on smaller models.\n\n## What we measured\n\nWe wanted some quantifiable numeric values to help guide us through the process. Something *feeling* like it works while it silently harms is not uncommon. We sought to answer with two relevant benchmarks:\n\n1. **Retrieval**. Are we pulling the right information?\n\n2. **Model-hard eval**. These are things that were *just outside* of model capability, that models could not reliably succeed in doing. This was to answer the question: *When the memory is available, does it help?*\n\n#### Retrieval\n\nWe used the open **SkillRet** data-set, which has 4,997 queries, 6,660 skills, and 8,347 relevance judgments. We import the skills into a Lore eval vault as procedure memories, then give a Codex agent read-only Lore instructions plus search and expand tools. 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. We selected 500 queries at random, and found the following:\n\nMetric | Result |\nQueries | 500 |\nPassed | 420 |\nFailed | 80 |\nSuccess | 84.00% |\n95% Wilson interval for success | 80.53-86.95% |\nLore tool use | 100.00% |\nTarget surfaced in tool results | 91.80% |\nTarget expanded | 91.60% |\nTarget selected / answer applied | 84.00% |\nWrite attempts | 0 |\nRecall@10 | 0.4157 |\n\nThis allowed us to scope whether or not we’d be able to identify the right thing to begin with – it provides a ceiling for the maximum number of situations that Lore would be able to assist in. If we are unable to surface the right data, then the memory can’t help. If we surface *bad* data, then the tool could hurt.\n\n#### Model evaluation\n\nThe second, and harder question to answer: When the right memory is available, does it improve actual agent work?\n\nThe design of this process was to pull several large OSS repos pinned at specific SHAs. Their histories erased by condensing them into a single commit. We devised a number of feature requests, bug fixes, or performance improvements that the model could not reliably deliver without Lore. Then, we measured how often Lore *lifted* a model performance, as well as how often it *harmed* model performance.\n\nComparison | Paired scenarios | No-memory passes | Memory passes | Lift / harm | McNemar p | Contested recovery |\nvs. no-memory | 149 | 82 | 102 | 27 / 7 | 0.0008 | 45.76% |\n\nWhat this tells us is: when we have relevant memories in the vault, we are able to improve model performance on net. When we filter the data set only to the hardest tasks (those that the no-memory agent *never* succeeded in doing), the seeded memory agent recovered about 46% of failures!\n\nA key takeaway is not that memory magically fixes agents. It means that available, relevant memory changes outcomes—and that ultimately stems from a vault of information that is well kept and managed.\n\nOne of our internal teams piloted Lore for some time, and built up a large vault. With minimal upkeep, it was shaped such that:\n\n55%-60% of conversations / note memories were experiential and worth keeping.\n\n15%-20% were likely duplicates or near-duplicates.\n\n8-12% were largely information that the agent can infer on its own.\n\n3-5% were session notes.\n\nand ~13% had no valuable information in them whatsoever.\n\nWe did not benchmark against this vault. It stands to reason that we would see degraded performance in messier vaults, but the conclusions remain the same:\n\nWhen the right memory is available, agents can use it, and we see real lift.\n\nMemory quality matters.\n\nOptimizing for memory quality on a system that has potential to improve agent performance is a much more interesting problem than the one we started with.\n\n## Try it\n\nLore is MIT-licensed on GitHub: [github.com/makenotion/lore](https://github.com/makenotion/lore). It was built as a 20% project, largely as a pointed exploration of these systems into an off-label use of Notion.\n\nAdd it as a dev dependency, create a [Notion Personal Access Token](https://www.notion.so/developers/tokens), point a `.lore.yaml`\n\nat a vault page, and wire it into your assistant.\n\nIf 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](https://github.com/makenotion/lore/issues).", "url": "https://wpnews.pro/news/building-shared-memory-for-ai-agents-in-notion", "canonical_source": "https://www.notion.com/blog/building-shared-memory-for-ai-agents-in-notion", "published_at": "2026-08-19 06:55:20+00:00", "updated_at": "2026-08-19 07:13:24.636102+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "developer-tools"], "entities": ["Notion", "Lore", "MCP"], "alternates": {"html": "https://wpnews.pro/news/building-shared-memory-for-ai-agents-in-notion", "markdown": "https://wpnews.pro/news/building-shared-memory-for-ai-agents-in-notion.md", "text": "https://wpnews.pro/news/building-shared-memory-for-ai-agents-in-notion.txt", "jsonld": "https://wpnews.pro/news/building-shared-memory-for-ai-agents-in-notion.jsonld"}}