A broken check must not grant permission.
Suppose Busy can’t reach the list of approved recipients. Skipping the check would let an outage expand who the Persona can contact. We require the opposite: if the required check can’t complete, the message doesn’t go.
An empty list permits nobody. An unavailable policy blocks the action it governs. A missing communication setting gets the tightest stance. An unanswered override expires without executing the request.
This is called failing closed. The controls remain restrictive when information is missing, even when that means useful work has to wait.
The failure should be understandable.
You should be able to tell what happened without reading a technical log. “I drafted the email. The recipient needs approval. The request expired, so nothing was sent. Here’s the draft.”
That tells you what is finished, what stopped, and what you can do next. A bare refusal leaves you guessing whether the problem is a rule, a broken connection or a misunderstanding.
We design the escalation to resemble a colleague asking someone with authority to approve an exception. The Persona can keep useful work ready without pretending it finished a blocked action.
The size of a mistake matters.
Imagine asking for a $12 refund and getting a $20 refund. Now imagine the amount was right, but the refund went to every customer. The second mistake has a very different cost.
Computers are good at repetition. That makes it especially important to control the scope of an action: which records, which recipient, which purchase. One misunderstood instruction should have as little room as possible to spread.
Account permissions, card limits, communication stances and scoped approvals each constrain a different part of that risk. Better model judgment helps, but it doesn’t replace those boundaries.
There is still work for people.
These controls don’t guarantee every answer will be correct. A Persona can misunderstand context, miss a detail or need correction. You still teach it the business and review work that calls for your judgment.
The controls govern what it is permitted to do with that understanding. Keeping the books read-only limits what a mistaken interpretation can change. Requiring approval before an external send gives you a decision before the message leaves.
Useful autonomy needs a tolerable failure.
Sometimes the result is an extra approval or a task that waits for you. That can be inconvenient. It is preferable to a system granting itself wider access to get past the inconvenience.
Clear boundaries let you give the Persona more work inside them. The aim is useful help that can explain where it stopped, with limits that continue to hold when something goes wrong.