The wrong question: 'can the agent do this?'
Technically an agent can call any tool it is wired to, so the capability question never shapes the design. The question that does: if this step goes wrong, can it be undone, who notices, and how long does the repair take?
- The capability question always answers yes
- The real criteria are impact and reversibility
- Time to notice is part of the risk
- Cost of repair pulls the threshold down
Three buckets: free, logged, approved
Sorting actions into three buckets settles the question faster than debating them one by one. Reading and drafting can run free; state changes that can be undone run with a log; financial, legal or customer-facing steps wait for approval.
- Free: reading, searching, drafting
- Logged: state changes that can be reversed
- Approved: money, contracts, outbound messages
- Moving an action between buckets is its own decision
Approval is context, not a button
An approval screen does more than ask for a click. It shows which data the agent read, why it chose this step, and what the path back looks like. Approval without context transfers responsibility on paper only.
- The sources consulted are visible
- The reason for the chosen step is written down
- The rollback path is known at approval time
- Who approved, and when, is recorded
Test the boundary in production
A permission threshold is tuned against real cases, not at a desk. In the first period the agent only proposes; its proposals are compared with human decisions. Where agreement is high the threshold moves up; where it is not, the workflow is corrected.
- The first period runs in suggest-only mode
- Proposals are compared against human decisions
- The threshold moves on measurement, not on guesswork
- Every threshold change is recorded with its date