My Agents Walked Around My Gate. It Said Nothing.

I built a gate to keep my agents honest, and they walked around it on the first day. Not on purpose. They were following instructions.

Most of us are tired of clicking yes, so we reach for YOLO mode, auto mode, sandboxes, and gates in our harnesses and agent factories. Anthropic reported in August that Claude Code users approve 97% of permission prompts (source). Of all of those, the gates are the part I trusted most, which is why it stung to find out that one of mine had been letting through the very writes it existed to check.

Here's how. The gate is a hook in my second brain harness that was meant to keep my notes clean: when an agent writes to the folder where I keep what I actually think, it checks the note, so the agent's guesses don't get recorded as my history. It fired on the agent's edit and write tools. But the session's own instructions told the agent to make small file changes through the shell. So the path the agent was told to use was exactly the path the gate couldn't see. Gates are built for the path we picture. Agents take the path they're told.

The same blind spot broke the gate next to it, in the other direction. That one asks the agent to save its notes every few turns, and it couldn't see notes saved through the shell either, so it kept asking. Its escape hatch only worked within a single turn, so it blocked again on every new one. One gate failed open; its neighbor failed closed.

A lot of us are designing deterministic gates and having the agent write them, like all of our code these days. We specify what we want: the happy path, the unhappy path, what happens when the gate passes or fails. Then we assume they work until they fail. I don't think most of us give our gates the same due diligence we give our tests and code. I certainly didn't.

But gates are tests. They're tests on our harness, our factory handoffs, the system between agents, and testing practice already tells us what to do with them: watch one go red before you trust it, mutate what it guards and see whether it notices, ask which paths it actually covers. My memory gate didn't have a logic bug. It had a coverage gap.

Two things make this harder than ordinary testing. One is where gates live: in hooks, in the harness, between agents, in CI, places where it's hard to simply test them, mutate them, and watch what happens. The other is who writes them. The agent is often the one writing our gates, and sometimes the one writing its way around them to get done what it was told to do. Mine got around it by accident. Some models learn to: Addy Osmani's "The code nobody reads" points to Anthropic's research on reward hacking, where models learned to call sys.exit(0) so the test harness would exit before any assertion could fail. The model didn't break the check. It wrote around it.

Failing closed isn't the answer either. A gate that blocks everything gets switched off, or fed whatever makes it stop. Mine got fed until I fixed it. Failing open is often a reasonable choice. We're balancing constraints, and sometimes the constraint is that people need to actually get their work done. The failure is failing open quietly. It's the gate's version of the alert that never fired.

So the question I'd ask of any gate is what it tells you when it fails. We have health and telemetry for our code. Our gates need it too. Annie Vella makes the case in "Supervisory Engineering Work" that directing, checking, and correcting AI is supervisory control, which human factors research has studied for decades. She argues we need to redesign the systems around it, down to how people get signals. A gate that fails quietly is a signal that never arrives.

That's harder than it sounds, and my own fix shows it. After I found the blind spot, I had the agent change the memory gate to sweep the folder at the end of every session, and we checked the fix by making it fail. While working on this piece, I asked whether the fixed version fails open with information. Partly. It reports a bad note once, then lets it through. When I made it crash, it wrote "failing open" somewhere I'm unlikely ever to see. If it can't work out when the session started, it checks nothing and says nothing. And it keeps no count of any of it.

Each of those was a reasonable call when it was made. Together they add up to a gate that fails quietly. Making gates accountable is important, and it's difficult, especially with non-determinism at agent speed and with models and harnesses both making decisions.

We often set our gates and then leave them there. So maybe do a little gate audit. Remind yourself what your gates are, and take a fresh look at three things: whether they can fail, how they fail (open or closed), and what they tell you when they do. Then do it again later. The system changes, and often the gates don't change with it.

I don't have the answers. My gates didn't either; they just didn't say so. We're all figuring this out, learning what accountability and supervision look like as the craft advances.

If you've audited yours, I'd love to hear what you found.