MCP Memory: Persistent AI Agent Memory with Knowledge Graphs

By default, your AI agent forgets everything between sessions: the structure of your knowledge base, the insights you reached together, the operational lessons it learned the hard way. The InfraNodus MCP server fixes this with persistent, graph-based memory — and because different kinds of memory should behave differently, it serves them through different groups of MCP tools, which the model invokes depending on the layer a task touches.

The layers follow the AI memory stack methodology: content graphs for what your files contain, insight memory for what you realized in conversations, and agent learnings for what the model learned operating in your project. This page maps each layer to the MCP tools that write it, update it, and read it back — and to the skills that orchestrate those calls.

Why Graph Memory Instead of a Memory Bank

Most MCP memory servers store notes — files the model can re-read later. That preserves content but not structure. Graph memory stores the relations: every remembered statement links the concepts it mentions, so the memory can be traversed (GraphRAG follows connections outward from your query instead of ranking similar chunks) and measured (which topics has the memory formed, which concepts hold them together, which areas never connect).

That last capability is the one a pile of memory files cannot have: the memory knows what it is missing. Gap detection works on remembered knowledge the same way it works on any knowledge base — and the gaps in what you and your agent have accumulated are where the next question comes from.

Layer 1 — Content Graphs: Memory of What Your Files Contain

The base layer of persistent memory is generated from your material — a vault, a repository, a folder of documents. The InfraNodus skill extracts it into saved knowledge graphs, records them in a manifest, and adds routing rules to CLAUDE.md so the model knows which graph answers which kind of question.

Tools the model invokes to write and maintain this layer:

• create_knowledge_graph — save extracted content (or an agent-written digest) as a named graph; repeated calls to the same graph append.
• delete_statements — remove one source file's statements by category before re-uploading its new version, so edits replace rather than duplicate.
• update_statements — relabel or correct statements in place (a renamed file, a fixed line) without touching their ids or dates.

Tools it invokes to read the layer back:

• retrieve_from_knowledge_base — GraphRAG retrieval: content questions answered from the statements, with graph traversal building the context.
• analyze_existing_graph_by_name — structure questions: topics, clusters, influential concepts.
• generate_contextual_hint — a lightweight structural overview injected as context before answering broad questions.
• generate_content_gaps — direction questions: what the remembered content is missing.
• generate_responses_from_graph — advice generated from the graph in its own voice.

Layer 2 — Insight Memory: What You Realized in Conversations

Realizations you reach while working with the model — a new connection between your concepts, a contradiction a structural analysis surfaced — evaporate when the session ends unless something records them. The insight layer uses the server's dedicated memory tools:

• memory_add_relations — save short relational statements, each linking at least two [[wikilinked]] concepts, with an ISO timestamp per statement. The timestamps turn the memory graph into a timeline of your thinking.
• memory_get_relations — recall everything previously concluded about a concept, from any connected client.

The convention that drives it is a marker-managed block in CLAUDE.md, installed by the InfraNodus skill when you opt in at its register step (--register-project --with-memory): at the end of a substantive session, the model distills the insights you arrived at, shows them, and calls memory_add_relations only on your approval. Nothing is written silently.

Layer 3 — Agent Learnings: What the Model Learned Operating in Your Project

An agent working in the same project keeps rediscovering the same traps — which folder is excluded, which call fails right after a graph is created, what chunk size an upload tolerates. The Project Learnings skill persists these through three dedicated tools:

• enable_project_learnings — creates the per-project learnings graph, only on your explicit request; nothing can be written before this.
• add_project_learnings — proposes typed learnings (trap, convention, workflow, decision, question, approach) as a dry run; writes only after you approve the batch.
• get_project_learnings — read at the start of a substantive task: the most relevant learnings for the task at hand, the areas that have accumulated knowledge, and the gaps.

This is the one layer the model reads automatically — which is safe precisely because it holds operational facts about the project, never ideas and never anything about you.

Which Tool for Which Memory

How the model routes a task to a layer and its tools:

The separation is what lets one MCP server hold all three kinds of memory without them contaminating each other: the same model, in the same session, reads learnings silently, queries content graphs on demand, and asks before it writes an insight.

