Autonomy and human approval

Autonomy is a dial, not a switch

People often argue about agents as if there were two options: the agent does everything itself, or a human does everything. Real systems sit on a dial with at least four stops.

• Analyse only. The agent reads what you give it and replies with analysis. It has no tools at all, so it cannot search, read connected systems or act.
• Suggest only. The agent reads, reasons and proposes. It never changes anything in a connected system. You carry out the action yourself.
• Act with approval. The agent may act, but every action that changes something waits for a person to approve it. Reading, searching and drafting inside the chat carry on freely.
• Act autonomously. The agent performs actions without per-action approval, inside the tools and access it has been given.

Two points are easy to miss. First, above the analyse-only stop, which takes every tool away, the dial applies to side-effecting actions: sending, creating, updating, deleting, paying. Reading is not the risky part. Second, the dial is not set once per agent forever. It should move as the agent earns trust, and different actions can sit at different stops.

Match the autonomy to the risk

For each action an agent can take, ask four questions:

1. Can it be undone? A draft can be deleted. A sent email, a payment or a deleted record usually cannot.
2. Who sees it? An internal to-do task affects you. A message to a customer or a public post affects your organisation's reputation.
3. What is at stake? Money, legal commitments, personal data, access rights.
4. What is the track record? Has this agent done this exact kind of action well a hundred times, or never?

Low on all four, autonomy is reasonable. High on any one, the action should wait for a person. The matrix below is a starting point, not a rule book.

What a good approval request shows

An approval is only as good as the information in front of the person approving. "The agent wants to use the email tool. Allow?" is not an approval request; it is a prompt to click yes. A good request shows:

• The exact action: send, update, delete.
• The target: which record, which recipients, which account.
• The content: the actual email body, the actual field values, the actual amount.
• Why: what part of your request led to this.
• What happens next, and whether it can be undone.

If any of these is missing, decline and ask. That is the job, not an interruption to it.

Bind the approval to the exact action

Here is a subtle failure. You approve "email the Q3 summary to the finance team." Then, before it runs, something changes the recipient list to include an outside address. If your approval is just a yes attached to "the email tool," the changed action sails through on your earlier yes.

The fix is to bind each approval to a fingerprint of the exact proposed action: the recipients, the subject, the body, the amount, the record. At the moment of execution, the system recomputes the fingerprint and compares. If anything that matters has changed, the old approval does not apply, so a changed action cannot reuse an earlier approval, and a new request goes to the person. Good systems also make each approval single-use and give it an expiry, so a yes from last Tuesday cannot be replayed today.

Beware approval fatigue

An agent that asks permission for everything trains people to click approve without reading. Then the approval step exists on paper and protects nothing. Keep approvals meaningful: let reads run freely, group related changes into one reviewable set (a plan, as in lesson 3), and raise autonomy only where the record shows it is safe. Fewer, better approvals beat many ignored ones.

Know how to stop it

Approval covers single actions. You also need a way to stop the whole agent. Before you raise any agent's autonomy, make sure you know three things: how to cancel a run that is in progress, how to lower the agent's autonomy or pause its schedule in one step, and who to tell if an action already happened that should not have. Write them down for any agent that acts autonomously on shared systems. The time to look for the stop button is before you need it, not while an agent is sending the wrong email to the fortieth customer. A good rule for teams: whoever raises an agent's autonomy owns watching its first week of runs, and lowers it again at the first sign of trouble.

How Renly does it

Each Renly agent has an Autonomy setting with four levels: "Analyse only", "Suggest only", "Act with approval" (the default) and "Act autonomously". Analyse only gives the agent no tools at all. The other levels apply to actions that change connected systems; read-only steps always run. An organization admin can also set a Maximum agent autonomy for every agent, and the stricter of the two wins. Actions that need approval appear as a card in the chat with Approve and Reject; destructive actions ask you to type a confirmation first. Each approval is single-use and bound to a fingerprint of the action's key details (such as recipients, subject, body, amount or record), and Renly refuses to run an action that no longer matches it.