confidence: 0.95 each
evidence: [sprint1_chat_003]
query: "order service architecture"
Sprint 6 Copilot had zero context from Sprint 1. MnemeBrain bridged six weeks of project history.
How it works
MCP + MnemeBrain inside VS CodeGitHub Copilot Chat in VS Code supports MCP — the Model Context Protocol. Once configured, Copilot can call external tools mid-conversation. MnemeBrain registers as an MCP server and gives Copilot 13 memory tools: believe, search, explain, retract, revise, and more.
The backend is a local FastAPI process storing your belief graph in a Kuzu database on your machine. The MCP bridge is a lightweight stdio process VS Code spawns on startup. Nothing leaves your machine.
Install the backend
Local only, no cloud dependenciespip install mnemebrain-lite mnemebrain-lite serve # → MnemeBrain running at http://localhost:8000
Keep this terminal open. The backend must be running whenever you want Copilot to use memory.
Clone the MCP bridge
The process VS Code spawns to connect Copilot to MnemeBraingit clone https://github.com/mnemebrain/mnemebrain-mcp cd mnemebrain-mcp uv sync pwd # note this path
Register with Copilot
VS Code settings.json — one block to addOpen VS Code Settings (JSON) and add the MCP server configuration:
"github.copilot.chat.mcp.servers": {
"mnemebrain": {
"command": "uv",
"args": [
"--directory",
"/path/to/mnemebrain-mcp",
"run",
"mnemebrain-mcp"
],
"env": {
"MNEMEBRAIN_URL": "http://localhost:8000"
}
}
}
Replace /path/to/mnemebrain-mcp with the path from the pwd command above. Save and reload VS Code.
.vscode/settings.json and commit it. Every team member who clones the repo gets shared Copilot memory pointing at their own local MnemeBrain instance.
Verify and use persistent memory
What it looks like in Copilot ChatOpen Copilot Chat and try storing your first belief:
Remember: this project targets Node.js 20 LTS. We do not use CommonJS — ESM only across the entire codebase.
Copilot calls believe twice and stores both facts with evidence. Next session, they're available via search. To verify what's stored:
What do you know about this project's JavaScript setup?
Contradiction detection when architecture changes:
Sprint 9: "we migrated to Bun for the build pipeline"
truth_state: BOTH ← conflict flagged, not silently overwritten
belief_1: "Node.js 20 LTS" confidence: 0.95 → 0.31
belief_2: "Bun (build pipeline)" confidence: 0.90
Copilot: ⚡ Runtime conflict detected. Node.js stored in Sprint 1, Bun now mentioned. Confirm scope before I update project beliefs.
Enterprise patterns
Team-shared memory across your GitHub orgSeed project beliefs from a shared ADR file at team onboarding:
Read ARCHITECTURE.md and store all architectural decisions as beliefs.
Copilot reads the file, extracts each ADR, and calls believe for each decision. New team members get instant project memory without trawling through months of commit history.
What you've built
GitHub Copilot now has a persistent belief graph that survives across every session, sprint, and team member. Architecture decisions, runtime choices, and migration history are stored, tracked for contradictions, and retrieved semantically — exactly when Copilot needs them.
Typical belief lookup is <5ms on a local Kuzu store with ~100k beliefs. Everything runs on your machine — no cloud, no external APIs beyond what you already use.