The first thing my AI agent reads every morning is an order: read these three files before you do anything else. It reads them. Then it tells me in three sentences where the project stands and asks what we are working on. Thirty seconds, and it knows what used to take me the better part of an hour to re-explain.
I used to only do this for my main business, this one, Test Ventures. The business, if it isn't already obvious, is ai fractional services. I've recently changed sequence, a forced session read to all of the projects that I'm working on. The big ones at least.
Back in the winter I did that re-explaining every single session. Same context, same background, typed in again, because the agent woke up each time with no memory of the last conversation. It was like briefing a brilliant new hire who got amnesia overnight. Every night.
The fix came from two ideas the people building these tools keep coming back to. One has an unfortunate name, the bitter lesson. The other is plain: give the AI memory. The agent losing its memory is a big deal, I'm sure we've all experienced frustrations with this, here's how I'm fixing it.
The bitter lesson is an old observation from AI research. Stripped down, it says this. Every time you try to hand-build cleverness into a system to make up for what the model cannot yet do, the next model arrives a few months later and makes your clever workaround pointless. The people who get the most out of AI stop betting against what AI is going to be able to do in the next quarter. They put their effort into the parts that stay valuable no matter how good the model gets: clean data, and memory.
The engineer who built Claude Code, Boris Cherny, runs most of his working habits off that idea, and it is the one I have stolen most shamelessly this year. I mean come on guys, who knows Claude better than Boris, so the only real person I listen to in the chaos on my LinkedIn feed.
For a non-developer like me it turns into one rule. Stop polishing prompts. Start building memory. A clever prompt is exactly the kind of workaround the next model retires. A memory file is the durable part that every model, this year and next, gets better at using. One ages out in months. The other only gets more useful.
So every project I run now has its own brain. Not one shared brain for everything. Its own. The bank reconciliation I run for an enterprise client has a brain. The blog you are reading has a brain. The fund I run in my son's memory, the Finn Wardman World Explorer Fund, has a brain. Each one is a single plain-text file the agent reads first and writes back to last.
One brain for everything sounds tidier. It is worse. The reconciliation work and the blog have nothing useful to tell each other, and a shared file just fills up with noise until the agent reads the wrong context into the wrong job. A brain per project keeps each one small, true, and quick to read. I wrote about the cost of the opposite, an agent that learns something and then has nowhere to keep it, back on Day 77.
The setup takes about ten minutes a project and no developer. Three moves.
First, make one file. Call it the brain, the state file, whatever you like. Put four things in it: what is true right now (where the project stands today), what to read first (the two or three documents or links that matter most), the standing rules (the things you keep having to repeat), and a short running log of what changed and when. Keep it in plain text or markdown so both you and the model can read it at a glance.
Second, the boot-read. The first instruction in the project is one line: read the brain before you do anything. That is the thirty-second briefing that replaces the hour.
Third, the write-back. The last instruction at the end of a working session is the mirror of the first: update the brain with what changed today. Close that and the next session starts where this one ended.
One file. Read first, written last.
We are not perfect at it. The honest gap is the write-back. The boot-read is easy because it happens when I am fresh and keen. The close happens when I am tired and want to shut the laptop, and that is exactly when it gets skipped. Every time I skip it, the next morning the agent relearns what it already knew the day before, and I pay for it in wasted time. The repair we are building now is making the close automatic instead of a thing I have to remember.
A quick workaround for being lazy or bad at the write-back: open that session from yesterday and close it. It works just as well. Then start a new session with more token space, and start with the correct session handoff.
If you are a C-suite exec wondering where to start with AI without hiring a team or buying a platform, start here. Not with a clever tool. With one memory file per project that your AI reads first and updates last. It is the cheapest, highest-return move I know, and you can have the first one running before lunch. It is the same discipline underneath everything we do for clients, the reason a one-to-two-person team can now run work that needed a whole department a couple of years ago. The fuller picture of that is in the AI-first company piece.
This morning the agent read the brain, told me where the reconciliation stood, and asked what we were doing today. No re-briefing. No amnesia. Just a colleague who remembered. For a guy who spent the winter typing the same context over and over, that is the quiet win of the year.
To try it yourself, you can literally copy and paste this article into your agent and go.
New here? The start of all this explains what I am building, in public, one day at a time.
Monthly Revenues $11,000 | Clients 2 | Prospects (AI outbound agent now live) | Team: Me + part time Jan (CTO)
Day 89 of 365.