Building Cross-Project Memory for MCP with Persistent Knowledge Graphs

---

title: "The one thing nobody tells you about MCP: your agents forget everything between projects" published: false

tags: [ai, programming, tutorial, opensource]

Last week, we watched an agent solve the same problem three times.

First in a docs repo. Then again in an internal tool. Then again in a customer integration project.

Same API pattern. Same auth edge case. Same fix.

The agent wasn’t dumb. It just had no memory outside the current context window.

That’s the part people gloss over when they talk about MCP: connecting tools is great, but if every new project starts from zero, your agents stay expensive, repetitive, and weirdly inconsistent.

A good fix is cross-project memory backed by a persistent knowledge graph.

Not “store every prompt forever.”
Not “dump embeddings in a vector DB and hope.”

I mean a simple system where agents can remember:

• what entities exist
• how they relate
• what worked before
• which decisions were intentional
• and what should not be repeated

The problem in one sentence

Most MCP setups are great at tool access, but weak at durable memory.

So your agent can call GitHub, Slack, Postgres, and docs tools… but it still forgets:

• which service owns billing
• why a migration was rolled back
• which repo already solved OAuth token refresh
• who approved a risky change
• what “customer workspace” means across teams

That’s not just inefficient. It becomes a security and reliability problem.

If an agent can act across systems, it also needs context that survives a single chat session.

What a persistent knowledge graph gives you

A knowledge graph is just a structured memory layer:

• nodes = repos, services, people, tickets, decisions, incidents
• edges = depends on, owned by, approved by, supersedes, fixed in

That gives agents something better than raw text retrieval.

Instead of asking:

“Find anything about auth”

…you can ask:

“What service handles auth for Project B, and has any repo already implemented token delegation for it?”

That’s a much more useful memory model for MCP workflows.

Here’s the basic shape:

             +------------------+
             |   Incident #482  |
             +------------------+
                      |
                   fixed in
                      |
                      v
+---------+    depends on    +-------------+
| Repo A  | ---------------> | Auth API    |
+---------+                  +-------------+
     |                              |
  owned by                      approved by
     |                              |
     v                              v
+----------+                  +-------------+
| Team IAM |                  | Alice       |
+----------+                  +-------------+

The trick is keeping this graph persistent and queryable across projects, not rebuilding it every session.

A practical pattern that works

You don’t need some giant research-grade memory architecture.

A useful version looks like this:

1. Ingest MCP events and artifacts
   Tool calls, PRs, docs, tickets, approvals, incidents.

2. Extract entities + relationships
   Example: Repo A -> depends_on -> Auth API

3. Store canonical facts
   Keep them versioned and attributable.

4. Query the graph before tool execution
   Ask for relevant context before the agent takes action.

5. Write back outcomes
   Did the change work? Was it approved? Did it regress later?

That last part matters. Memory shouldn’t just store plans. It should store results.

One runnable example

If you want a tiny local prototype, you can model graph memory with a simple JSON-backed store.

npm install graphology

const Graph = require("graphology");

const graph = new Graph();

graph.addNode("repo:billing-web", { type: "repo" });
graph.addNode("service:auth-api", { type: "service" });
graph.addNode("decision:rfc8693", { type: "decision", status: "accepted" });

graph.addEdge("repo:billing-web", "service:auth-api", { type: "depends_on" });
graph.addEdge("service:auth-api", "decision:rfc8693", { type: "implemented_by" });

console.log(graph.neighbors("service:auth-api"));

That’s obviously minimal, but it shows the core idea: store relationships explicitly so your agent can reason over them later.

In production, you’d usually pair this with:

• a graph DB or durable document store
• event ingestion from MCP tool usage
• policy checks before memory writes
• provenance fields like source, timestamp, approved_by

The part people forget: memory needs governance

Cross-project memory is powerful, which means it can also go wrong fast.

A few rules help a lot:

1. Separate facts from summaries

Store:

• “PR #182 introduced token refresh”
• “Approved by Alice on 2026-04-02”

Don’t only store:

• “auth is fixed now”

2. Add provenance

Every memory entry should answer:

• where did this come from?
• who wrote it?
• when?
• can it be trusted?

3. Scope access

Not every agent should see every project memory.

If you already use OPA or another policy engine, this is a good place for it. Memory access should be authorized just like tool access.

4. Expire or downgrade stale knowledge

“Known good fix” from 8 months ago might now be the wrong answer.

5. Record approvals for sensitive actions

If memory says “this migration is safe,” that should ideally link to a human approval or an auditable workflow.

Why this matters for MCP specifically

MCP makes tools composable.

That’s huge. But composability without memory means agents can do more things without actually learning much over time.

The next step for serious MCP systems is:

• tool access
• identity
• policy
• persistent memory

That’s the difference between an agent that feels like a stateless script runner and one that actually gets better across repos, teams, and sprints.

Try it yourself

If you’re building or securing MCP workflows, these free tools are worth bookmarking:

• Want to check your MCP server? Try https://tools.authora.dev
• Run npx @authora/agent-audit to scan your codebase
• Add a verified badge to your agent: https://passport.authora.dev
• Check out https://github.com/authora-dev/awesome-agent-security for more resources

A simple starting point

If you’re implementing this now, start small:

• pick 5 entity types
• pick 5 relationship types
• store provenance on every edge
• query memory before tool execution
• write outcomes back after execution

That alone gets you way closer to useful cross-project memory than yet another giant prompt template.

How are you handling agent memory across projects today: vector search, graphs, plain docs, or something else? Drop your approach below.

-- Authora team

This post was created with AI assistance.