How You Organize AI Memory You Own
A practical companion to "How You Make AI Remember." For the few who decide to build their own.
A practical companion to “How You Make AI Remember.” May 18, 2026.
The previous chapter ended with a line I want to come back to.
“Build your own retrieval when the platform’s isn’t enough.”
That line is doing a lot of work. It is one of the things you can do, listed alongside naming files and using code for math and starting fresh. But it is the only one on the list that crosses a real boundary. The others are habits. This one is a project. If you decide to do it, you stop being a user and start being a builder. Most people will not. That is fine. Most people don’t need to.
This piece is for the few who will.
This is part of a book I’m writing in public.
Subscribe to read the rest as it comes
The line you cross
The platform’s memory works. Project knowledge holds your files. Project memory holds a synthesis of recent chats. Past chat search finds older conversations. For most projects, those three plus your own discipline are enough.
They stop being enough when you have state the platform was not designed to hold. The thread of a long project you’ve been working on for months, where the version that matters is the current version, and the AI keeps finding old versions in past chats. A short note at the end of a session saying “here is where we are right now, read this first next time” that the next session actually reads first. A list of decisions you’ve made about your own work, in order, that you can scroll back through later. The current state of something you are building or thinking through, separate from the conversation that produced it.
None of that fits in project knowledge cleanly. It’s mutable. It grows. The file you wrote last week is not the file you want the AI to read next month. You can update files by hand, and for a while you do. Then you realize the AI is still reading an old version because the new one hasn’t loaded yet, or the synthesis has compressed away the part that mattered, or you can’t remember which file holds the current truth.
That is when you cross the line.
What’s on the other side
A database the AI can read from and write to.
I will say that out loud because the word “database” sounds heavier than what is actually required. Cloudflare gives you SQLite at the edge for free. Five gigabytes of storage. Five million row reads a day. None of which you will use. You pay nothing. You set up an account, write a small program that exposes a few endpoints over HTTPS, and now the AI can call those endpoints the way you might call any other API.
Cloudflare is what I picked. It is not the only path. Supabase, Firebase, and Vercel all offer free tiers that can host this kind of thing, each with different shapes and different catches.[1] I picked Cloudflare because the free tier is the cleanest match for what this is. None of them are wrong.
The AI cannot do this on its own. It needs network access from inside the chat. In Claude.ai there is a setting that turns this on. Once it is on, the AI can run Python or curl from a sandbox and reach the internet. That is the door. Everything else is what you do once you walk through it.
I tested the door first, before building anything. I sent a few requests to a public echo service called httpbin.org, which exists for exactly this purpose. You send it anything, it sends back what it received, so you can confirm the wire works. The test took a minute. I sent it short strings, long strings, query parameters, JSON bodies, custom authentication headers. Everything came back intact. The largest payload I tested was ten megabytes, sent and echoed back in about a second, with a cryptographic hash on both ends to confirm nothing was lost. I had not expected that to work. It did.
If you want to run the same test yourself before you decide whether to build anything, I have left the prompt at the bottom of this piece. Paste it into a chat with network access enabled. The AI will run it and report what worked. You will know within five minutes whether the door is open for you.
What it changes
Once the AI can read and write a database you control, three things shift.
The first is that the carryover problem becomes solvable. When a long session ends, the AI writes a short note to one row in the database, replacing whatever was there before. The next session, before answering anything, reads that note. The next AI knows what the last AI was working on. You do not type a recap. The continuity lives on a server, not in your memory or your patience.
The second is that the current state of whatever you are working on stops being scattered across files and chats. There is one row that holds the present version. The AI proposes a change. You confirm it in chat. The change is written. The next session reads what is current, not what was current three weeks ago. If what you are working on has parts (chapters of something, sections of something, threads in a long thought), each part is its own row, each part has a status you can change, and the whole picture is one query away.
The third is harder to name. Once you can write, you can keep a record. Decisions you’ve made. Notes to yourself that didn’t fit anywhere else. Things you want to look back at later. The record is append-only. You can read it. You can filter it. You can ask the AI to show you what you decided last month, or every note tagged a certain way, or what was happening around the time you made a particular choice. The AI is not remembering for you. The database is. The AI is the layer that translates your question into a query and translates the result back into language. Same shape as the awk one-liner from the previous chapter. The math lives in a place that doesn’t lie. The model is freed up to do what it’s good at.
What this is not
This is not a system that makes the AI conscious of you across sessions. It does not give the AI memory. It gives you a database that the AI knows how to read and write. The AI is still freshly assembled at the start of every chat. The continuity is in the database, not in the AI.
It is also not a product. There is no app to install. No marketplace. No subscription. You write the small program yourself, or you ask the AI to write it for you, and you run it on Cloudflare’s infrastructure for free. It does what you decide it does. It changes when you decide it changes. Nobody else uses it.
And it is not a substitute for the discipline the previous chapter described. Naming files. Maintaining one source of truth. Using code for math. Starting fresh when the chat gets long. Those still apply. The database does not replace them. It adds one more room to the workspace.
When it is worth it
If you are using the AI for a single ongoing project that has grown past what project knowledge can comfortably hold, and you keep running into the problem of state that should persist but doesn’t, this is worth building.
If you are using the AI casually, or your projects are short, or the platform’s memory is already enough, this is not worth building. The platform’s memory is good. It keeps getting better. The cases where you outgrow it are real but not common.
The honest test is whether you have already started building this in your head. If you have read the previous chapter and found yourself thinking about which parts of your workflow want to be tables, you are probably on the other side of the line already, and the only question is whether you decide to make it real.
What I built
This piece is a companion to a larger build I am doing for the project this book is being written inside.
The pieces that matter to someone reading this are the ones any personal user would also want. A carryover row that survives the end of long sessions. A central instructions document that lives on a server instead of being copied into project instructions. A list of the parts of my work, each with a current status I can change. Material attached to each part. A place for free-floating notes. A log of milestones, things that happened, kept in order so I can look back.
When it is working, a fresh AI in a new session does this on turn one. It reads its instructions from the server. It reads the carryover from the server. It reads whichever part of the work the carryover points to as relevant. Then it speaks. None of that information was in the chat. None of it was in project knowledge. It was in a database, and the AI knew where to find it.
The thing I can say firmly is that the wire works. The AI can talk to a database over HTTPS. That part I tested before I built anything on top of it. Anything reasonable you design on a working wire should also work, because the rest is just deciding what tables you want and what the AI should do with them. The hard part is the design, not whether the connection holds.
The piece is written from inside an active build. Some of what I described is running. Some of it is still on paper. By the time you read this, more of it will be running. The shape is what I am sharing here. The details belong to whoever builds their own.
What to read next
Two things, if you want to go further.
The first is the test that started this. The prompt is at the link below. Paste it into a chat with network access enabled. The AI will run three small experiments and report what worked. You will know within five minutes whether the door is open for you.
The second is the design itself. I wrote a generic version, stripped of anything specific to my book project, that you can use as a starting point if you decide to build your own.
It is a few pages of specification. Schema, endpoints, bootstrap pattern, auth model, cost. Enough for you to hand to an AI and ask it to build the service for you, or to build it yourself if you have done that kind of thing before.
That is the thing worth knowing first. Before the database. Before the design. The door has to open. For me it did. The rest is what you do with that.
This is a working companion piece. The wire test is firm. The shape on top of it is a design that any reader can adapt to their own work.
I am writing this book one chapter at a time.
If you want to read it as it happens, subscribe below
If this made you think, share it with someone who needs to read it.
Four chapters in one room. The last one is where you leave it.
Footnotes
[1] The free tier options as of May 2026, with the catches that matter for this kind of personal continuity build:
Cloudflare Workers + D1 + KV. 100,000 requests per day. 5 GB SQLite storage with 5 million row reads daily. 1 GB key-value storage. Unlimited bandwidth. No sleep or pause behaviour. Custom domain free if your DNS is already on Cloudflare. What I picked.
Supabase. Real PostgreSQL with 500 MB storage and 5 GB egress per month on the free plan. More generous than SQLite in some ways. The catch: free projects automatically pause after 7 days of inactivity. That is a problem for a continuity tool that has to be reachable whenever a new session starts, which may be weeks later.
Firebase (Spark plan). Google’s offering. Firestore document database with 50,000 reads and 20,000 writes per day. Generous and stable. No pause behaviour. The catch: when you outgrow the free tier you move to the Blaze plan, which has no spending cap by default. A runaway query or a forgotten loop can rack up real charges before you notice.
Vercel (Hobby plan). Mainly a hosting and serverless functions platform. 1 million function invocations and 4 hours of active CPU per month. You’d still need a separate database (Vercel offers Postgres and KV add-ons but with smaller free quotas). Better fit if you are already running a Next.js site there and want to extend it.
Other adjacent options include Render, Railway, and Supabase’s competitors, but the four above cover most of what readers will recognize. If you already have an account with one of them, use that. The design in the companion document is generic and transposes across all four with small adjustments.
BØY (Chaiharan) has spent 30 years in tech — building products, recovering disasters, and turning around the things nobody else wanted to touch. Based in Bangkok. Writing a book in public about what AI reveals about the humans who use it.
Hey bØy — "you have state the platform was not designed to hold" is the sentence that makes this click. That's not a feature request — that's the moment you realize you've outgrown the tool and need to build around it.
The Cloudflare free tier approach is smart and democratizing. Five gigs of SQLite for free means anyone with basic technical skills can give their AI persistent state without paying for enterprise infrastructure. The barrier between "user who wishes the AI remembered things" and "builder who made it remember things" just dropped to zero dollars and a few hours of setup.
I work with AI agents professionally and memory architecture is where most projects either succeed or quietly fail. The three shifts you describe — session carryover, centralized state, queryable decision logs — that's basically the minimum viable memory spine. Most people don't realize they need it until they've lost context for the third time and something breaks that shouldn't have. The fact that you can build this on free infrastructure means the excuse of "it's too expensive to give my AI real memory" is officially dead. Practical and well-documented — sharing this.