The Brain Is Just Postgres
Building a persistent state layer for LLM workflows
For the last few months, I have been using Claude for almost everything. Building, writing, thinking, running my work.
But the data kept getting messy.
A work document would come back with my son’s name in it. A task I had given to a colleague in one thread would be invisible in the next. Context I had built up over weeks would not carry forward. Projects helped, the way a drawer labeled miscellaneous helps. I created my own methods to compress a thread and continue it in a new one. Not enough.
Claude could not hold on to things, no matter how hard it tried. Every conversation felt like it started from zero, despite the context, skills, and instructions. I needed something that persisted across conversations. I tried being more structured. It helped, but didn’t fix it.
So I built something. A small server. A Postgres database. A way for Claude to remember things between conversations, owned by me, queryable by any AI client.
I did not set out to build a framework. I just wanted my tools to work.
Managers
Each domain of my life gets its own manager in the database. A manager for my work. One for my health. My mother’s care. My finances.
To each manager, I gave three things.
Identity, which is who they are and what they own.
Skills, which are how they handle specific tasks.
Context, which is what they currently know about their domain.
That’s basically the model.
The work manager knows about my business. Latest MIS reports. Team structure. Client information. The health manager stores my checkups, patterns, what to watch for next. My mother’s manager does the same for her records.
I can tell the work manager to track a client’s deliverables, and a week later, in a new conversation, it still knows what slipped. Not because I repeated it, but because it’s stored.
When I open a new conversation and load my system, the right manager comes up and we keep going from where we left off. Not from zero.
Shared infrastructure
Around those three knowledge layers sits the boring part. Tasks. Logs. Files. Links. Integrations with Email, WhatsApp, Calendar, etc. Postgres tables and a few MCP tools.
The interesting part is the three-layer mind. The infrastructure is just plumbing.
The one rule that does most of the work
Context is the current state. Overwrites in place.
Logs are point-in-time events. Append-only.
A blood report from April 15 is a log. “Mother has diabetes” is context. The report goes into a row that stays there forever, timestamped. The diagnosis goes into a living document that gets updated as reality changes.
Collapse these into one thing and the system rots within weeks. Keep them separate and it compounds.
How it became a framework
I built this for myself in late March. Three weeks in, I was thinking about Retainia, my agency platform. We had been making context documents for client brands, kept in folders. It clicked. Retainia could have a layer like this. Each brand as a manager. Each one with its own identity, skills, context. The same shape.
A few days later I was working on a website design project for a client. Different domain entirely. Halfway in I caught myself reaching for the same model. A manager for the project. Skills for how the work moves. Context for what each section needs.
I had built this for myself three weeks earlier. The pattern had already shown up in two more places before I could stop and name it.
What this is not
Not an AI product. The database stores the data. Claude, or ChatGPT, or any MCP client reads it and acts as the interface. The AI is the cognition. Postgres is the memory. The brain, if you want to call it that, is the part you own and the part that compounds. The AI gets swapped. The memory does not.
Not a workflow tool. Asana and Notion give humans a place to coordinate. This gives AI a place to remember.
Not a theory about agents. What I have built is simpler. Persistent state. Domain ownership. A small number of disciplines that keep the state from rotting.
LLM Knowledge Bases
This felt related to something Andrej Karpathy wrote a few weeks ago about LLM Knowledge Bases. Wikis compiled from raw research material, queried and extended by an AI, all stored as markdown that the user owns.
The difference, at least in how I’m using it, is that his pattern is for understanding a domain, while mine is for running one.
His state is more like a wiki. Mine is more like a set of active managers with things in flight.
If LLM Knowledge Bases organize what you know, what I have been building runs what you do.
I’ve been calling it an LLM State System, mostly as a way to refer to it.
What I notice
Every productivity tool I have used expects me to go to it. Open the app. Check the dashboard. Update the status.
This one does not work that way. I am already talking to Claude every day. The system meets me where I am. The conversation is the interface and the state accumulates underneath it without me thinking about it.
It compounds in a way I hadn’t really experienced before. Every context update, every log, every small correction to a manager’s skill file, it all persists. The assistant that helps me today is smarter than the one that helped me yesterday because it has more to work with.
A pattern that keeps showing up across different domains when I was not looking for it. No roadmap, no waitlist, not a product.
Just something I built because the tools I had were not stateful enough, and a guess that this might be useful to others as well.
Public repo
https://github.com/sgistic/llm-state-system
About SG
I run Dobby Ads, an AI Creative Agency. I am an Over-thinker. This is where that overthinking goes. Connect with me on LinkedIn.