A confirmation screen is only useful if the operation executed is the one the person reviewed. “Allow the assistant to help” is too broad for a specific write such as changing a client's program or exporting account records. Design human approval around an exact proposed action and bind the decision to that proposal.
Turn the suggestion into a reviewable object
Before asking for approval, produce a structured proposal containing the operation, target, arguments, expected change and relevant account context. Show a readable summary that reflects those fields. For a hypothetical coaching action, name the client and display the current and proposed program assignment. Do not expose unrelated health details just to make the screen look complete.
Assign a proposal identifier and version. Record who may approve, when the proposal expires and what invalidates it. An edited target or argument creates a changed proposal that needs a new decision. This prevents approval for one action from being reused for a materially different operation.
| State | Permitted next action | Important boundary |
|---|---|---|
| Proposed | Review or reject | No write has occurred |
| Approved | Revalidate and execute | Approval matches this version |
| Stale or expired | Create a fresh proposal | Old approval cannot be reused |
| Executing | Observe durable operation state | Retry does not duplicate the write |
| Completed or failed | Show verified outcome | Do not infer success from generated text |
Recheck access at execution time
Approval does not freeze the world. A coach may lose access to a client, a record may be edited or an account may be suspended between review and execution. Verify current permissions and any required version preconditions immediately before applying the change. If the state no longer matches, explain why a fresh review is needed.
Use an idempotent operation identity where retries are possible. A network timeout after the write should lead to checking durable outcome, not blindly repeating the action. The assistant's final message should describe the recorded result, including partial failure or pending work where applicable.
Framework support is only part of the design
LangChain's human-in-the-loop documentation describes interrupting selected tool calls and resuming after decisions such as approval, edit or rejection. That can provide orchestration support. The application must still define the authorisation policy, proposal lifetime and relationship between edited arguments and renewed consent.
Reference: LangChain human-in-the-loop documentation
What we can point to in UltraFit360
The reviewed UltraFit360 MCP code contains account context, coach-organisation scope and per-operation preview or confirmation support. Those are relevant implementation building blocks. Source inspection does not establish that every possible action has passed production acceptance tests; a release still needs operation-specific evidence.
Read the account-linked MCP integration case
Test the decisions people will actually make
- Approve a valid proposal and confirm the intended record changed once.
- Reject it and confirm no write occurs.
- Edit the target or arguments and require review of the changed action.
- Remove the approver's access before execution and deny the operation.
- Retry after a timeout and return the existing outcome without duplication.
- Expire the proposal and provide a clear way to start again.
For an AI-agent engagement, bring the first write action you want to enable and the consequence of getting it wrong. AptixLabs can help turn that action into a proposal contract, permission checks and an evaluation set. The product should earn trust through inspectable outcomes, not the confidence of the assistant's wording.
Does every AI tool call need human approval?
No. Choose approval requirements according to the action, permissions and consequence. Reads and bounded writes may need different policies, but all actions still require appropriate access checks.
What happens if an approved AI action changes before execution?
Treat changed arguments, targets or relevant record state as a reason to revalidate and, where needed, request fresh approval. Approval must refer to the operation version actually executed.