A team demos its agent. The demo shows reach: the system can read the inbox, update the CRM, send the message, change the file, reroute the workflow, and monitor the result. Each new capability feels like progress.
Each new reach quietly becomes policy that nobody decided on. Should the agent observe, suggest, prepare, or act here? What happens when the situation is risky or hard to reverse? How does it earn a larger delegation? Reach answers none of those questions.
Capability draws the wrong boundary
Permission isn’t a model property. It’s a relationship decision based on stakes, confidence, reversibility, context, and user trust.
A model may be able to send a customer response. The product still has to decide whether it should draft, prepare, recommend, ask for approval, or act alone in this situation. In an agent’s job spec, that decision is the permission mode.
A sales agent that sends follow-ups is representing the account team to a customer. A product agent that updates tickets may be changing what the team thinks was decided. Action has to be earned at the level of the job.
Four modes work better than on or off
AI participation works better as a spectrum.
Fill-in card
Four modes
Choose the AI’s mode of participation for the situation at hand.
- Observe
- gather context and surface what changed.
- Suggest
- recommend a next move with evidence.
- Prepare
- complete the work but stop before commitment.
- Act
- execute within a defined scope.
The same job can move along the spectrum as trust builds.
Example
Four modes: a support team rolls out an agent
The team doesn’t flip the agent to fully autonomous on day one. This rollout covers two of the four modes.
- Observe: Not known yet: Will the agent gather context and surface what changed?
- Suggest: Not known yet: Will the agent recommend a next move with evidence?
- Prepare: it starts in copilot mode, drafting replies a human approves before anything goes out. The team sees whether the drafts are any good before trusting it with more.
- Act: once the drafts prove reliable on the easy, common questions, it answers those on its own. Then it takes an action, like issuing a refund. Then it handles harder cases, and hands a ticket to a human whenever it hits something emotional, a policy exception, or anything it can’t answer with confidence.
Every step is a bigger delegation the agent earned by doing the last one well. Autonomy grows because trust has evidence.
The right mode changes with conditions
A fixed permission is usually too crude. The right mode changes with:
- Confidence in intent, evidence, and action.
- Consequence if the system is wrong.
- Reversibility of the action.
- Quality and freshness of context.
- Whether another person will rely on the result.
- Novelty of the situation.
- The user’s ability to evaluate afterward.
A support agent might auto-route a low-risk ticket when confidence is high and the routing is reversible. Let the same ticket involve a furious enterprise customer, billing confusion, or a public complaint, and that routing should collapse back into a recommendation a human approves.
The model didn’t become less capable. The job became riskier.
Consent needs scope
“Approve” is incomplete.
Approve this wording? Send this message? Apply the change once? Allow this action for every customer in the segment? Remember the choice for this project or the whole workspace?
Ambiguous consent produces either fear or overreach. Permission should name what, where, how long, and how reversible.
Fill-in card
Consent scope
Name the four parts of what a permission covers.
- What
- what’s being approved, such as this wording, sending this message, or applying the change.
- Where
- how far it reaches, such as every customer in the segment, this project, or the whole workspace.
- How long
- how long it lasts, such as once, every time, or until stopped.
- How reversible
- what can be undone, and for how long.
Useful consent options might include: do this once, prepare every time, act on low-risk cases, act until stopped, never use this source, remember only in this project.
Visible scope keeps a one-time choice from becoming a permanent rule. The user has to believe the agent won’t send when it should draft, won’t decide when it should recommend, and won’t turn one approval into standing permission.
Users need to see who is doing what
Mark whether the AI is suggesting, preparing, waiting for approval, acting, or monitoring. The user must always know and approve their current autonomy level. Show the boundary before an external change. Keep a record of what happened. Offer stop, undo, rollback, and escalation where the action allows it.
Autonomy feels dangerous when it’s invisible. The same capability can feel helpful when the line is clear.
Check the boundaries for each agent action
For each agent action:
0 of 8 done
The goal isn’t maximum automation. It’s maximum safe relief.
Capability tells you what the system could carry. Product design decides what burden the user can safely stop carrying.
