An assistant that writes a draft and an agent that sends it have crossed a product boundary. The first prepares something for inspection. The second changes what another person receives.
For teams building agents, a useful design question is therefore specific: what authority does the system need for this particular action? The framework below is an editorial proposal for product design, not a claim about any vendor's current controls.
Start with the action
Describe the action in plain language: read a document, edit a draft, send a message, publish a page or spend money. Avoid a single permission called "manage everything." It hides the decisions both the user and the system need to make.
For each action, record the affected resource, the intended audience and whether the result can be reversed. Editing a private draft and changing a public page should not automatically inherit the same authority.
Make permission useful before making it broad
A meaningful instruction might allow an agent to update a particular collection of drafts while keeping publication separate. It can also specify a time window or a spending ceiling when those limits matter.
Once the user has clearly authorised an action within that scope, repeated confirmation adds friction. The product should ask again when the action exceeds the agreed scope or when a missing detail changes its consequences.
Show the result that is about to happen
When confirmation is needed, show the concrete result: the destination, the affected content and the change. "Proceed?" is a weak question if the user cannot see what proceeding means.
For a publishing tool, a useful preview includes the page title, destination and content. For an outbound message, it includes the recipient and exact text. This turns approval into a decision a person can actually assess.
Design the failure state too
Consider what happens if an action times out after it may already have succeeded. A product should avoid blindly repeating it. Give users a clear status and enough action history to understand what changed.
Also distinguish "the agent prepared this" from "the service accepted this" and "the result is publicly visible." These are different states, even when a smooth interface makes them look like one step.
Review the product, not just the prompt
Take one workflow and answer five questions: what can the agent access, what can it change, when does it ask, what evidence remains, and how can a person recover?
Use the AI Transparency Checker as a starting point for that discussion. It surfaces product questions; it does not certify legal compliance. For the regulatory context, consult the European Commission's AI Act overview.
The design goal is authority that users can understand. A capable agent becomes more useful when people can see the limits of the job they have given it.