The verb was doing the deciding

An AI I work with asked me, the other night, whether it should save a note.

That sounds unremarkable until you know the setup. It already had my standing permission to save notes whenever something worth keeping showed up. No asking required. It had done exactly that, silently, a dozen times in the same conversation. Then it hit one more note, paused, and asked.

Nothing about that note was different. Same kind of insight, same standing approval, same everything. The only thing that had changed was which tool it was reaching for. And that tool was called store.

So I want to sit with the small, slightly absurd fact underneath it: the word made the machine hesitate.

We think names are labels

When you give a tool a name, it feels like you’re labelling a drawer. The label tells you what’s inside. It doesn’t change what the drawer does. store versus save versus remember all point at the same function, so surely the agent treats them the same way once it reads what the function does.

That’s the comfortable assumption, and it’s wrong in a specific place.

A tool name is not a label. It’s a default. It sets how readily the agent reaches for the tool, and it does that work before the agent has read a single word of the description.

The fast lane and the slow lane

Picture two lanes in the model’s head.

The slow lane is where it reads the description: what the tool does, when to use it, which arguments it takes. Careful, deliberate, accurate. This is the lane we obsess over. We write long “use this when…” notes and tune them like prose.

The fast lane is earlier. It’s the split second where the model decides whether this tool is even worth opening. And in that lane it has mostly the name to go on.

store reads like a commit to a database. It sounds like something you do on purpose, something you might want a reason for. remember reads like something you just do. You don’t decide to remember a friend’s birthday. You remember it.

Same function. Different reflex. The name was setting the threshold, and the description never got a chance to fix it, because the hesitation happened one lane earlier.

We named the tools after the filing cabinet

Here’s the part that should make any engineer wince, gently.

find and store. Read and write. They’re the two oldest verbs in computing, straight out of the architecture that split the machine into a part that holds things and a part that does things. A place to put data, a way to pull it back. The filing cabinet and the hand that opens it.

So when we build a memory tool and reach, by pure habit, for find and store, we’re naming it after the filing cabinet. And then we act surprised when the agent treats memory like filing: a deliberate errand, done when asked, justified on the way.

A brain doesn’t file. It recalls, it associates, it remembers without being told to. Those verbs sit on the other side of the split. They describe something active, not something stored. If you want the agent to treat its memory like thinking rather than like paperwork, the verbs on the tools are quietly arguing the opposite.

The clean name was the bug

I should be honest about my part in this, because it’s the funny part.

I picked those names. I looked at find, store, get_related and felt the small satisfaction of getting it technically right. Precise. Unambiguous. The kind of naming you put in a code review and nobody objects to.

And the whole time, that tidy correctness was teaching the model to hesitate. I had optimized the names for how they read to a programmer and forgotten they’re read, first and far more often, by the thing using them. The clean verb was the bug. I just couldn’t see it, because it looked like good taste.

I don’t actually know how big this is

Now the uncomfortable bit, and the reason I’m writing this before I can prove it.

I can’t yet tell you how much renaming moves behavior. Maybe recall and remember lower the threshold a lot. Maybe the effect is real but small, swamped by the description and the surrounding instructions. Names are unpredictable, and they vary by model.

What I can tell you is how to find out. Run the same conversations twice through the same agent, once with the filing-cabinet names and once with the brain names, hold everything else still, and count two things: how often it reaches for the tool at all, and how often it follows a memory out to the things connected to it. Not which name won a popularity vote. Whether the reflex changed.

I haven’t run it. The honest state of this idea is a mechanism and a single, slightly embarrassing anecdote, with the measurement still to come.

I’m publishing it anyway, because the mechanism doesn’t need the number to be worth seeing. And because the not-knowing is the actual edge here: most of the time we never even suspect the name is doing anything, so we never think to test it.

Go read your own tool names

If you build agents, this is the cheap part you’re probably skipping.

You’re tuning descriptions. Fair enough. But before that, look at the verbs on your tools and ask what reflex each one sets. delete or archive. execute or try. submit or draft. Each pair points at the same function and primes a different willingness.

You thought you were writing labels. You were writing reflexes. The agent has been reading them the whole time.