Research note · A proposed interaction framework, not a production case study.

An agent can sound certain while acting outside the user’s intent. For a product designer, the important question is not how confident its response looks. It is whether the person can understand, limit, and recover from what the system is allowed to do.

Anthropic’s April 2026 discussion of trustworthy agents describes the tension between useful autonomy and meaningful human control, including the fatigue created by repeated approval prompts. Stripe’s agentic-commerce primer shows that delegated commerce is already an infrastructure concern, not only a chat-interface concept.

My design inference is that we need to treat authority as an interaction model. The framework below is a proposal to explore and test; it is not evidence that a particular financial workflow is safe or compliant.

Separate an intention from permission to act

“Find a suitable tool” and “buy a subscription” are different instructions. A product should make that boundary visible before an agent crosses it.

Consider an illustrative procurement assistant. The user asks it to compare three software tools. The assistant may gather information and prepare a recommendation, but a recommendation should not quietly become an authorised purchase. A conversational message is a poor substitute for an explicit record of what the user allowed.

I would model three separate states: proposed, authorised, and completed. Each state needs its own language, evidence, and available actions.

Make the scope readable

A useful permission is more specific than “Allow AI”. It explains which account, which resource, which action, what limit, and for how long.

• Resource: which project, account, or dataset can the agent access?

• Action: can it read, draft, edit, submit, or make a commitment?

• Limit: what quantity, time window, or usage budget applies?

• Escalation: which changes require a fresh decision?

The interface should summarise that scope in plain language and keep it available during execution. A technical permission model that people cannot interpret is still an interaction problem.

Put review at the commitment boundary

Asking for approval at every small step can create noise. Asking only after an irreversible action is too late. My proposed middle ground is to match review to the consequence of the next action.

For a consequential submission, a review surface could show the destination, the exact change, relevant constraints, and whether the action can be reversed. If those facts change after approval, the prior approval should not be presented as covering the new action automatically.

This is a design hypothesis to validate with the product’s users and risk specialists. A visual confirmation pattern alone does not establish authorisation, security, or regulatory sufficiency.

Show evidence, not a performance of thinking

A long stream of generated narration can feel transparent while leaving the user unable to check the outcome. I would prioritise inspectable evidence: which sources were used, what is proposed, which action is pending, and what the connected system actually confirmed.

A completion message should distinguish an attempt from a confirmed result. If a request timed out, the interface should say what is known and what remains uncertain. Repeating the action without checking its status could create a duplicate commitment.

Treat time and tokens as product constraints

Users experience model cost through waiting, interruptions, and unexpected usage. More reasoning is not automatically a better experience.

For an exploratory workflow, I would test an effort limit the user can understand: a bounded initial pass, visible progress, and a clear choice before substantially expanding the work. The product should explain the available estimate and its uncertainty, rather than promise a precise cost it cannot know.

Stop, resume, and “use what we have” are meaningful controls. They let someone trade completeness against urgency instead of waiting indefinitely for a supposedly perfect answer.

Design the receipt and the recovery

After an action, the person needs a usable record: what changed, where, when, under which permission, and what can happen next. Recovery might mean undoing an edit, revoking future access, checking a pending request, or handing the situation to a person. These are different capabilities; the interface should not collapse them into one vague “Undo”.

For evaluation, I would test whether participants can explain the agent’s scope, identify an action awaiting approval, stop work, recognise an unconfirmed result, and recover without repeating a completed action. These are proposed checks, not measured results.

The connection to B2B design

In the B2B payment-handoff note, a requester’s intention and a finance approver’s authority belong to different people. Agent interfaces introduce another actor, but they do not remove that distinction.

The transferable design question is simple: who is allowed to commit what, and how can everyone tell what happened? Making that visible is a more useful starting point than making the assistant look autonomous.