There's a common misconception in the AI tooling space: that MCP (Model Context Protocol) is a memory system. It isn't. It's a transport layer — and understanding that distinction is critical if you're building anything that needs to persist knowledge across sessions and surfaces.
The Confusion
MCP gives you a standardized way to shuttle context between AI models and external tools. It handles the plumbing — structured requests, tool discovery, response formatting. What it doesn't do is decide what to remember, how to organize it, or where to store it.
That's the substrate's job.
Architecture from First Principles
When we started building a cross-surface AI memory system, the temptation was to start with a tool — MemPalace, LangChain memory modules, whatever the flavour of the week was. Instead, we asked the underlying question: what does a memory substrate actually need to do?
The substrate stores and retrieves. The transport layer moves data between surfaces. Conflating them produces systems that are fragile, opaque, and impossible to debug.
Our Approach
We landed on pgvector on Postgres 17 as the substrate — embeddings at 768 dimensions using mpnet-base-v2, with MCP as the transport layer connecting Claude Desktop on Mac, Claude Code CLI on Linux, and whatever comes next. The substrate is the source of truth. MCP is the courier.
Why This Matters
If you're building AI tooling and you've bolted "memory" onto your transport layer, you've created a dependency that will bite you when you need to change models, swap surfaces, or debug retrieval quality. Separate the concerns. Your future self will thank you.