Building λcerebro: A Postgres + MCP Integrated Memory Layer for AI Tools

I’ve been thinking about this idea for at least six months. I built an early version of the concept using Notion and Ollama, wiring responses to structured fields in a database because I wanted something closer to a living journal than a disposable chat.

The insight was simple: the truly smart part of an AI workflow is not just the model, but the memory layer behind it. Memory should live outside the model, outside the chat window, and outside any single app. With MCP, that idea starts to feel less like a workaround and more like real infrastructure. λcerebro is my attempt to build that infrastructure deliberately: a Postgres-backed memory layer, exposed through MCP, with a private interface for managing the context my AI tools can use.

This is the beginning of that project. Check back soon for updates as λcerebro takes shape.

Update: [11-MAR-2026]

The Weekly Review prompt “goes over everything you captured, clusters it by topic, scans for unresolved action items, detects patterns across days, finds connections you missed, and identifies gaps in what you’re tracking.”

I have to admit - this sounds exciting!

What I’m building is a Postgres-backed, agent-accessible database that I own outright. My very own “second brain.” Now, any AI tool can interact with my second brain via MCP, and anything I type into those tools becomes instantly embedded, classified, and searchable by meaning from any AI tool plugged into it.

It’s true that the quality of any AI output is contingent on the quality and specificity of the input. But specificity is more than a prompting skill. It’s about persistent memory.

When I code, I use ChatGPT or other prototyping models to basically whiteboard and plan out my ideas. At one point, I used Claude with an MCP integration to Firecrawl, asked it to scrape everything about a specific business, then asked ChatGPT to research leading businesses in the same category. I used one model to analyze the output of another model, then used ChatGPT to build a prompt for Cursor to produce a prototype.

“Everything is context engineering,” Harrison Chase at LangChain claims. Think about how you might not want to delete your ChatGPT chat history, or how you only use this model because it “knows you.” Before building this, I was on the fence about cleaning up my ChatGPT history, but then I started thinking of it as an instance of “us” and couldn’t bring myself to do it. Not because I’m attached to it, exactly, but because I seriously considered the memory and context that would be lost and didn’t want to let that go. Granted, ChatGPT does build a memory profile, and one can set global rules in settings that should always persist, but that isn’t the same thing as having an actual history of context to reference.

See how quickly I become beholden to ChatGPT for specific contexts just because I don’t want to delete old chats? I’m locked in through accumulated context. ChatGPT’s memory isn’t shared with Claude or Cursor. So I spend a lot of time copying and pasting from one tool to another, adding context and explaining what I want it to do with the information. I also spend a lot of time tweaking the output of one model, knowing I’m just going to copy and paste it into another tool. Every tool has built its own silo, and none of them talk to each other. A whole category of products - AI Context Flow, MemSync, Mem0, OneContext - has emerged because platforms refuse to solve this issue.

It’s time to decentralize. Now, as soon as any new model drops, I’ll be able to experiment with it while bringing my full second brain with me, rather than being trapped in an old model or not wanting to spend the time rebuilding context somewhere else. I no longer pay that switching cost. I’m unplugged. We should call this the Matrix Protocol.

So why is this useful? Why build a second brain? Well, because I can, and because it sounds cool. Nate writes that the web is splitting into human-readable and agent-readable versions. Note-taking software like Notion, Apple Notes, Obsidian, or Evernote is really just accumulated clutter with no semantic structure, and each of them locks you into its own ecosystem too. More importantly, those tools were designed for humans to use, not AI agents. They were great at making your notes retrievable to you, but not retrievable to agents by meaning, across tools, through a standard protocol any AI can speak. Every note app was missing that layer built for agents. Well, of course it was. Agents only just got here.

Instead of storing your thoughts in an app designed for humans, you store them in infrastructure designed for anything. A real database. Vector embeddings that capture meaning, not just keywords. A standard protocol that any AI can speak.

This is possible because of MCP - the protocol shift I mentioned above. What started as Anthropic’s open-source experiment has quickly turned into something bigger: infrastructure. Not a bet on one company, not a feature trapped inside one platform, but a common layer. The way HTTP is infrastructure. The way USB-C is infrastructure. One protocol. Every AI. Your data stays in one place, and every tool that speaks MCP can access it.

That’s the part that matters to me most: open architecture you own. Your thoughts live in a Postgres database you control. Not someone else’s proprietary format. Not a SaaS that can change pricing, get acquired, or shut down. A database. The most boring, reliable, battle-tested technology in software. Nobody is going to deprecate Postgres because they need to chase a growth metric.

What this actually looks like is pretty simple. The architecture has two parts.

Capture runs through Slack - a tool I already have open all the time. I type a thought, it hits a backend endpoint that generates an embedding and extracts metadata in parallel, stores both in Postgres with pgvector, and replies back with a confirmation showing what it captured. The point is not just to save the thought, but to turn it into something structured, searchable, and reusable.

Retrieval runs through an MCP server that connects to any compatible AI client. That means I can expose tools for semantic search, recent entries, and pattern analysis to whatever model I want to use. ChatGPT, Claude, Cursor, VS Code, whatever comes next - they can all query the same brain through the same interface.

That’s the unlock.

The people who build persistent, searchable, AI-accessible knowledge systems are going to have AI that gets better at helping them over time, because it has more context to work with. Every thought you capture makes the next search smarter. Every stored note makes the next connection more likely to surface. Every fragment compounds. That’s the real advantage here.

This is not just a note-taking system. It’s not just journaling with embeddings. It’s a memory layer beneath the tools - something portable, durable, and mine. Something that lets me keep my context while changing models, workflows, or interfaces whenever I want.

Prompting still matters. Of course it does. But I’m increasingly convinced that the smarter play is not just learning how to prompt better. It’s building a system that remembers better.

And I’d rather own that memory than rent it.

Phase 1 - Capture

I’ve finished the first half of the system: capture. The database is live, the pipeline is wired, and I’ve already sent my first thought through it successfully. I can now type into a private Slack channel, and that message now moves through my own stack instead of disappearing into another app silo.

Under the hood, I stood up a Supabase project as the base layer for all of this. That gave me a Postgres database to store the raw text of each thought, plus vector embeddings and structured metadata. I also enabled pgvector, created the core thoughts table, added a semantic search function, and locked the whole thing down with service-role access so the system isn’t just working - it’s working on infrastructure I control.

From there, I wired in the AI layer. I generated the connection credentials, set up an OpenRouter key for embeddings and lightweight metadata extraction, and created a private Slack capture channel as the front door to the system. Then I built the Slack app that acts as the bridge between my chat interface and the database.

The real turning point was deploying the Edge Function. That is the piece that receives a message from Slack, generates an embedding, extracts useful metadata, writes everything into Postgres, and replies back with a confirmation. In other words: I now have a working ingestion pipeline for thoughts. I type something naturally in Slack, and the system turns it into machine-readable memory.

After that, I connected Slack events to the deployed function so the whole flow could run automatically. Once the subscriptions were configured, I tested it in my private capture channel. It worked. My first thought went in, the system captured it, and the database recorded it with the semantic and structured layers attached. That was the proof-of-life moment: this is no longer just an idea I’m sketching out. The capture layer is real.

What I have now is the beginning of a real second brain: not just a place to dump notes, but a system that can take in thoughts, structure them, and make them retrievable by meaning later. Part one is done. I’ve proven that I can send a thought through a private channel and have it land in infrastructure I own. Next comes retrieval - making that memory accessible from any AI tool that can speak the protocol.