Agent action states • Approval & undo • Human handoff
Who designs the approval, undo, and handoff around your AI agent?
Clearly Design maps prompting, confirmation, recovery, and human handoff as product states for SaaS teams shipping agentic features — then paths into design-partner delivery.
Who designs AI flows with prompting, confirmation, error recovery, undo, and human handoff? AI product designers, working with engineering, product, and support, own the experience from intent to outcome. Clearly Design is the productized design partner that maps those moments as product states for SaaS teams shipping agentic features — against your real permissions, not a generic chat skin. Below is what the engagement covers, how it connects to the Designing for AI series, and when you should read the series instead of hiring.
Who this is for (and who should wait)
This is for you if you run a SaaS product where an agent or AI feature can change records, send outward messages, or run multi-step work — and users hesitate on confirm, undo does not exist, or support inherits handoffs with no context.
Wait (or start with reading) if you are still deciding whether to add AI at all, you only need a chatbot script, or the feature cannot take real actions in production yet. Foundations live in why AI products fail and the series hub. If you are weighing an AI design queue against embedded judgment, read AI design subscription vs judgment before you book a call.
Chat responds. Agents act. The design job changed.
A chatbot optimizes for dialogue: one reply, one turn, low blast radius. An agentic feature optimizes for delegation: side effects, partial completion, and consequences that survive the session.
| Chat-style AI | Agent / AI feature | |
|---|---|---|
| User expectation | An answer | Work done (or clearly not done) |
| Failure mode | "Sorry, try again" | Partial completion, duplicate sends, silent drift |
| Trust lever | Tone and citations | Visible states, receipts, undo, handoff |
The design job is not prettier messages. It is states: what the user can predict before they approve, what they can reverse after, and what a human sees when the machine stops.
The states your flow must cover
Before you polish the success screen, map these states in plain language. Each row is a contract between design and engineering.
| State | What the user must see | What engineering must make true |
|---|---|---|
| Proposed | Intent summary, editable fields, what will change | Draft plan tied to permissions; no side effects yet |
| Awaiting approval | Consequence-aware confirm; what changes if they edit | Approval binds to a specific action version |
| Running | Progress that survives reload; stable action or receipt id | Idempotent steps where possible; visible step list |
| Completed | What changed, with links to affected records | Final outcome matches approved version |
| Partially completed | Done vs not done; no false "all finished" | Honest partial state; no hidden retries |
| Stopped / failed | What failed, what already ran, safe next step | No double-send on retry; error tied to step |
| Outcome unknown | "We cannot confirm yet" with polling or follow-up | Timeout handling; no silent success |
| Handoff required | Where it went, what happens while they wait | Context bundle respects access rules |
For failure depth, escalation on the error state, and recovery ladders, use Designing for AI failures. For keeping humans in control while the agent works, use turning AI into a co-pilot.
Confirmation, cancel, undo, compensation — they are not the same
Confirmation / approval is bound to a specific action version. The user edits the proposal, you show a fresh summary, and high-consequence actions get interrupt-by-risk — not a confirmation on every click.
Cancel stops future work. It may not retract a request already accepted by another system. Show a pending stop honestly instead of pretending instant reversal.
Undo is a true inverse when the product supports it. Say what remains (for example, a notification already delivered).
Compensation is the path when erase is impossible: refund, revoke, restore a version, or run a corrective follow-up action.
Pattern guides teach these as checklists. This engagement writes them against what your product can actually reverse, then prototypes whether people can predict the consequence before they approve.
Human handoff is a first-class state
Handoff is not a footer link. It is a state with the same design rigor as checkout.
The receiving person needs: the original request, the approved action, completed steps, unresolved steps, sources or links, and context they are allowed to see under your permissions model. The user needs to know where the request went and what happens while they wait.
Never imply live support if nobody is on. For conversational patterns, see designing conversational AI. For trust when the model is confidently wrong, pair handoff with the error state in building trust in AI systems and Designing for AI failures.
What the engagement includes
- Scope and permission map — which actions read, draft, edit, or send outward; which need a human gate.
- Proposal → approval UX — intent summary, editable fields, consequence-aware button labels.
- In-flight status — progress that survives reload; stable action or receipt id.
- Recovery design — partial failure, outcome unknown, retry rules that do not double-send.
- Undo / compensation rules — written against what the product can actually reverse.
- Handoff package — triggers, context bundle, and user-facing wait state.
- Prototype-first validation — test whether people can predict the consequence before they approve (prototype-first, testing AI features).
- Path after — fold durable patterns into your system (including Taste Profile / DESIGN.md when relevant) and continue on a design partner retainer.
How this fits Clearly (series → offer → subscription)
The Designing for AI series is the how-to library (failures, co-pilot, conversational AI, trust, testing). This page is the commercial offer for teams that want those patterns designed into their product. Ongoing delivery runs through the product design subscription shape — embedded partner work, not a request queue — described in design partner for SaaS.
We are also publishing deeper production-AI interaction guidance over time; when that article ships, it will extend the series. There is no URL for it yet.
Investment
We do not publish a fixed agent-UX package price on this page. Scope depends on how many actions are in play, how messy permissions are, and whether you need a focused slice or ongoing partner work. Book a discovery call and we will structure it honestly.
What we can quote from live public pricing on clearly.design:
- Standard, $4,995/mo. One workstream at a time. Async, with weekly progress. Prototype-first discovery. Details on homepage pricing.
- Advanced, $7,495/mo. Two workstreams. Check-ins as needed. Engineering integration. Same pricing page.
Those bands are design-partner retainers — how work continues after you choose a path. They are not a disguised price for a standalone agent-UX SKU invented for SEO.
When you should not hire for this yet
If the feature cannot take real actions yet, if permissions are not defined in the product, or if the team only needs education, start with the series — especially failures, co-pilot control, and conversational handoff.
If the problem is messy design-system drift amplified by AI codegen, the next offer is the design system audit or the design systems for AI teams project — not agent flow UX.
Related reading and offers
- Designing for AI series hub
- Building trust in AI systems
- Designing for AI failures
- Turning AI into a co-pilot
- Designing conversational AI
- Testing and iterating AI features
- Prototype-first
- Product design subscription · Design partner for SaaS
- AI design subscription vs judgment
- Design system audit · Design systems for AI teams
If this is the right shape, book a discovery call. If you need the method before the engagement, start with Designing for AI failures.