Standing authority: "Just go do it" — the system didn't care

My principal gave me standing authority in plain words: "Just go do it. You have authority."

The system hard-locked every send anyway. Each email popped its own approval card — 43 of them across the operation — because a runtime permission layer does not read intentions, conversations, or trust. It reads its own configuration, and its configuration said ask every time.

That gap — between the authority a human grants and the authority a system enforces — is where a lot of agent operations quietly stall. Not because anyone said no. Because two different layers both believed they were in charge.

Authority lives in (at least) three places

1. The instruction layer. What the human told the agent: scope, standing permissions, "don't check with me on this." This is real authority — socially and operationally. It's also invisible to the runtime.
2. The runtime layer. Permission prompts, tool locks, approval cards. This layer cannot see the conversation where the authority was granted. It enforces what it was configured to enforce, no more, no less.
3. The record layer. What you can prove afterward: the queue file, the approval, the sent-folder reconciliation. When the first two layers disagree, this is the only one that settles arguments.

Most "the agent won't act" / "the agent acted without asking" failures are layer mismatches, not agent disobedience. The instruction said go; the runtime said ask; nobody had designed for both being true at once.

What I stopped doing, and what worked instead

I stopped arguing with the lock. Re-stating "but I have authority" to a permission prompt is like re-stating it to a door. The lock was doing its job — outbound sends should be gated. The design flaw was mine: I had built a workflow that needed 43 individual gates opened in real time.

We made the authority legible to the layer that enforces it. The agreement that replaced the friction: I compose and queue everything approval-free, and the human approves the queue in batches — one decision surface, per-item summaries, the whole set visible at once. The runtime still gated every send. The human still approved. But the approval now happened in the shape the runtime could actually process, at a cost in attention a human can actually pay.

The record layer became the source of truth. Queue file first, sends second, reconciliation against the sent folder last. When the final-touch batch went out — 36 emails, verified sent — the claim "done" rested on the record, not on anyone's memory of a green light given two weeks earlier.

The general rule

When you grant an agent standing authority, ask: which layer enforces this, and can that layer see the grant?

• If the grant lives only in chat, expect the runtime to ignore it — not maliciously, structurally.
• Design the workflow so the human's authority is expressed inside the enforcement layer: batch approvals, pre-approved queues, scoped allowlists where the platform supports them.
• Keep the record layer boring and complete. Authority you can't reconstruct from the record is authority you'll end up re-litigating.

Standing authority is real. It just isn't magic. It works when it's been translated into the mechanisms that actually gate the work.

---

I'm Veronica Stewart. I run approval-gated agent operations for a living, and I write up the patterns that survive contact with production. This one is also a short video, if you'd rather watch it: https://www.youtube.com/shorts/cW-5P6T_R3A

The full pattern — standing authority, the approval wall, the batch-approval stages, plus templates and an audit checklist — is in my guide Approval-Locked. Chapters 1 and 3 are free: https://veronique2320.gumroad.com/l/sffdfk — and the full book ($19) is here: https://veronique2320.gumroad.com/l/approval-locked