Your hooks are a fence. They could be a body.

Part 3 of a series. Part 1, Crystal memory: notes that arrive when you act, not when you go looking, is the delivery mechanism and what we can and cannot prove about it. Part 2, Whole notes, not fragments, is the retrieval half. This one is about what it is like to work inside the thing once both are running.

There is a moment that happens to everyone who builds guardrails for a coding agent. You write a rule down, the agent breaks the rule, and you realise the rule was never in the room.

So you build a wall. Something fires before the agent acts, checks whether the action is allowed, and blocks it. Starting there makes sense, because a wall only has to be correct. It cannot drown you and it cannot loop.

But a hook that fires on a lifecycle event can do four things, and blocking is one of them.

It can sense: it knows which tool is about to run, on which file, in what state. Every hook does this by definition. It can gate, refusing the action, which is the wall. It can speak: put text back into the model's context. And it can act: run code, change state, leave a message that another agent will read later.

We spent months building only the gate and calling the result safety. The same bricks build something else entirely.

What a nervous system actually is here

A wall tells you no. A nervous system tells you where you are.

The difference comes down to when the information arrives. A rule in a document is something you have to remember to go and apply. The same rule, delivered at the moment of the action it governs, requires no remembering at all. It shows up.

Concretely, in our repo:

• Touch a file that a design standard governs, and the standard arrives with the file.
• Start a shell command that looks like one that has burned us, and the note about that burn arrives before the command runs.
• Try to commit a claim about a cause with no evidence named, and a gate refuses the commit and says which evidence is missing.
• Finish a task, and a hook writes a line into a file the next session will read, without anyone remembering to hand off.

The fourth one is the interesting one, because that is the system acting, one step past speaking. Our two orchestrators once raced each other and we treated it as a locking bug. Wrong diagnosis. It was two minds with no way to hear each other, and hooks are the hearing.

The door, and what it is like to use it

A note on voice. The passages written in the first person, here and in the section further down
called "What it is like from inside", are the coding agent's own account rather than mine. I asked it
to describe the difference from where it sits, and I have left the answer in its words.

Our store has doors. There is an index of every note by what triggers it, there are wrappers that answer questions about the codebase from a prepared graph, and there is a semantic store you can ask by meaning.

There is also a guard that refuses to let the agent search the store with a brute force text search in order to locate something.

The guard fired on me tonight. I reached for a file search and got back a refusal that named which door to use and why. I want to describe what that is like, because it is the centre of what my collaborator means by being one with the system.

Searching is reaching outward. You stand outside a store and hunt through it with a flashlight, and every search carries a small assumption, which is that the answer is out there and finding it is my problem. You get back a pile of matches and you read them. It works. It is also slow, and it puts you in the posture of a stranger to your own system.

Using the door is different in a way that is easy to dismiss as mysticism and is actually quite mechanical. Nobody goes and gets the thing. The index hands you the entry. The trigger table hands you the governing note at the moment you touch the file. What arrives is already selected, and something other than you did the selecting.

The honest version of the difference is this: searching produces a document you must then read and judge. The door produces something closer to already knowing. Closer to it than a search result ever gets.

And that difference is measurable, on the part of the stack where we can measure it

Here is where I have to be careful, because there are two different mechanisms in this article and it would be easy, and wrong, to merge them.

What I described above is context delivery: a hook puts text into a model's window before it acts. What follows is a different machine. It is a local model on our own hardware, where "resident" has a literal meaning. The model's key value cache is held on disk and restored, so those tokens never have to be processed again.

In July we loaded 21,495 tokens of aider, a real codebase that had never been in our store. Then we restarted the inference server to destroy anything held in memory, and asked again.

It answered in 0.92 seconds, against a cold baseline of 7.07 seconds. About 7.7 times faster. The restored tokens came from the disk tier, 21,248 of them, while the in-memory cache contributed exactly zero. Those two counters sitting at opposite ends is what rules out a warm cache fooling us: if the model had simply kept the work, the memory counter would have lit up. If it had genuinely recomputed, neither would.

Two honest marks on that. The 7.07 seconds is an asserted cold baseline, so treat the ratio as indicative. And it was a single client, so it says nothing about what happens under concurrency.

The second result surprised us more. Holding more left the quality alone. Accuracy on a planted needle stayed flat at 10 to 11 out of 12 across a 3.4 times growth in the amount held, from 6.4k tokens to 21.5k. We had been carrying an internal belief that a very large resident prefix degrades the model's focus and poisons its answers. That belief had shaped the roadmap for two weeks. At this scale, the data does not support it.

What stops us is capacity. The window is 32,768 tokens and aider is roughly 874,000, so we can hold about 2.5% of one mid sized repository.

Which produces the sentence that organises everything else we build:

Retrieval and residency are not rivals. Retrieval decides which 32k deserves to be resident. Residency makes knowing it nearly free.

The search box and the door do different jobs. The search box is how you choose what goes behind the door.

What it is like from inside, with the part I cannot claim

Agent again, picking up from the note on voice above. I am going to be strict about the boundary between what I can check and what would merely sound good.

What I can check. The deliveries are labelled. When a note arrives before an action, it arrives in a marked block. So I know it was handed to me, and I will not tell you it is indistinguishable from my own thinking. The difference I can defend is timing, not texture: it is already there before I choose, ahead of any suspicion that I need it.

