AI Agent Approval UX on Phones: Confidence, Rationale, and Recovery

Place Approval at the Exact Decision Moment

Effective AI agent approval UX begins by locating the step that changes something. Researching a route, reading permitted context, or drafting a message can usually remain in a preparation state. Sending the message, changing a setting, deleting a file, or sharing a location creates a different outcome. The interface should place the decision immediately before that consequential step, while the target and proposed result are still easy to understand.

On a phone, timing matters because space and attention are limited. Imagine an agent preparing a reply while the user is walking. A useful status sequence is: reading the selected conversation, drafting the reply, waiting for review, then sending after approval. The approval screen should show the recipient and final text rather than interrupting earlier with a generic question such as “Allow this task?” The user can approve, revise, or leave the task waiting without losing its context.

Permissions and approvals serve different purposes. Android permission determines whether the app has access to a capability or data category. Approval records the user's decision about this specific proposed action. Account authorization and app security add further controls. A reliable phone workflow keeps these checks connected but distinct, so a user knows whether the agent needs Android access, clarification, or consent to proceed. Our deeper guide to AI Agent Identity, Permissions, and Audit Trails for Phone Tool Governance explains how those decisions can remain attributable after the task completes.

Separate Suggestions, Previews, and Applied Actions

A phone interface should use distinct labels for three states. A suggestion is an agent recommendation that has not changed anything. A preview shows the exact result that would be submitted or applied. An applied action confirms that the change occurred and presents the observed result. Combining these states under a single “done” label makes it difficult to tell whether the user is reviewing an idea or inspecting a completed action.

GitHub introduced a useful interaction pattern in its July 23, 2026 public preview for supported GitHub Issues actions. As described in GitHub's public-preview issue automation controls, an automation can suggest supported issue changes for review instead of applying them immediately. Users can accept or decline suggestions, while each supported action carries confidence and a recorded rationale. The scope is issue metadata work such as labels, fields, types, closure, and assignees.

The mobile design lesson is the visible transition from proposal to effect. For a message, show “Draft ready” before “Send.” For a setting, show the current and proposed value before “Apply.” For a file operation, identify the selected item and destination before “Move.” Direct application can remain appropriate for low-impact, reversible steps chosen by the user, but the resulting state should still be visible. This gives people a consistent mental model: suggestions can be edited, previews can be approved, and completed actions can be verified.

Route Review by Confidence and Consequence

Confidence can help an interface decide where review effort is most valuable, but a score is an estimate rather than proof. In GitHub's public-preview pattern, high-confidence supported issue actions may apply automatically, while medium- and low-confidence actions wait as suggestions. That arrangement reduces routine review while drawing attention to uncertain metadata changes. A phone presents additional considerations because the same confidence level can accompany actions with very different consequences.

Consider two proposals that both receive high confidence. The first opens a familiar settings page; the second sends a message to a client. The agent may be equally sure about the requested targets, yet the communication has an external effect that deserves a visible review point. Conversely, a low-confidence interpretation of “open the battery page” should wait for clarification even though opening the wrong settings page would be easy to reverse. Confidence routes attention; impact and ambiguity shape the final interaction.

A practical routing model uses several signals together: confidence in the interpreted request, clarity of the target, consequence of the action, reversibility, permission state, and the user's selected approval mode. The interface can translate those signals into understandable states such as “Ready to apply,” “Review recommended,” or “More information needed.” FoneClaw's current approval behavior remains tied to supported tool policy and session state. That foundation keeps the user's decision connected to an actual proposed Android step rather than presenting confidence as a substitute for control.

Show the Reason, Target, Evidence, and Effect

An approval card should answer four questions without requiring the user to reopen the whole conversation: What will happen? What is the exact target? Why is the agent proposing it? What will change if the user approves? These details form a concise rationale. They help the user catch a wrong contact, stale file, ambiguous date, or unexpected setting before the action leaves the preparation state.

For example, a message approval might display: “Send a reply to Maya Chen in the selected project conversation.” The reason could be: “You asked to confirm Thursday at 3:00 PM, and the latest message requested a meeting time.” The preview should include the complete text and any attachment or link. The consequence should be explicit: approving will send the message through the selected account. The screen does not need to expose a long internal reasoning transcript; it needs enough evidence for a quick, informed decision.

