CHOICEFLOW · AI AGENT UX · CONCEPT 2026
The Receipt Before AI Acts
ChoiceFlow explores the pause before AI acts: what it understood, assumed, changed, avoided, and needs permission to do next.
ROLE
Sole Product Designer
Team
Design (Solo)
focus
AI UX · Interaction Model · Prototype
Timeline
2026
PRODUCT RISK
The Pause AI Was Missing
As AI products move from recommending to acting, the risk shifts. Users need to understand not only the output, but what the system understood, what it inferred, and what will happen if they approve it.
I used meal ordering as a test case because a single request can contain ambiguous constraints around preference, budget, timing, and memory. It created a contained way to explore consent before an agent takes action.
PROBLEM
Four questions users can't answer in most AI flows.
When these questions stay unanswered, users have to choose between trusting the system blindly or interrupting the flow to regain control.
01
What did it actually understand?
The output is visible, but the system's interpretation of the request often isn't.
02
What did it assume about me?
Inferences can shape the result without showing users what was understood versus assumed.
03
Can I adjust without starting over?
Corrections often require restarting instead of preserving what the system already understood.
04
What happens when I confirm?
The action, memory, and consequences of confirmation are often bundled into a single ambiguous step.
design question
How might an AI flow let users understand, refine, and approve a recommendation before the system acts?
INTERACTION MODEL
Say · See · Steer · Sign Off
I structured the flow around four beats. Intent comes before interpretation, interpretation before refinement, and refinement before commitment. Memory is approved rather than assumed.
Say
The user expresses intent naturally. No menus, no filters, no perfect prompt. Vague is valid input.
TRUST CHECKPOINT
See
The system reflects what it understood as editable criteria. Correction happens before the recommendation gets specific, while it is still cheap.
Steer
The user adjusts without restarting. Every change preserves prior context and explains what shifted and why.
TRUST CHECKPOINT
Sign Off
Before anything is ordered, saved, or remembered, the user reviews the Decision Receipt: what the AI understood, assumed, and is about to do.
PROTOTYPE
Testing the model through one ambiguous request.
I applied the four-beat model to meal ordering: a familiar task where preference, budget, timing, and memory can all require interpretation before an agent acts.
SCREEN 01 · SAY · VAGUE CRAVING INPUT
Uncertainty is the starting state, not a problem.
The user can begin with an incomplete request. ChoiceFlow extracts workable constraints without requiring a perfectly structured prompt upfront.
SCREEN 02 · SEE · UNDERSTOOD AS
The cheapest moment to fix a misunderstanding.
Before recommending anything, the system exposes what it understood as editable criteria. Correcting an interpretation here prevents the wrong recommendation from carrying downstream.
SCREEN 03 · ONE FOCUSED RECOMMENDATION
Decision support means narrowing the choice.
Instead of returning a grid of options, the agent commits to one recommendation while preserving the information and controls needed to evaluate or change it.
SCREEN 04 · THE "WHY THIS? LAYER
Separating what you said from what it guessed.
The rationale separates explicit input from matched criteria, assumptions, and avoided options. Users can see which parts came from them and which came from the system.
SCREEN 05 · STEER · REFINE WITHOUT RESTARTING
Refine the decision without restarting it.
A correction updates the recommendation in place while preserving previously established context. The system also explains what changed and why.
WORKING PROTOTYPE
Don't take my word for it. Try it.
I built the flow as an interactive browser prototype to test the four-beat model end to end. Nothing is ordered, saved, or remembered.
DEEP DIVE
The Decision Receipt took three versions.
The Decision Receipt is the final trust checkpoint before action. I iterated on how much information users needed to review without turning confirmation into another wall of complexity.
VERSION 1 · THE LEGAL DISCLAIMER
Honest and unreadable. Everything was exposed, but the hierarchy made critical information difficult to scan. Transparency without prioritization became noise.
VERSION 2 · THE OVER COMPRESSION
Scannable, but it buried the two things users most need at the point of commitment: Collapsing assumptions and memory improved scanability, but hid exactly the information that required explicit review.
VERSION 3 · THE RECEIPT
The receipt. The final version separates the request, recommendation, assumptions, changes, and memory into a scannable record immediately before confirmation.
THE RECEIPT AS A SYSTEM COMPONENT
The receipt needed to work beyond one scenario.
I documented the Decision Receipt as a reusable component with defined anatomy, states, and rules of use. The goal was to preserve the same trust checkpoint as actions, assumptions, and memory states changed.
DECISION RECEIPT · ANATOMY
STATE · HIGH CONFIDENCE
Compact by default
Assumptions remain available without competing with the primary decision.
STATE · LOW CONFIDENCE
Leads with uncertainty
The system surfaces what it is unsure about before presenting a recommendation.
STATE · CONFLICTING CONSTRAINTS
Make the tradeoff explicit
When every constraint cannot be satisfied, the receipt identifies what changed and why.
STATE · MEMORY MOMENT
Memory requires permission
Anything the system proposes to remember is separated from the immediate action and explicitly approved.
STATE · POST EDIT
Preserve what changed
After refinement, the receipt distinguishes the updated decision from the user's original request.
Rule of use: the receipt appears at any boundary where the system transitions from suggesting to acting: ordering, saving, remembering, spending.
EDGE CASES
Designing the hardest moments first.
The interaction model also needed rules for moments when the system was wrong, uncertain, or unable to satisfy the request.
01
The AI gets it wrong
If the system misreads “comforting,” the interpretation surfaces before recommendation as an editable criterion. Correction happens before the error compounds downstream.
02
Confidence is low
When intent is genuinely ambiguous, the system asks one targeted clarifying question rather than presenting uncertain inference as fact.
03
Constraints conflict
When every constraint cannot be satisfied, the system names the tradeoff, identifies which constraint it relaxed, and offers an alternative.
04
Safety-adjacent assumptions
Safety-critical information is never inferred from behavioral patterns. Dietary restrictions, allergies, and similar constraints require explicit user input before they influence an action.
pattern transfer
The trust checkpoint extends beyond ordering.
The Decision Receipt is designed around the boundary between recommendation and action, making the pattern applicable wherever an agent can create a consequential change.
Benefits Enrollment
Surface assumptions before a consequential selection is submitted.
Travel Booking
Show what was optimized and what changed before money moves.
Agentic Checkout
Review the action, assumptions, and memory before purchase.
Subscriptions and Finance
Show what changes, what persists, and what can be reversed before confirmation.
WHAT'S NEXT
The model still needs to earn its friction.
01 · CORE TRADEOFF
Transparency has a cost.
Every checkpoint adds friction. The open question is how much visibility users need before an action, and when that visibility can safely stay one tap away.
02 · INTERACTION RISK
Reflection can feel like latency.
The “See” step creates a deliberate pause before recommendation. I’d test whether that pause increases confidence enough to justify the added time.
03 · NEXT TEST
Put the model in front of users.
The next step is testing where people hesitate, what they skip, which assumptions they correct, and whether the Decision Receipt changes confidence before action.