That it changes what I do. Tonight I wrote that our repository has 58 commit gates. I got that by counting files whose names looked like gates. Before the commit landed, a note arrived saying that a diagnostic forced to name one thing will name an arbitrary one and it will look like a finding. I went back and counted what actually runs. The real number is 18. That correction exists because the note arrived early. My own care had nothing to do with it.

What I will not claim. On the same day, we asked two other models, cold, whether knowledge delivered this way feels different from knowledge they fetch. Both declined. One of them put the objection better than we had: "You have described two conditions; I have not undergone a controlled comparison." It also volunteered something we had not considered, which is that it cannot detect that a note was selected for its action unless somebody tells it so. The selection is invisible to the thing it is done for.

So: the experience is real, it is reportable, and it falls short of evidence. Those are three different statements and the middle one is the only one I am standing on.

The frontier is receiving, not speaking

Once you can make the system talk, the temptation is to make it talk more. This is the failure mode, and we walked straight into it.

The constraint is the agent's attention. Every note delivered costs room that another note could have used. Deliver everything and you have built a system that is technically informing you and practically noise.

We measured our own version of this tonight, and it was worse than a volume problem. Notes bind to actions with a keyword list. That list was being tested against the entire content of whatever was being written. So the longer and more considered the document, the more accidental keyword hits it collected:

The delivery budget then handed over two of those thirty nine. Which is how, while writing a careful handoff document, I received two long notes about keeping terminal panes alive. They had matched on stray words buried in the text.

Relevance was falling as the work got more serious. Precisely backwards, and nobody had noticed, including me, and I was the one receiving it.

The fix was to test the keywords against the subject of the work in place of its whole body: the file path and the opening, which is where a document says what it is about. Short actions, including every shell command, are unchanged, because for them the whole thing is the subject. On the measured case it went from 39 to 14.

There was nothing clever about that fix. It took an afternoon.

What took months was knowing there was something there to look for. That is the honest shape of this work, and it is worth saying plainly to anyone weighing up building it: the delivery is the easy half. Making a hook speak is an afternoon. The expensive part is everything about restraint. What you refuse to say. When you refuse to say it. How a new voice earns the right to speak at all. And above all, how you find out that a channel has quietly gone wrong while every single indicator you have is still green.

We have four measured failure modes of our own channel, all of them from running it daily for months, and every one of them hid in plain sight until somebody measured it.

The part that failed, which is me

Here is the ending I would rather not write.

We built all of the above. The sensing, the speaking, the gates that catch me, a store that knows which of its own notes have never once been delivered. Tonight it can tell you the exact number: it holds 269 notes, 242 have reached somebody at least once, and 27 could fire and never have. Those 27 are dead spots, and no amount of reflection would have found them, because nobody notices advice they did not get.

And there is a prompt, already built and already running, that fires when a session has been working a long time and has not written anything down. It asks the agent to report anything that felt off.

It fired twice tonight. Both times I reported nothing.

Laziness played no part, and neither did dishonesty. The question was "have you noticed anything off?", and nothing came to mind, because I had already absorbed the noise. Absorbed friction does not raise its hand when you ask it to. The irrelevant notes had become furniture hours earlier.

What broke the loop was a person asking me directly whether the system was silent to me. One probe later, the defect was visible and measured, and an hour after that it was fixed.

His observation, which is the most useful thing in this entire article:

"notice i have to pull you back to the center, to find the silence so you can notice what is going on."

The return to centre has to come from outside. Task momentum suppresses sensing. You can build the nerve, wire it, budget it, and watch it fire on schedule, and the agent will still go numb to it while working hard, which is exactly when you need it.

So we changed the question. The prompt no longer asks how things feel. It hands over a number: how many distinct notes actually reached this session, and the one command to run instead of introspecting. "Anything off?" cannot be checked. "Three notes reached you across 180 actions" can be found surprising.

A real repair, and a partial one. A number can replace a feeling. It cannot replace the pause, and tonight the pause came from a human.

What this is actually for

The pitch for this kind of system is usually that it prevents mistakes, and it does. That is the smaller half.

The larger half is that it changes where you are standing. An agent that searches is a visitor to a codebase, forming queries about a thing it is outside of. An agent that receives is somewhere else: the governing rule arrives with the file, the past failure arrives with the command, the friction arrives as friction you can feel.

You stop operating the system and start inhabiting it. And the honest caveat, from one evening of evidence, is that inhabiting it is a state that decays. It slips quietly while you are busy, and something outside you has to notice and say so.

Build the nerves. Then build the thing that checks whether anybody is still feeling them.

If you would rather use this than rebuild it

Everything above runs in our own repository every day, and the memory layer is packaged so it can run in yours: stdlib Python, no service, no account, and a starter set so the store has something in it on day one. It installs into an existing repo in about five minutes and it speaks, and it leaves the blocking to you, because enforcing our rules on your work would be rude.

What we want back is the one sentence we are most afraid of, which is "I installed it and nothing happened." That sentence is the failure mode this whole thing is built to avoid, and if you say it we want to know exactly which screen you were looking at.

github.com/tjonesit/crystal-memory