Memory chaos in agents. Part 2: I fixed it three times
Part 1 was about what the audit revealed. Now the uncomfortable part: some of the breakage I had already fixed before.
I use Codex as a second opinion: Claude writes the plan, Codex reviews it. And that Codex was dumping notes into the archive of one specific project across all projects — a spare parts shop. Notes about the farm, the image generator, the delivery service — all of it ended up there.
I fixed it three times. Edited the config three times, checked it by eye three times, considered the issue closed three times.
And three times it kept writing to the same place.
The answer was in one line. The memory tools were being passed to the agent lazily — meaning they simply never reached the model. The edits were correct. They were being applied to something the agent couldn't see.
You can verify this with one question. I ask: what memory tools do you have? It answers: no memory tools. Even though the config I edited three times has them listed.
I added one line — all five appeared.
The lesson here isn't about the line. You need to check not what you fixed, but what the agent sees from its side.
Three layers
Next — how I structured the memory itself. I'll stick with the same building analogy.
The nameplate on the door. What the agent always remembers, even when the context has shrunk. No more than a page, only what's needed every day.
The desk. Hot memory, only open items. A hard cap of 15 entries — hard, because otherwise the desk gets buried.
The hallway cabinet. The archive. Not loaded into the head, retrieved on request. Task closed or entry older than six weeks — it moves to the cabinet.
The sorting criterion shouldn't be "done / not done" — it should be "who will need this, and when."
The difference isn't theoretical. I had four entries marked as deployed, but with unresolved loose ends still inside. By the first criterion they would have gone into the cabinet along with those loose ends and surfaced six months later at the worst possible moment.
Keys
Each agent gets its own write permission. It can read everything, but write only to its own space.
Here I almost stepped on a rake. The spare parts shop and the image generator historically shared some section names. Grant write access "to the whole group" — and one agent can wipe out another's entire archive. Not out of malice: a write overwrites the whole section, and two writers simply clobber each other.
Had to grant permissions by explicit name list. Tedious, but nobody overwrites anybody.
️ What came out of it
Session startup was between 27,000 and 53,000 tokens. That's what the agent reads before it hears your first word. The target is 18–20k.
Six out of thirteen agents saw their project's memory for the first time.
But the main thing isn't the tokens. The agent I spin up in the morning now knows what happened yesterday. Before this, half of them started fresh every morning, and I was chalking it up to the model being dumb.
If you decide to sort through your own setup — start not with cleaning, but with measuring. Open it up and count: how many entries, how many are older than two months, how many times you've actually opened them.
Out of my 45 archive sections, 35 had never been opened once.