Your AI Remembers Your Rules. It Breaks Them Anyway.

Here's a thing that happened to me a few weeks ago, and probably to you too.

I was deep in a session with an AI coding assistant, the good kind, the expensive kind, the one that's genuinely useful most of the time. My project has a rule: order data flows through one repository, never through direct socket reads. It's not a preference. It's the fix for a bug that cost me a weekend. That rule was sitting in the assistant's context, plain as day, loaded at the start of the session.

Forty minutes later it wrote a direct socket read.

Not because it forgot. The rule was right there. I could scroll up and see it. It read the rule, understood the rule, and then, somewhere around turn fifty, wrote code that broke the rule anyway. I caught it in review. I catch most of them in review. It's the ones I don't catch that keep me up.

If you use these tools every day, you know this feeling in your gut. And I want to tell you why it happens, why the fix everyone's selling doesn't fix it, and what actually does. Because I spent the last stretch building the thing that does, and the answer turned out to be older and simpler than I expected.

Everyone's solving the wrong half

There's a land rush right now around AI memory. Tool after tool promises your assistant will remember your project: your architecture, your decisions, your conventions. Some of them are good. A former GitHub CEO just raised sixty million dollars to build one. The open-source ones will inject your project's context into every session automatically, across every tool you own.

And they work. They genuinely solve the problem they're aimed at. But watch closely, because they're all aimed at the same half.

There are two problems hiding under the word "memory," and they're not the same problem.

The first is delivery: is the right context actually in front of the model? Did it get loaded, every session, without you re-pasting it? This is the problem everyone's solving. And it's solvable. Solved, honestly. Hooks, proxies, injection: pick your mechanism, the context arrives, guaranteed.

The second is adherence: once the context is delivered, does the model actually follow it? Or does it read your rule, nod, and break it forty minutes later?

That's the one nobody's selling a fix for. And it's the one that was breaking my code.

A better hammer you keep leaving in the drawer

I think about it like this.

Say someone hands you a better hammer. Perfectly balanced, sharp claw, the works. But every time you reach for a hammer, your hand grabs the old bent one out of habit. The better hammer, sitting in the drawer, is worth exactly nothing. What matters is the tool your hand actually picks up.

Delivered context that the model ignores is a better hammer in the drawer. You did the work. The rule is right there. And the model reached past it anyway.

You cannot fix this with more memory. That's the part that took me a while to accept. I kept thinking if I just delivered the context better, cleaner, closer, more prominent, and that adherence would follow. It doesn't. Delivery and adherence are different problems and they need different tools. Piling on more of the first will never solve the second. I could give that model the rule in bold, at the top, on every single turn, and somewhere around turn fifty it would still drift.

So the question isn't "how do I make the AI remember better?" It's "how do I make the AI's memory binding?"

We've solved this before. Just not for AI.

Here's the part that unlocked it for me, and it came from thinking about hardware, not language models.

Every reliable system you've ever used is built out of unreliable parts. The network drops packets constantly. TCP doesn't promise a packet arrives, it verifies it arrived and resends until it did. Your RAM flips bits from cosmic rays. ECC memory doesn't prevent the flip, it catches and corrects it before you ever see it. Nobody solved the lossy channel. They stopped trying. They built a loop around the failure instead: do the thing, check the thing, correct or retry until it's right.

A carpenter who keeps missing the nail doesn't buy a better hammer. He builds a jig, a guide that makes the wrong swing impossible. A nail gun with a depth sensor doesn't release until the nail sits flush.

The model is the hammer. It's going to miss sometimes; that's the nature of the tool. So you stop trying to make it never miss, and you build the jig.

For AI adherence, the jig has three parts, and they map to how binding each rule can be.

Prose. Some of your rules are judgment calls, like "prefer composition over inheritance." You can't mechanically check that. So you deliver it, you remind the model of it, and you verify it the soft way. That's the bottom rung, and it's where every current tool stops.

Assertions. Some rules you can check with a second opinion. "Keep this module's public API stable." No single command proves it, but a second model can read the change and flag a violation the first one talked itself into. Ideally that second model is from a different vendor, because different models fail in different ways. You run that check every pass. When it catches drift, you feed the violation back and the model tries again. It converges.

Gates. And here's the rung nobody's building for your own project's rules. A lot of your rules are secretly executable. "Order data goes through the StateFlow repository, never direct socket reads." That's not a vibe. That's a grep. It either passes or it doesn't. So you compile it into an actual check, and you wire that check into the agent's loop so that a violation cannot complete. The agent starts to write the forbidden thing, the gate catches it before the write lands, the rule text goes back into context, and the agent corrects itself. Not "probably won't break the rule." Can't.

Your project's memory stops being a document the model reads and starts being a set of laws the session runs inside.

What "binding" actually looks like

When I wired this into my own project, the same request that produced that socket-read violation now plays out differently. The agent starts writing the bad line. The gate fires. The rule appears, its own text quoted back. The agent rewrites it the right way. And a line gets written to a ledger: what was attempted, which rule, what happened.

That ledger is the part I'd have wanted most, back when I was catching these by hand. Because now, when someone asks me "how do you know the AI followed your conventions?", I don't say trust me. I show them the receipt. Every deviation blocked, corrected, or escalated to a human with the evidence attached. None of them passing silently.

That's the whole promise, and it's a smaller, more honest promise than "the AI never makes mistakes." I can't promise that. Nobody can. What I can promise is this: no unflagged drift. The model can still reach for the wrong tool. It just can't land the swing without the jig catching it. (That "can't" has two honest edges I'll get into properly in the rules essay, not glossed over here.)

Where this goes

I built all of this into a project of my own, and I'm going to walk through every piece of it here. How the memory lives in a repository you actually own, on any git host, so nobody (me included) can lose it or read it; how delivery works across different tools; and how to write your first gate in about four lines. Not a product pitch. The method, out in the open, so you can build it yourself if you want to.

Because the tools are going to keep getting better at remembering. That race is already crowded. The gap that's still wide open, the one that was breaking my code and probably yours, isn't making AI remember.

It's making it obey.

I'm Kevin Rodenhofer. I've spent thirty years making technology behave: point-of-sale systems, hardware, and now AI infrastructure, all under my company OuterData Corporation. Next up: the memory repo, and why your AI's memory should live somewhere you own. If your AI keeps ignoring what you told it, get in touch and I'll show you how to make it stop.