I Got Tired of AI Memory Hype, So I Built a Context Lake

There are problems with creating a report that brings you all the AI news it can find every morning. The first time you hear about some new technique or technology, you’re on it. You’re testing it out. Two days later, you uninstall it to try the next one. Right about the 13th to 25th time you hear the same thing, you actually hear a carnival barker instead and move on.

Well, I got tired of hearing about AI memory. Every tool, every framework, every other thread has its own flavor of it: short-term, long-term, episodic, semantic, a memory MCP, some SDK that bolts a “memory layer” onto your agent. None of them agree with each other. I started skipping those articles.

Part of that is timing. I adopted AI coding early, back when the tools were genuinely crappy, and honestly a lot of them still are. So I’ve already been through a hype cycle or two. Install the getting-shit-done skill bundle, it’ll do miracles. Install the superpower skills, guess what, even better, shinier miracles. So I did. What I got was a bloated pile of skills scattered everywhere, half of them firing at random on the wrong things, most of them quietly depending on three other skills just to work. It burned me out. I’ve started to think early adoption is its own little curse: you go in idealistic and you come out the other side disillusioned. So by the time “memory” showed up as the next miracle, I was already numb to it.

Then, on a completely unrelated project, I accidentally built a piece of the answer without realizing that’s what I was doing. I’d wired up graphify (a tool that turns a codebase into a knowledge graph) and a vector database to index the research behind a project. Not the code. The notes, the plans, the stuff I’d been reading to figure out what to build get synced to a folder daily (I still read some of the news) and processed. I just wanted one place to plan from. It worked unreasonably well.

A while later I ran into a paper that put a name to the thing I’d stumbled into: a Context Lake. First idea in the entire memory conversation that made me go oh… yeah, that actually makes sense. It also didn’t hurt that I already built part of one.

One brain, not one per agent

The paper is a theory paper. It lays out what a Context Lake is and what it has to guarantee, then more or less leaves the actual building as an exercise for the reader. But the core idea fits in one breath:

Stop giving every agent its own memory. Give them all one brain, and let them read from it.

Yes, that’s the hype again, but by building it I knew how it worked. One place that quietly keeps track of everything you actually work on (your notes, your code, your past AI conversations) and stays current. Whatever tool you’re using just asks it for what it needs. I also knew I wouldn’t have to install it as a plugin in Claude. And I am going to say it. FUCK plugins. Let’s just call them “lockins.” We have portable standards, right? So why the fucking plugins, seriously. Yeah, it’s a touchy subject with me.

Now, if you’ve used any of these coding tools, you already have a version of this in your head. “A brain my agent reads from” probably sounds like: it remembers what we did last session, it knows the shape of the project, maybe someday it knows about my Jira tickets or my Confluence pages. That’s the version everyone’s racing to ship. And if that were all a Context Lake was, I’d have kept tuning it out.

It’s the stuff that only shows up once the brain is sitting outside the agents that got me to actually build one.

The part nobody pictures

Start with where the brain’s contents even come from. The tools I use all day, Claude Code and OpenCode, already write down what they did: every session is a record of what I asked, what the agent changed, and, crucially, which project I was in when it happened. That last part is the sneaky-powerful bit. If the lake reads those session logs, it doesn’t need me to tell it which repos matter or point it at my projects. The sessions already say. It back-traces from “here’s what you were working on” to “here’s the code and the context that go with it,” on its own.

Which means the core of the thing assembles itself. I don’t sit down and configure my whole life into it. I work the way I already work, and the record of that work is the setup. Everything else (pulling in an Obsidian vault, wiring up email or Jira down the line) is stuff I add on purpose, on top of a spine that populated itself for free.

And once the lake is quietly recording all of that, not just what’s in your files but how you and your agents actually work together, it stops being only a place to read from. It starts to notice things. Where you keep hand-fixing the same kind of output. Where you ask for the same thing over and over. Those are patterns, and patterns are something it can act on: “you keep correcting this, want me to fix the skill that keeps getting it wrong?” For a developer, that’s sharpening your own tools. For someone who isn’t a developer, it’s the same engine pointed a different direction: “you keep doing this by hand, want me to build you a app that just does it?”

