Good AI memory isn't about storing more — it's about loading the right things.

I've been building with AI agents for a while now — not as a side project, but as the core of how I work. I run a small consultancy that builds AI systems for businesses, and my own agent is where I test everything first. It manages my tasks, tracks my projects, holds context across days and weeks. It's like having a 24/7 employee — one that I test everything on first.

But before I got here, I spent weeks convinced my AI agent was forgetting things. Projects I'd mentioned yesterday — gone. Decisions we'd made together — evaporated. I kept adding more to its memory files, stuffing in every detail I thought it needed. The agent got worse.

Turns out it wasn't forgetting. It was drowning.

The missing big picture

I had a file called ACTIVE_PROJECTS.md. A running document of everything I was working on — project names, statuses, next steps. Of course I assumed it loaded — it was right there with the others. But sitting in the workspace doesn't mean it gets read.

Some context: my system has 8 hardcoded files that get injected into the agent's context every session — things like AGENTS.md (the main instruction set), SOUL.md (personality), and MEMORY.md. These load automatically. No action required.

ACTIVE_PROJECTS.md was not one of them.

It was sitting in the workspace, unread, every single session. My agent had no idea what I was working on unless I explicitly told it. It was like starting every conversation from zero. I thought my agent knew the landscape. It didn't. It was navigating without a map — not because the map didn't exist, but because nobody handed it over at the door.

The missing sense of today

Problem two was subtler and, honestly, more dangerous.

My AGENTS.md had a boot sequence:

But steps 1 through 3 were reading files that were already auto-injected by the system. It's like being told to go grab a document you're already holding. You don't just skip that step — you stop trusting the whole list.

The problem wasn't the redundancy itself. It was that by dismissing steps 1-3 as unnecessary, the agent dismissed steps 4 and 5 along with them — the ones that actually mattered. Today's log and memory search never ran.

The result: no anchor to the present. Yesterday's state driving today's decisions. The agent was technically functional. It responded coherently. But it was speaking from old context. Sometimes 24 hours old. Sometimes more.

I didn't catch this for a while. That's the insidious part. A slightly-out-of-date agent doesn't throw errors. It just makes subtly wrong calls.

The cost of memory expansion

Meanwhile, the boot files themselves were bloating. MEMORY.md had grown to around 25KB — a sprawling dump of everything the agent had ever learned about me, my preferences, my projects, my workflow. AGENTS.md was about 13KB of increasingly redundant instructions. Total injection across all 8 files hit roughly 46KB — that's about 23 pages of text. My agent was reading a short novel before every conversation, before I even said good morning.

Duplicate content was everywhere. AGENTS.md repeated things MEMORY.md already covered. MEMORY.md contained operational details that belonged in searchable reference files, not in context that loaded every single session. Every conversation started by burning tokens on stale, redundant information before the agent even read my first message.

More context past a certain point doesn't make an agent smarter. It makes it confused. Important instructions start getting lost in all the noise.

What we built

The fix was to strip everything down and rethink what "boot" actually means.

AGENTS.md went from 13KB to 2.9KB — from 7 pages down to one and a half. Just the essential operating rules — nothing that belonged elsewhere. MEMORY.md's bulk moved to a file called LONG_TERM.md — still accessible, but searched on demand instead of injected every session.

And ACTIVE_PROJECTS.md got replaced by something better: inbox.md.

inbox.md solves both problems at once. It's a lightweight index — a compressed snapshot of everything active. Each item is one line: what it is, what state it's in, who owns it. That's enough for the agent to know what's happening without paragraphs of backstory. And it's the anchor — read fresh every session as the very first thing, before anything else, so the agent always knows where we are today.

It stays small by design. Done items get archived out. Updates happen in real-time during conversation, not batched at the end. Deep history lives in daily log files — one per day, named by date — that are never loaded at boot. When the agent needs something from last week or last month, vector search pulls it on demand.

The total boot went from 46KB of stale context down to about 10KB of lean instructions — plus another 9KB of fresh, current data read each session. Half the total size, but all of it relevant. None of it stale.

Think of it as the difference between carrying your entire filing cabinet to every meeting, versus walking in with one page of notes and knowing exactly where to find the rest.

The insight

The "never forget" promise that AI memory systems sell you — it breaks. Not because the system can't store things. It breaks because loading everything into context makes the agent worse at using any of it.

The answer isn't bigger context windows or better embeddings. It's discipline about what loads at boot:

1. Boot lean — only what the agent needs to operate, nothing more
2. Anchor to today — one small file that says "here's where we are right now"
3. Search for history on demand — the past is always available, just not always present

Nobody wants to burn tokens on sloppy execution driven by stale data. The moment a session starts and my agent knows exactly what matters right now — with the ability to reach back into the past when it needs to — that peace of mind is irreplaceable.

This wasn't a memory problem. It was a problem of discipline at boot time.

And the fix wasn't remembering more. It was organizing the flow of what loads at startup.

I hope my experience with my AI agent's memory system can be useful to others working through the same challenge. I don't think one system fits everyone — and that's exactly why it matters to use agentic engineering to arrive at your own solution. If anything in this post is unclear, feel free to reach out anytime.