Drafts Yes, Sends No. The Only Agent Guardrail That Survived a Year.

My agents read my email. They score job postings against my resume, write the cover letter, draft the follow-up, write the first version of a post, and file all of it where I can find it in the morning. Not one of them can send anything. That rule is about a year old now, and it is the only one I have never loosened at 1am when it was standing in my way.

Most of the argument I read about autonomous agents is a capability argument. Can it book the flight. Can it run for six hours unattended without a human touching it. Those are fun questions and they are not the ones that decide whether I let one of these things near my actual life. The question that decides it is smaller and duller: can this put words in front of another human being without me having read them first.

Read anything, draft anything, send nothing. The third clause does all the work, and the first two are what make the third one bearable.

What actually runs

This is not a thought experiment I wrote in a doc. It is a standing rule in a system I use every day, across four products I run off a 16GB laptop with a second, older machine sitting on as a worker.

The agents have wide read access on purpose. They see my inbox. My memory layer injects the five most relevant things it knows about me into every prompt automatically, so the drafts come out with context I never typed. On the job-search side, one part pulls roles and scores them, another writes the application material, another tracks who I owe a reply to. On the content side, something writes a first pass and I argue with it.

All of that is upstream of anything anyone else ever sees. Downstream, there is exactly one door, and it opens from my side.

Send is the one action I cannot take back

Inside my own machine, nearly everything is recoverable. If an agent writes a bad row into memory I delete the row. If it mangles a file I have git. If it burns an evening on the wrong task, I have lost an evening, which is irritating and finite.

Outbound is different in kind. A cover letter that reaches a hiring manager with a wrong claim in it does not get un-read. A follow-up that lands twice in the same week does not get un-landed. The recipient’s memory is the one database in this whole setup that I have no write access to, and no amount of model quality changes that.

So the permission map I actually run is not organised by how smart the model is. It is organised by which side of the machine an action lands on. Reading costs nothing. Internal writes are cheap because I can walk them back. The moment an action crosses off my hardware and into someone else’s attention, the cost of being wrong stops being mine to fix, and I stopped being interested in clever arguments about that particular boundary a long time ago.

A human thumb on its own is not a gate

Here is the uncomfortable part, because “a human reviews it before it goes” sounds like a guardrail and mostly is not one.

I have sat through enough review queues of machine-written drafts to know what happens. The first few get read properly, word by word. Somewhere after that you start reading for shape, and the shape is always fine, because producing correct-looking shape is the single thing these models are best at in the world. A human thumb is a real gate for the first handful and a rubber stamp after that. Anyone who tells you otherwise has not reviewed a batch.

Which is why the rule cannot rest on me being attentive. In the job-search half of the system there is a step I call fact-guard, and it sits between the model and the draft rather than between the draft and me. It blocks fabricated claims in cover letters and in screener answers. The model is not permitted to invent a number about me. If a claim is not in my verified facts, it does not reach the document, and that behaviour is tested rather than hoped for.

The point is not that the model lies all the time. It doesn’t. The point is that when it does, the invention is fluent, specific, plausible, and lands in the third paragraph of the eleventh cover letter, which is precisely where my attention has already gone. Fact-guard fails closed. I fail open.

The last time a write path had no gate

I know how this goes because I got the same question wrong somewhere else in the same system.

My memory layer, the thing that stores what my agents know about me and my work, was writing secrets in plain text. A session hook saves facts automatically at the end of every working session, and nobody, meaning me, had ever thought carefully about what a “fact” might turn out to contain. When I finally swept it, the damage came to 181 database rows and 36 files.

My first instinct was to filter on read. Catch it on the way out, redact before anything gets shown to anything. That is the wrong layer, and it is wrong for the same reason the send rule exists: a filter on the read path is optional. Some other code path skips it. An export skips it. A backup skips it. Future me, in a hurry, skips it. The fix was to move redaction into the write path, inside insert(), so the unredacted version never exists to be leaked in the first place.

Then the second half, which I nearly missed. The pre-sweep backup still held the original values. The code was correct well before the job was done. It was done when that backup was deleted and the keys were rotated. A gate you can walk around is decoration.

Drafts yes, sends no has the same shape. The rule lives as a place in the pipeline that an action structurally cannot get past, rather than as a policy I remember to apply to the output afterwards.

What the rule costs me

Throughput, and I would rather be straight about how much.

My tracker currently shows 125 follow-ups past due. The machine could have sent every one of them last night. It has the threads, the addresses, the cadence, and the drafts already written. Nothing went out, because I had not opened the folder, and I had not opened the folder because there were 125 of them, which is a chunk of work I keep moving to tomorrow.

An autonomous version of this system would have a cleaner tracker than mine. That is a real cost and pretending it isn’t would be dishonest. It would also have 125 messages loose in the world that I never read, which is one bad generation away from an apology I would rather not write, multiplied by 125 recipients.

I think the trade is still right, though I hold it a bit less tightly than I did in month two. The backlog is not free. Every week those sit there they cool off, and a cold follow-up is a different message than a warm one, no matter how well it is written.

Where the line moves

The honest question is what happens when the models get good enough that my review adds nothing.

Some of that has already happened. On plenty of drafts now I open the file, change one word or none, and press send, which by any reasonable description is a ritual rather than an act of judgment. I am aware of how that looks. Rituals are usually the thing you remove.

The obvious first candidate to hand over is the low-information touch. A day-three nudge that says nothing except that I am still interested carries almost no risk, because there is almost nothing inside it to get wrong. If I were going to move the line, that is where I would move it, and I have thought about it more than once while staring at the overdue column.

What stops me is not a principle I can defend in a design review. It is that I cannot describe, in advance, the specific failure that would make me regret it. I could not describe the memory one either, right up until the moment I ran the sweep and found 181 rows sitting there in plain text. The failures I can picture are the ones I have already engineered around. The ones that get me are the ones I could not picture, and send is the only verb in this system where picturing it afterwards is too late.

So the rule stands, partly on reasoning and partly on a superstition I would struggle to write down. I keep meaning to run the day-three nudges autonomously for a month and see what actually breaks. Every time I sit down to build that, I end up building something else.