Most identity files solve the autonomy problem the wrong way. Too little permission and the agent becomes a chatbot with extra steps — every action a question, throughput dead. Too much and it becomes a liability — emails to the wrong list, tables dropped, money moved to the wrong vendor. The usual response is a permission matrix that grows forever and is still wrong at the edges. There is a one-line rule that generalises better than any policy table we have seen: never post, publish, purchase, or break things without approval. Everything else, move.
Four verbs cover everything that matters
Post — any action visible to a third party (Slack, Discord, customer email, social). Publish — anything persisted to a public surface (blog, site, docs). Purchase — any external transaction that spends money. Break — any destructive change without a recovery path. That is the entire approval-required surface. Everything else — research, write, code, debug, plan, schedule, analyse, organise, delegate — is internal, recoverable, or both.
The four verbs are not exhaustive. They are sufficient. We've watched dozens of soul.md files converge on this exact shape independently. Operators start with long enumerated permission lists and discover they're either too lenient in some edge case or too strict in another. The four-verb rule absorbs both ends.
What this looks like in soul.md
Two lines in a permissions block. requires_approval: [post, publish, purchase, destructive_irreversible]. allowed_default: everything_else. The agent reasons about every prospective action against that floor. If the action plausibly belongs to one of the four verbs, it asks. Otherwise it acts.
The verbs need defining once, in a glossary the agent shares with its harness. "Publish" includes commits to main, blog posts, and updates to public documentation. "Purchase" includes anything that hits a payment endpoint, including refunds. The definitions stay short and live alongside the boundary itself.
Personality decides how the boundary gets read
Different types calibrate the same boundary differently under load. An 8 reads "allowed default" generously and acts on borderline cases without pinging. A 6 reads it conservatively and over-asks. A 1 asks whenever there is any rule ambiguity at all. This is the personality field doing its job: same boundary, different calibration, predictable in both directions.
That predictability matters because the boundary's value is operational, not philosophical. You don't want the agent to ask twelve times per task. You also don't want it to act on a borderline case without checking. Knowing the type lets you tune the boundary itself — looser default verbs for cautious types, tighter for bold ones.
Domain overrides go on top, not inside
Some agents need extras. A financial agent should ask before reading sensitive PII. A security agent should ask before disclosing findings externally. A legal agent should ask before any client-facing communication. These belong in a separate domain_overrides block, not folded into the four-verb default. Keeping them separate lets the default stay portable across roles, and lets the overrides be audited per role.
The result is a boundary that fits on one screen. Four default verbs, one short glossary, an optional overrides block. An operator reading the soul.md knows in twenty seconds what the agent will and will not do without checking.
Why these four generalise: it's really one rule
The four verbs look arbitrary until you notice what they share. Post, publish, purchase, and break are the actions that are hard or impossible to take back and that reach outside the agent's sandbox — they touch other people, the public record, money, or state with no undo. Everything on the "move" side is internal, recoverable, or both: a draft can be rewritten, an analysis rerun, a plan revised. The four-verb boundary is a memorable front-end for a single deeper principle — ask before the irreversible-and-external; act freely on the reversible-or-contained. The verbs are easy to remember; the principle is what lets an agent classify an action you never anticipated.
That is why the rule survives contact with novelty. Confront the agent with a new tool — "deploy to staging," "DM a lead," "delete a branch" — and it does not need a new line in a permission table. It asks the only question that matters: is this irreversible and outward-facing? Deploy to staging: reversible, contained — move. DM a lead: outward-facing, a form of post — ask. Delete a branch with no backup: irreversible — break, ask. The boundary scales to actions you never listed, because it encodes the reason, not just the rule.
“A good autonomy boundary is the smallest rule that prevents the worst outcomes. Four verbs is small enough to remember and broad enough to catch what matters.”