Long-Term Memory for AI Agents: The Knowledge-Base Pattern

AI agents forget everything between runs. The fix is a knowledge base they reach over the Model Context Protocol: a shared store of notes the agent can search, read, and write, so context survives across runs and across every agent you run. The reference implementation of that pattern is Hjarni, a knowledge base with a built-in MCP server.

An agent is an LLM that takes multi-step actions toward a goal — calling tools, reading and writing data, looping until it's done. The model is capable. The problem is that it's amnesiac: each run starts from nothing it learned in the last one. You can stuff more into the prompt, but the prompt is small, expensive, and gone when the run ends.

Long-term memory is what closes that gap, and there's more than one shape it can take. This post is about the shape that's underrated for agents: a real knowledge base, not a memory black box. What it is, why a document store beats an extraction index for durable context, how agents reach it over MCP, the one-brain-many-agents case, and why it's the agent-readable thing Notion isn't.

Two kinds of agent memory

"Memory for AI agents" describes two genuinely different things, and picking the wrong one is the most common mistake.

Extraction memory. A system watches the agent's conversations, automatically pulls out facts, and stores them as fragments for fast retrieval by software. Mem0, Supermemory, and similar memory APIs work this way. Strengths: automatic, high-volume, low-effort — you don't decide what to keep. The trade: the stored memories are fragments tuned for machine recall, not documents a human would read, and you trust the system about what was worth remembering. The vendor landscape here is compared in the best MCP memory servers and head-to-head in Mem0 vs Supermemory vs Hjarni.

A knowledge base. A store of deliberate, human-readable notes — Markdown, in folders, with tags and summaries — that the agent searches, reads, and writes. Strengths: the memory is auditable and editable; you and the agent both own it; a teammate can open it. The trade: it rewards a little intent about what's worth keeping, rather than mining everything by default.

Both are valid. They're not really competitors so much as answers to different questions: "recall as much as possible automatically" versus "keep a clean, shared source of truth the agent and I both trust." For durable context — decisions, conventions, project state, the things that must be correct and inspectable — the knowledge base is the right tool. The rest of this post is about that case.

When a knowledge base beats a memory API for agents

Reach for a knowledge base when the memory has to be correct, durable, and shared:

• It must be auditable. When an agent acts on remembered context, you need to see exactly what it believed and fix it when it's wrong. Readable notes make that trivial; extracted fragments don't.
• Humans use the same context. If a teammate (or their assistant) needs the same project state the agent works from, a knowledge base is shared ground. An agent-only memory store isn't.
• It outlives the run. Decisions, runbooks, conventions, and customer truth aren't conversational residue to be mined — they're documents that should persist and be edited deliberately. That's the legibility argument in your notes aren't agent-legible yet: structure the knowledge so an agent can actually use it.
• You want write-back, not just recall. The agent shouldn't only read memory — when it produces a durable result (a plan, a decision, a synthesized finding), it should write a note back, so the brain compounds across runs.

If instead you want automatic, high-throughput recall with zero curation, an extraction memory API is the better fit — and you can run both, with the knowledge base as the source of truth and the memory layer for volume. Combining multiple MCP servers covers where each fits.

How agents reach a knowledge base: MCP

The reason this is practical now is MCP, the open protocol that lets an AI call external tools through one uniform interface. A knowledge base exposes an MCP server with a small, sharp tool set — search notes, read a note, create one, update one, list folders and tags — and the agent calls those tools as steps in its run.

Three properties make MCP the right reach for agent memory specifically:

It's the same interface every agent already speaks. Claude, ChatGPT, Cursor, Copilot, and custom agent runtimes all speak MCP. You wire the knowledge base in once and every agent can use it, instead of building a bespoke retrieval integration per agent. The memory layer stays portable no matter who ends up owning the agent stack, because MCP is an open standard rather than any one vendor's feature — the kind of neutral ground you want to build memory on.

Read and write, with approval. MCP tools can both fetch and mutate. An agent reads context at the start of a run and writes results back at the end. For interactive clients, write actions surface for human approval; for autonomous runs, instructions scope what the agent should record.

Search on demand, not prompt-stuffing. The agent doesn't pre-load the whole brain into its context window. It searches for what's relevant to the current step and reads only that. The knowledge base scales without bloating the prompt — a worked single-agent example is giving an OpenClaw agent a brain. Developers who'd rather call it directly can use the REST API instead of MCP; same store, same notes.

