A Name, a Lane, and a Kill Switch

This morning I killed an agent I had forgotten I was running.

It had been alive for two weeks. Idle, parked, spending nothing, doing nothing. I did not find it by auditing anything, because I was not auditing anything. I found it because I tried to name a new session and was told the name was already taken.

Taken by what? By a background job I had started on July 31, interrupted mid-task, and never actually closed. It had been sitting in the dark ever since, holding its context and its name, waiting for someone to come back.

That is a small and slightly embarrassing story. It is also the exact moment I realized my problem had changed shape.

The fleet I did not know I had

When I went looking, here is what was actually running on one laptop.

Six agents. Five repositories. Two of them working at that exact second, on different products, in different languages, for different reasons.

That is not the whole picture either. Three more run in the cloud on a schedule, on machines I never see. One reviews pull requests every hour. One writes a growth report every Monday morning. One audits a client codebase weekly and regenerates a stack of documentation. They start themselves, do a few thousand dollars of junior-developer work a month, and go back to sleep.

For about a year, the interesting question in AI development was which model. I wrote about that repeatedly. I argued in The Flagship Is Dead that picking a single best model was the wrong game, and then eight days later Opus 5 moved the routing decision inside the model and made the point better than I had.

Somewhere in the months since, without a decision I can point to, my hard problems stopped being about models at all.

They are operations problems now. How many of these things are running. What each one is allowed to touch. How I stop one. How I find out what it did.

Three things every agent needs before you run more than one of them: a name, a lane, and a kill switch.

A name

A name sounds like decoration. It is not. It is the difference between knowing that an agent changed something and knowing which agent changed it.

Every session on my machine writes a small record while it runs. Process id, working directory, when it started, what it is doing right now, and a name.

{ "pid": 159828, "cwd": "D:\\documents\\claude\\revtech-website",
  "kind": "bg", "name": "revtechkc", "status": "idle" }

That file is unglamorous and it is the most useful thing in the system, because it turns a pile of identical processes into a roster. Without it, six agents are six indistinguishable copies of the same program, and the only way to answer who touched this is to guess.

The naming also did something I did not design it to do. It surfaced the problem. I asked for a name, the name was refused, and the refusal was the entire alert. No monitoring, no dashboard, no threshold. A collision told me something was alive that I believed was dead.

That is worth generalizing. The most valuable signals in a fleet of agents are the ones that make invisible state visible without being asked. If you are building any of this yourself, spend your effort there before you spend it on prompts.

A lane

A lane is the blast radius you decide before the agent acts, rather than the one you discover after.

The clearest one I run is a pull request reviewer on a private SaaS repository. It wakes hourly, finds open pull requests, reads the actual diff rather than trusting the description, checks it against the repository conventions, posts a review, and is allowed to merge.

That last clause is the one that makes people nervous, so here is the rest of it. Regardless of its own verdict, it is forbidden from merging anything that touches:

• production deployment workflows
• database migrations
• billing code
• anything that deletes or rewrites existing data

If a change touches any of those, it reviews it, says so plainly, and leaves it open for me. The instruction that governs it is one sentence: leaving a pull request open is free, and a bad merge is not.

The second lane is tighter still. My growth agent reads a week of measured search data and writes a report of recommendations. It is not permitted to change site code and it is not permitted to push to the main branch, because main auto-deploys to production. It opens a pull request and stops.

Notice what neither lane is about. Neither is about capability. Both agents are perfectly capable of doing the forbidden thing. The lane is about consequence, and consequence is not the agent's judgment call to make.

Which leads to the part I would most want a client to hear. A lane written only as a polite instruction is not a lane. It is a suggestion to a system that is optimizing for finishing your task. Real lanes get enforced where they cannot be argued with: an allowlist of tools the agent can call at all, branch protection on the repository, a service account with fewer permissions than yours, a required human approval on the deploy. Put the boundary in the infrastructure. Write it in the prompt too, but do not let the prompt be the only copy.

I have written before about what code review means when the machine writes the code. This is the structural half of that argument. The review gate matters more, not less, when the reviewer is also software.

A kill switch

A kill switch is two things that people tend to collapse into one. Being able to stop it, and being able to find out what it did.

The agent I killed this morning had done the second part correctly. Its saved state read:

state:  done
detail: repo clean, tests green, memory saved; safe to restart
tokens: 84,041
tasks in flight: 0

That is a good note. It says the working tree is clean, the tests were green when it stopped, and it wrote down where it left off. Because of those three facts, killing it was a fifteen second decision instead of an investigation. I did not have to reconstruct anything. It had already told me it was safe to end.

The stopping half was one command. The knowing half was two weeks of the agent having written things down as it went.

Its own record of why it stopped was a single line: request interrupted by user. That is me. I interrupted it, walked away, and it did exactly what it should have. It parked, saved its place, and waited. Then it kept waiting, for fourteen days, because nothing in my setup was ever going to tell me it was still there.

Agents fail quiet

That is the part worth sitting with, and it connects directly to the last thing I broke.

Two weeks ago I wrote about my own site blocking my own agent for eleven days, while a dashboard I look at every morning reported the wrong cause in confident red. Different mechanism, identical failure mode. Nothing crashed. Nothing paged anyone. The system kept reporting, and what it reported was wrong.

A web server that dies takes the site down and you find out in minutes. An agent that dies, or stalls, or quietly finishes and parks, looks exactly like an agent that is working. There is no smoke. The absence of output is the normal state of a thing that is thinking.

So the monitoring instinct you already have does not transfer. Uptime is the wrong question, because the process was up the entire time. The right questions are closer to: when did this last do something, what was it, and is anything still assigned to it.

This is not AI advice

Here is the deflating conclusion, which I think is the honest one.

Name your processes. Bound their permissions before you start them, in infrastructure rather than in prose. Be able to stop any of them, and make each one leave enough of a trail that stopping it is safe. Know what is running.

None of that is new. That is operations. It is what running services has demanded for decades, and every one of those lessons was paid for by somebody, usually at two in the morning.

Two things about agents make it easy to skip anyway. They are almost free to start, so you start more of them than you would ever start services. And they hold context, which makes leaving one running feel productive rather than negligent. Together those produce exactly what I found this morning: a fleet nobody decided to build, assembled one reasonable decision at a time.

If you are running even two of these today, the audit takes ten minutes.

List everything you have running right now, including whatever is on a schedule in the cloud, and see whether the list matches what you expected. For each one, name the worst single thing it could do with the access it currently holds, and check whether anything other than its own good judgment would stop it. Then pick one and kill it, just to find out whether you can, and whether you can tell afterward what it had been doing.

The model you are running matters less every month. What it is allowed to touch while you are asleep matters more.