That’s the part I keep coming back to. Every other memory tool stops at handing your agent better context. This one watches the friction pile up over time and offers to remove it, because it’s the only thing in the stack that can see the whole loop.

The sketchy part: it was going to need an MCP

I already ranted about plugins up there. Treat this as the sequel, because I’ve got one more name on the list: MCPs. I hate MCPs. Yeah, so fuck MCPs too, while your at it. Not the idea of them, the idea’s fine, a shared standard for handing an agent tools and data. The reality is that in my experience they randomly work when they’re supposed to and randomly don’t, and I’ve never found the pattern. So I’ve ended up at the same sad little ritual everyone ends up at: every single time I need the thing, I tell the agent to use it, by name, out loud, because it will not remember on its own. Ever. Or it might, sometimes, but that’s even worse actually.

Which is exactly where this project got sketchy. A Context Lake is a brain the agents read from. So how does an agent read from it? It calls out to it. And the standard, everybody-does-it-this-way plumbing for “agent calls out to an external service” is an MCP. I’d designed myself straight into depending on the one piece of the stack I trust the least: build the nice outside brain, then wire it to the agent with the flakiest connector I can find and pray the agent remembers to ask.

Then I found a post from Jason Zhou about a codebase-memory tool he’d been using, and it solved my problem from the side. His complaint was word-for-word mine: these “index your codebase” tools never stuck for him or his team, because either the index went stale or the agent forgot to call the special MCP tools. Same disease. His fix is the part that clicked, and the clever bit isn’t that he threw the MCP out. The tool is still an MCP. He just stopped relying on the agent to remember it. He hangs a pre-tool-use hook on grep, the one command the agent reaches for a hundred times a day anyway. The agent greps like it always does, and in the same step the hook quietly looks that query up in the graph and folds the structural answer into the result. The agent never had to remember a special tool. It greps, and the map rides along.

That was the missing piece, and it wasn’t about hating MCPs into submission. It was about not depending on the agent’s goldfish memory. Claude Code has hooks. So my lake doesn’t have to sit there as a tool the agent might call if it feels like it. It can ride along on something the agent already does and push what’s relevant in at the right moment, on its own. For my own thing I can lean on that even harder than he does: a hook can read the lake and inject context directly, no MCP in the middle at all, no plugin to install, no “please use the memory tool” chanted at the top of every session. It doesn’t ask the agent to be disciplined. It just works whether the agent cooperates or not. That post didn’t hand me the Context Lake. It handed me the thing that made me sure I could build one without it living or dying on whether the agent remembers to ask.

Why build my own instead of installing one of the five billion

Here’s the honest reason I’m building my own instead of just installing one of the memory tools that already exist: I want to know how it works. All of it. Every piece.

Because right now I can’t tell those tools apart. Mem0, Zep, Letta, Cognee, Graphiti, and a new one every week, each with a landing page swearing it’s the one, and from the outside they’re indistinguishable. The exact wall of “AI memory” noise that made me tune out in the first place. The only way I’ve ever cut through that kind of thing is to build it myself, badly if I have to, until I actually understand the moving parts. Once I’ve done that, I’ve got a ruler. Maybe I’ll find something in the wild that’s better than what I made. Great, I’ll happily throw mine out. But now I’ll be able to tell that it’s better, and why.

Where it actually is right now

So where is it actually? Honestly: part-built and mostly promise. The plumbing that reads my sessions and files into one place exists. A lot of the rest, the self-improving part especially, is still me sketching how the pieces fit and betting they will. I’m fairly sure they will; I’ve built enough to not see why they wouldn’t. But I want to be straight that a good chunk of what I’ve described here is potential.

I’m fine with that, because the thing I was chasing was never a product. It was a frame. A way of thinking about all this memory noise that finally sat still and made sense. Stop bolting a brain onto every agent. Build one, outside of them, that they all read from. Everything else is downstream. Whether my version survives contact with reality, the idea is the part I’d want you to walk away with. It’s the first one in this whole space that made me stop tuning out.