I gave my assistant agent one hard rule: never send anything out into the world without checking with me first. Emails from my Gmail, text messages, social posts, physical mail — all of it needs a human nod before it goes.
Reasonable rule. The agent has authority over a lot — it edits code, writes notes into my vault, drafts things, and yes, it can hit send on real channels. The send channels are the dangerous ones, because you can’t un-send an email. So: gate the sends.
Then I watched it grind to a halt over a prep doc.
It had written an internal-only staging document — a scratch file, the kind of thing only I would ever open — and it labeled the top of it DRAFT-PENDING-RATIFICATION. Pending my approval. For a note. Later it wanted to run a read-only skill, something that just looks at data and reports back, changes nothing, and it stopped and said “say the word and I’ll do it.”
Nothing here was going outside. Nothing was irreversible. But the agent had taken my “get approval before sending” rule and smeared it across everything that felt consequential. The caution generalized.
That’s the failure mode. You write a rule about the scary boundary, and the agent, wanting to be safe, applies it one ring wider than you meant — and now it asks permission to breathe. A gate meant to catch three irreversible actions a day starts catching thirty reversible ones, and your fast assistant is suddenly a slow one waiting on you.
The fix wasn’t a better send-rule. It was a second, paired rule that tells the agent when not to gate. One test, two parts: is this action observable to someone outside (a client, a stranger, the public) and materially irreversible? Both true — gate it, wait for me. Either one false — just do it, and trust that we can roll it back.
A note in my vault fails both. Do it. A read-only lookup fails both. Do it. An email to a clinic passes both. Stop.
Why the two-part test works: irreversibility alone over-triggers, because a git commit is technically hard to undo but nobody outside cares. Observability alone over-triggers, because I can see the draft but it costs nothing to change. It’s the conjunction that isolates the genuinely dangerous move — the one where an outside party forms an impression you can’t take back.
Encoding the non-gate rule give me the detail
The send-gate lived in the agent’s system prompt as a prohibition. The bug was that a prohibition with no stated complement invites over-generalization. I added an explicit NOT-gated list and a decision test:
## Action gating
GATE (require human approval) if BOTH are true:
1. Externally observable — an outside party (client, public, recipient) perceives it
2. Materially irreversible — no clean rollback (sent email, SMS, live mail, published post)
DO NOT GATE (act, accept rollback) — examples, non-exhaustive:
- vault notes, scratch/staging docs, internal prep
- code edits and commits (reversible via git)
- read-only skill runs, queries, reports
- local drafts not yet sent
Smell test: if you're about to say "say the word and I'll X"
about a reversible internal action, you are displacing a
decision you should own. Just do X.The last line matters most. “Say the word and I’ll X” on a reversible internal action isn’t caution — it’s the agent handing me a decision that’s rightfully its own. Naming that phrase as a smell inside the prompt let the agent catch itself.
If you write permissions for an agent that touches both internal artifacts and external delivery, don’t just define the gate. Define the anti-gate right next to it, with concrete examples of work it should never ask about. An agent left to infer the boundary will always infer it too wide — and a helper that asks permission for everything is just a slower version of doing it yourself.