Your agent has all its rules. That doesn't mean it reaches them in time

While building memory for my own agent, I hit a simple wall. The things it has to load before every session, the standing rules in a file like CLAUDE.md plus a separate memory index, together crossed 140-some entries and grew too big to fit into context in one pass.

The fastest fix was to delete some of the old stuff. My finger was almost on the delete key, but I stopped, because the real question wasn't what to cut. It was whether these were even the same kind of thing.

They weren't. And once I sorted them by kind, a problem deeper than space showed up.

Part 1The always-loaded layer has a ceiling

The memory an agent holds splits, roughly, into two kinds.

First, rules: things it must do automatically no matter the task, like "don't push on your own unless told" or "verify before every deploy." These work like a reflex on the brake, foot down at a red light, no thinking first. Second, data: things you look up when you need them, like which origin a service deploys to or what path a token sits at. These are like phone numbers on your phone, you don't memorize them, you look them up when you call.

Sounds easy: put rules in the always-loaded layer, data in the pull-when-used layer, done. But the wall I just hit says something else. The always-loaded layer has a ceiling. You can't cram everything important into it. Human working memory is the same, Miller estimated back in 1956 that we hold only a few chunks at once, and a context window has a limit too.

Once there's a ceiling, the first instinct is to push some things down to the lower layer and pull them when used, including some rules. That's exactly where it breaks.

Part 2Rules can't be pushed down, because they can't call themselves

In 1966, Tulving and Pearlstone separated two things we tend to treat as one: memory that is available and memory that is accessible. Having it all in your head doesn't mean you will recall it the moment you need it. Something has to trigger the recall first. They called that trigger a cue.

Data sits in the lower layer just fine, because you know in advance when you will use it. When work that touches a service comes in, the work itself is a reliable cue to pull the related data back.

But a rule has no such cue, because you can't predict when it has to act. "Don't push on your own unless told" has to be ready always, not only when the word push appears. Put a rule in a layer that waits for a cue, and it becomes something that exists but never gets picked up.

It looks like this: the agent finishes a task, sees a pending commit, and pushes, out of the habit that finishing means pushing. The rule didn't go anywhere, the file is all there, but at that moment nothing triggered it. Call this silent policy loss, a rule going quiet while still present.

What makes it scary is it does not fail with an error. No red log, nothing pops up. It just goes quiet and breaks the rule plainly. Like someone who has to think before braking every time, by the time they remember, they have already crashed. A reflex that waits to be recalled is no longer a reflex.

This is why rules belong in the always-loaded layer, not because rules matter more than data, but because rules can't cue themselves. That always-loaded layer is exactly what a file like CLAUDE.md is for.

Part 3So what about the ceiling? The fix is a validator, not a good memory

Back to the wall. If rules all have to stay up top, what about the space that hit the ceiling? The fix isn't pushing rules down, we just saw that makes them go quiet. The fix is keeping the top layer small: rules have to be sharp, non-overlapping, not everything you ever recorded. The things that are genuinely data get pushed down, where they cue themselves anyway.

But push a lot down and a new risk shows up wearing the same face: things quietly falling out of the index. The file is still there, but the index no longer points to it. In Tulving's terms, available but with no way to reach it.

To guard against that, you can't rely on a good memory or on being careful. You need a checker. We made the index just a generated view of the files, the files are the truth, the index is only a reflection, and a validate command checks one simple rule: every file must have a place in the index, none dropped.

The first time I ran validate, it found 38 memories whose files were intact but had quietly fallen out of the index. The agent had those memories but had forgotten it had them. Re-indexing pulled them all back without creating a single new one. Nothing was ever lost. It just couldn't be reached.

The shallow lesson here is "rules up top, data below." The real one is deeper: most agent-memory problems are not about storing, they are about retrieving. Having it doesn't mean reaching it in time.

So rules stay in the always-loaded layer because they can't wait for a cue. Data can live below because the work cues it, and you need a checker so nothing drops out of the index in silence.

Next time you are about to store something for your agent, ask one question. Is there a reliable cue that will pull this up when it's needed? If not, it has to stay up top, not left to hope it gets recalled on its own.