AI Agent Actions with Human Confirmation: A Design Pattern

AI agent actions with human confirmation follow a propose → confirm → execute pattern: the model turns a request like "make a task for Jordan due Friday" into a structured proposal, the app shows it as an editable confirmation card with every field visible, and only on confirmation does the server execute the confirmed values, through the same code and permissions as the normal UI. The model never performs the action itself: people get natural-language speed with a form's control.

Why not let the agent act directly?

Autonomous agents are appealing: say what you want, and it's done. For actions in a workplace tool, three problems make direct execution risky:

• Misunderstanding. "Move the onboarding task to done" when there are two onboarding tasks. "Friday" when it's Friday afternoon — this Friday or next?
• Prompt injection. Text the model reads (a ticket, a document) can contain instructions. OWASP lists "excessive agency" — giving a model more functionality, permissions or autonomy than needed — as a top risk for LLM applications, and recommends human approval for high-impact actions.
• Accountability. When something goes wrong, "the AI did it" isn't an answer. A confirmation makes the person the actor.

Anthropic's engineering guidance on building agents recommends starting simple and adding autonomy only when it demonstrably helps. For a workplace assistant, one step with a confirmation covers most requests.

Step 1: a structured proposal

The model's job is to fill a structured object, not to perform anything:

{
  "action": "create_task",
  "args": { "title": "Prepare Q3 budget review", "assignee": "Jordan", "due": "friday", "priority": null }
}

Use schema-constrained output with every field required and nullable when unknown, so fields aren't silently dropped. Then resolve the loose values in code, deterministically:

• "Jordan" → the matching person in the user's organization. Two Jordans → a pick-list on the card, not a guess.
• "friday" → a concrete date, computed in the user's timezone by a tested date parser. The card shows "Fri 17 Oct" so a wrong guess is visible.
• Missing priority → the default, shown as editable.

Don't ask the model to compute dates or look up IDs; that's where confident mistakes live. The structured-output technique is covered in AI request classification with structured output.

Step 2: the confirmation card

The card is a small form, pre-filled:

• A plain summary: "Create a task for Jordan Lee, due Friday 17 October."
• Every field editable: title, assignee (a dropdown), date and time pickers, priority.
• Clear buttons: Confirm and Cancel. Nothing happens on Enter by accident.
• Accessible labels tied to their inputs, so screen readers read each field correctly.

The card must be built without another model call — from the resolved proposal and your own data — so it's instant and can't be influenced further.

Step 3: execute the confirmed values through existing code

When the user confirms, the client sends the card's values — not the model's original proposal — to an action endpoint. That endpoint:

1. Validates input with the same schema as the normal form.
2. Calls the same server action the regular button uses: creating a task via the assistant and via the task board run identical code.
3. Runs with the user's own session, so database permissions (row-level security) apply exactly as they would in the UI.

LetRelay's assistant is built this way: its actions — create and move tasks, request and decide leave, request and answer meetings, set your status — call the screens' own server actions. The assistant adds no new permissions, no new validation and no new side effects to trust. If the user can't do it by hand, the assistant can't do it for them. Why that matters is in row-level security vs app-layer authorization.

Step 4: report the result

After execution, show what happened:

• Success with a link: "Task created — Open task."
• Failure in plain words with the reason from the server: "Jordan is on leave that day — pick another assignee?" — never a silent failure or a generic "something went wrong".
• A visual difference between success and failure (an icon, not only colour).

Step 5: remember what was proposed

Conversations continue after a card. If the user says "actually make it Monday", the model needs to know what was proposed. Send prior cards back in the conversation history as short text summaries ("[Proposed: create task 'Prepare Q3 budget review' for Jordan, due Fri 17 Oct]"), so follow-ups can amend rather than start over.

Guardrails around the pattern

• An organization-level switch. Actions are more sensitive than answers. Let admins turn assistant actions on or off separately from the assistant itself.
• Per-user rate limits on the action endpoint — LetRelay allows 15 confirmed actions a minute and 200 a day per person — so a script or a loop can't flood the system. See rate limiting without Redis.
• An audit trail. Record that the action came via the assistant, who confirmed it and the values executed.
• No chained actions without confirmation. "Create a task and email everyone" is two cards.
• Reads don't need cards; writes always do. Looking up "what's on my plate" runs immediately, with the user's permissions.

What confirmation doesn't solve

Confirmation fatigue is real: if every card is correct, people start clicking Confirm without reading. Keep cards short and put the most error-prone fields — dates, people — first and prominent. Measure how often users edit cards before confirming: a high edit rate on dates means the date parser needs work; on people, that name resolution does.

And confirmation doesn't replace evaluation. Test the proposal step with a golden set of real requests, including ambiguous names, relative dates and romanized text — see how to evaluate an LLM feature with a golden set.

Tokens and cost

A common question: do actions spend AI tokens? Only the understanding step does — one model call to turn the message into a proposal. Building the card, resolving names and dates, and executing the action are ordinary code and database work with no model call. Rule-based shortcuts (a lone ticket reference, a suggestion button) can skip the model entirely.

FAQ

Should AI agents be allowed to take actions automatically?

For actions that change data in a workplace tool, show a confirmation with editable details first. Automatic execution is reasonable only for low-risk, easily reversible actions with strong evaluation behind them.

What should an AI action confirmation card show?

A plain-language summary, every field the action will use (editable), resolved values like concrete dates and full names, and clear Confirm and Cancel buttons.

How do I keep an AI assistant from exceeding user permissions?

Execute actions through the same server code and user session as the regular UI, so database permissions apply. Never give the assistant privileged keys.

Does an AI action cost more tokens than an answer?

Usually no. One model call understands the request; building the card and executing the action are plain code with no model call.

Sources

• OWASP — LLM06:2025 Excessive Agency
• OWASP — LLM01: Prompt Injection
• Anthropic — Building effective agents
• NIST — AI Risk Management Framework
• W3C — WAI-ARIA Authoring Practices Guide