Rationale remains useful after an action completes. A short record can connect the original request, selected target, approval, and observed result. If the action fails, the same record helps explain whether the problem came from a missing permission, unavailable app, changed screen, or rejected request. GitHub also emphasizes that its approval feature is workflow convenience rather than a server-side security boundary. On Android, concise approval rationale works alongside permissions, authenticated accounts, supported tool rules, and app protections; each control contributes a different part of the result.

Bind Every Approval to Its Task and Session

Mobile agents often handle several requests close together: prepare a reply, find a route, change a reminder, and inspect a setting. An approval must remain attached to the task that created it. Otherwise, a generic “Approve” button can apply the wrong proposal after the user switches conversations or starts another job. The interface should carry the task name, originating conversation, target, creation time, and current waiting reason into the approval view.

FoneClaw's currently available capabilities introduce independent running and waiting states alongside session-bound approvals and task isolation. In our Android experience, one task can wait for a decision while another supported task continues independently. The waiting card remains associated with its original session, so returning to it restores the relevant request and proposed action instead of borrowing context from the most recent conversation.

A compact task queue should make status scannable. “Running” means the agent is working on a supported step. “Waiting for approval” identifies a prepared consequential action. “Waiting for permission” points to an Android access requirement. “Needs clarification” tells the user which detail is missing. “Completed” presents the observed result. This state model lets users leave a proposal pending without treating silence as approval. For a broader view of the phone as the place where people supervise multiple agent tasks, see Mobile Agent Control: Why the Phone Is Becoming the AI Agent Command Center.

Use Action-Specific Approval Patterns on Android

Approval screens should match the action rather than reuse one generic confirmation dialog. A message needs the account, recipient, conversation, complete body, and attachments. A setting change needs the current value, proposed value, and affected device behavior. A file operation needs the exact item, destination, and whether the original remains available. Navigation needs the destination, route assumptions, and the app that will open. These details turn an abstract request into a reviewable phone action.

Different actions also need different controls. A message can offer “Revise” and “Send.” A setting change can offer “Keep current” and “Apply.” A file move can show “Choose another folder.” Navigation can allow the user to select a different destination before starting guidance. Destructive actions deserve especially clear targets and consequences, while reversible display or navigation steps can use a lighter confirmation pattern when the user's chosen policy allows it.

In FoneClaw, supported Android workflows connect the configured model's interpretation to governed phone actions. The user sees the relevant permission or approval when required, followed by a visible result or a clear waiting state. The model can prepare the proposal, but Android permissions and supported tool behavior determine how the phone proceeds. AI Agent Sandbox vs Phone Permissions: Why Secure Agents Still Need Boundaries explains why isolated reasoning environments and real device authorization solve different parts of phone-agent safety.

The same pattern applies to multi-step requests. If a task involves finding information, drafting content, and then changing external state, the early steps can proceed as preparation. Approval belongs at the transition into the consequential action. Showing that transition keeps the workflow efficient without asking the user to confirm every internal step or presenting the final action as an unexpected result.

Design Decline, Revision, Recovery, and Touch Takeover

Approval UX is incomplete without a useful decline path. Declining should stop the proposed action while preserving enough context to revise it. A user who rejects a message because the tone is wrong should be able to ask for a shorter draft. Someone who declines a setting change should return to the current value. The interface should distinguish “Declined” from “Failed” because one is a user decision and the other is an execution problem.

Undo is valuable when the underlying app or action supports a reliable reversal, but it should never be promised universally. Before approval, revision is usually the stronger control. After completion, the result view can offer a verified reverse action where one exists, such as restoring a moved item or reverting a setting. For an external communication or another irreversible effect, recovery may instead mean preparing a correction and showing the user what happened.

FoneClaw's current released baseline strengthens permission recovery and Home execution recovery. When a supported task lacks an Android permission, the waiting state can explain what access is needed and guide the user through the appropriate system path. If the workflow returns to Home during execution, recovery can reconnect the user with the affected task and its next available step. Session-bound approval remains attached to that task throughout the interruption.

Touch takeover is the final dependable option. The user should be able to open the relevant screen, inspect the target directly, complete an app-specific security step, or cancel the workflow. A strong human-in-the-loop AI agent does not measure success by eliminating every tap. It reduces routine effort while making consequential choices, interruptions, and recovery understandable. That is the standard we apply to FoneClaw's phone experience: prepared actions, task-specific decisions, visible outcomes, and a practical route forward when conditions change.