Install It: the Skill, or a CLAUDE.md Block

The easiest path is the InfraNodus skill: when it builds your content graphs it offers to install the memory conventions into your project's CLAUDE.md too.

Install the InfraNodus Skill

/plugin marketplace add infranodus/skills
/plugin install infranodus@infranodus-skills

npx skills add infranodus/skills --skill infranodus -g -a claude-code -y

$skill-installer install the infranodus skill from https://github.com/infranodus/skills

npx skills add infranodus/skills --skill infranodus -g -a codex -y

npx skills add infranodus/skills --skill infranodus -g

If you are not using the skill, add the instructions to CLAUDE.md yourself. A template that covers all three memory graphs — adapt the project name and drop the layers you don't use:

## Project Memory (InfraNodus MCP)

Graphs in the user's InfraNodus account hold this project's accumulated
knowledge — keep them updated:

- **`learn-<project>`** (agent learnings): at the start of a substantive
  task, call `get_project_learnings` (project `<project>`) with the task
  as prompt; at the end, propose new traps / decisions / workflows via
  `add_project_learnings` — show the batch in chat for approval (the
  dry-run dialog may time out in some clients; keep statements under
  400 chars).

- **`<project>-insights`** (insight memory): at the end of a substantive
  session, distill the USER's new realizations — not agent mechanics,
  not file content — into short relational statements, each with at
  least two `[[wikilinked]]` entities and an ISO 8601 timestamp; show
  them and save on the user's OK via `memory_add_relations`. Recall
  earlier conclusions with `memory_get_relations`. Zero insights is a
  normal outcome — do not pad.

- **`<project>-memory`** (concept map, optional): the project's core
  concepts and architecture as relations. Query with
  `memory_get_relations`; when the architecture or concepts change,
  append updated statements via `memory_add_relations` with explicit
  `[[wikilinks]]` and a category per statement (e.g. concept / source /
  pipeline / platform).

The block does the routing for the model: which graph to read at the start of a task, which to write at the end of a session, and the approval gate on every write. Everything else — the tools themselves — comes from connecting the MCP server.

One Memory, Every Client

Because the memory lives in your InfraNodus account behind the MCP protocol rather than inside one application, it is client-independent: a graph written from Claude Code is readable from Claude Desktop, ChatGPT, Cursor, an n8n automation, or a local agent. Your agent's memory is not locked to the tool you happened to use that day — and you can inspect, edit, or delete any graph directly in the InfraNodus interface, because agent memory you cannot see is agent memory you cannot trust.

Set It Up

• The AI Memory Stack methodology
• MCP Tools Catalog
• InfraNodus skill (content graphs)
• Project Learnings skill (agent learnings)
• LLM Wiki skill (curated pages)

FAQ

Can an MCP server give my AI agent persistent memory?

Yes. The InfraNodus MCP server stores memory as knowledge graphs in your account: content graphs generated from your files, a timestamped insight memory the model writes with your approval, and an append-only learnings graph agents read at the start of a task. Any client connected through MCP reads and writes the same memory.

Which MCP tools handle which kind of memory?

Content graphs: create_knowledge_graph to write, delete_statements / update_statements to maintain, retrieve_from_knowledge_base and the analysis tools to read. Insight memory: memory_add_relations / memory_get_relations. Agent learnings: enable_project_learnings / add_project_learnings / get_project_learnings. The model picks the group based on which layer the task touches.

How is this different from a memory bank or file-based memory server?

File-based memory stores notes the model can re-read. Graph memory also stores the relations between concepts, which makes it traversable (GraphRAG) and measurable — the memory can report its own topics, hubs, and gaps, which a pile of files cannot.

Does the model decide on its own what to remember?

No. Insight memory and agent learnings are proposed and saved only after you approve the batch; the learnings graph must be explicitly enabled per project first. Content graphs are generated from your files deterministically. Operational knowledge may be loaded automatically; intellectual knowledge stays reviewable.

What counts as long-term memory for an LLM here?

Anything that survives the session and is reachable through a tool call: the structure of your knowledge base, the approved insights with their timestamps, and the accumulated agent learnings. Each session starts by reading the relevant layer instead of re-deriving it — long-term memory rather than a longer context window.