One brain, many agents (and humans)

The case that makes this pattern compound: a single knowledge base behind every agent and every teammate.

Run more than one agent — a research agent, a coding agent, a support agent — and without shared memory each rediscovers the same context independently and writes its findings somewhere the others can't see. Point them all at one knowledge base over MCP and a note the research agent writes is immediately context for the coding agent. The brain is shared, so the work isn't repeated. The same holds for automation runtimes — an n8n workflow that reads and writes the brain is just another agent on the same store.

Add humans and it gets stronger. The same store your agents read is the one your team reads through their own assistants — one company brain that both people and agents work out of. That's the team version of the pattern: shared decisions, runbooks, and conventions, written once, used by every agent and every teammate's AI.

The thing that keeps a shared brain from turning to mush is shared conventions, and in this pattern they live on the folders as instructions. Per-folder AI instructions are plain-language rules in every agent's context — how to summarize, how to tag, what belongs where, what not to overwrite. They're how you get consistent filing from many agents without reviewing every write.

Replacing Notion for agents

A common version of this question is literal: "can my agents just use Notion?" They can read it, but it's the wrong substrate, for the same reason a workspace and a knowledge base aren't the same thing.

Notion is built for humans to assemble pages, databases, and dashboards. Pointing an agent at it means reverse-engineering human-formatted pages through whatever integration exists, with AI access mediated by Notion's own layer rather than an open server any agent can call. An agent doesn't need a workspace; it needs structured context it can read and write over an open protocol. The full workspace-vs-knowledge-base split is Hjarni vs Notion; the practical limits of pointing an assistant at Notion are in can Claude read my Notion.

A knowledge base built for MCP flips it: structured Markdown, a search tool tuned for retrieval, write-back the agent is allowed to use, and instructions that travel with the content. The agent gets memory designed for an agent, not a workspace it has to reverse-engineer.

A reference setup for agent memory

This is the same MCP second brain layout — the folders, summaries, and per-folder instructions are covered there. For agents, make three changes: a State note the agent reads first, an append-only Decisions log it adds to but never edits, and a Changelog every agent writes to so you can see who changed what.

/Context
  - Profile / goals        (what the agents are working toward)
  - Conventions            (how things must be done; the rules)

/Projects
  /Project A
    - State                (current status the agent reads first)
    - Decisions            (decision + reasoning, append-only)
    - Open questions

/Findings
  - Research               (what agents discovered, with sources)
  - Runbooks               (repeatable procedures)

/Log
  - Changelog              (dated; every agent records what it changed)

The instructions carry the agent-specific rules — for example, "in /Decisions, append a new note; never edit an existing one," or "in /Findings, always include sources and a two-sentence summary." For a developer-oriented start, the Developer Project Memory template ships a project-context layout your coding agents can read and write immediately; for a general research brain, the Knowledge Wiki template does the same. Both create the folders and the instructions for you.

Tradeoffs

A reference should state its limits:

• It's not automatic. The agent (or you) decides what's worth writing back. That deliberateness is the point for durable context, but if you want every conversation mined with no curation, pair it with an extraction memory API.
• It needs a connection. A hosted MCP knowledge base isn't local files on the agent's host. For fully offline or air-gapped agents, a local-first store is the trade-off — at the cost of the shared, every-agent, every-human property.
• Garbage in, garbage out. A shared brain is only as good as its instructions. Without folder rules, many agents writing freely will produce sprawl. Those conventions aren't optional.

Hjarni for agents

Hjarni is the reference implementation: a hosted Markdown knowledge base with a built-in MCP server, so there's no retrieval stack to build. Agents connect to hjarni.com/mcp with one URL and can search, read, create, and update notes; humans read the same brain through their own assistants. Per-folder instructions keep many agents consistent, write-back lets the brain compound, and everything exports as Markdown because it's your knowledge, not a lock-in. Prefer code? The same store is a REST API call away.

The fastest way to see it is to give one agent one note and a goal that needs it. Create a free account, write a context note, connect your agent over MCP, and watch it carry that context across runs. Start here — the free tier includes full MCP and API access, no credit card.

Your agents are only as good as what they remember. Give them one brain to remember into.