Designing AI-Native Products: UX Patterns for Agents, Chat and Non-Deterministic UI

TL;DR: Traditional UX rests on determinism - the same input produces the same output, so you can design a predictable flow and test it exhaustively. AI-native products break that assumption, and most of the hard design work follows from it. You are no longer designing a path; you are designing how a user calibrates trust in a system that is usually right and occasionally confidently wrong. That means designing for uncertainty, making verification cheap, sizing consequences to autonomy, and treating latency as material. It also means resisting the chat box, which is usually an admission that the harder design work has been skipped.

The Assumption That Quietly Breaks

Every interface pattern you know was developed for deterministic software. Click submit, the form submits. Click it again with the same data and it submits identically. This assumption is so foundational that it is rarely stated - it is simply what software is.

It underpins almost everything downstream. Usability testing works because you can reproduce a session. Error handling works because failures fall into enumerable categories. Progressive disclosure works because you know what is behind the disclosure. Undo works because state transitions are discrete and reversible. Onboarding works because you can teach a fixed model of how the system behaves.

AI-native products violate this at the core. The same prompt produces different outputs. Failure is not a category but a spectrum, and the most dangerous failures are the ones that look exactly like successes. There is no fixed mental model to teach, because the system's competence is uneven in ways that are not obvious from the outside.

This is not a small adjustment. It changes what the designer's job is. In deterministic software, you design the path from intent to outcome. In AI-native software, the path is generated at runtime, and your job becomes designing the conditions under which a user can correctly judge whether to trust the output. That is a genuinely different discipline, and most products currently shipping have not noticed.

Here is the mapping, before we get into specifics.

Deterministic assumption	What breaks	Pattern that addresses it
Same input, same output	Users cannot build a stable mental model	Show the system's interpretation before it acts
Failures are detectable	Hallucinations look identical to correct answers	Sources, citations, and cheap verification paths
Actions are discrete and reversible	Agents take many actions with varied consequences	Blast-radius-aware permission and undo
Response is instant or has a known duration	Latency is variable and sometimes minutes long	Streaming, visible reasoning, interruptibility
Capability is discoverable from the UI	A text box implies unlimited, uneven capability	Structured affordances over open prompts
Correctness is binary	Output can be plausible, partial, or subtly wrong	Confidence signalling and graceful degradation

A note on scope: this post is about designing products that are themselves AI-powered. If you are looking for how designers use AI in their own workflow, that is a different subject and we cover it in AI in product design.

Chat Is Usually the Wrong Default

Let us start with the most common mistake, because it is the one costing companies the most.

Since 2023, the reflexive response to "we should add AI" has been to add a chat box. It is easy to build, demos well, and feels modern. It is also, for most products, the worst available interface, and the reason is straightforward.

A text box is an affordance that promises everything and specifies nothing. A blank input with a blinking cursor tells the user the system can do anything - which is false - while giving no indication of what it actually does well. Users respond in one of two ways: they ask for something outside its competence, get a poor result, and conclude the feature is useless; or they do not know what to type at all and never return. Both are churn, and neither shows up as a bug.

Compare this with a well-designed conventional interface, where the available actions are visible. A toolbar is a capability statement. A blank prompt is a capability question, and you are asking the user to answer it on your behalf.

Chat earns its place under specific conditions: when the input space is genuinely unbounded and cannot be enumerated, when the interaction is inherently conversational and multi-turn refinement is the point, or when your users are expert enough to have formed accurate intuitions about the system. General-purpose assistants qualify. Coding tools qualify, because the problem space is genuinely open. Most B2B SaaS features do not.

The stronger pattern for most products is AI inside existing structure. Rather than a chat box bolted to the corner, put intelligence where the work already happens: a suggested value inline in the field, a generated draft that appears in the editor as editable content, a ranked ordering of a list the user already scans, an anomaly flagged directly on the chart. The user does not need to learn a new interaction, discover capability, or phrase a request. The capability is where the task is.

The test worth applying: if you removed the chat interface and had to express this capability through your existing UI, what would you build? Very often that answer is the better product, and the chat box was an escape hatch from designing it.

Designing for Uncertainty Without Becoming Useless

Once you accept that output quality varies, you face a real tension. Communicate uncertainty too little and users over-trust. Communicate it too much and the product becomes exhausting and feels unreliable even when it is right.

Most teams resolve this badly, in one of two directions. Either every output carries a generic disclaimer - "AI can make mistakes" - which users learn to ignore within a day and which transfers responsibility without transferring information. Or the interface projects total confidence, which works until the first significant error and then permanently damages trust.

Better approaches:

Vary the surface by confidence, not just the label. Instead of a numeric score nobody can calibrate, change what the interface does. High confidence: apply the result inline and let the user move on. Medium: show it as a suggestion needing acceptance. Low: show it as one of several options, or decline and ask a clarifying question. The interaction cost communicates the uncertainty more effectively than any badge.

Show interpretation before action. One of the most underused patterns. Before the system acts on an ambiguous request, show what it understood in a form the user can correct - "I'll archive the 47 conversations from before March that have no replies" is checkable in two seconds. This converts a trust problem into a proofreading problem, which humans are far better at.

Be specific about what is uncertain. "I'm not certain about the Q3 figures because the source document was partially unreadable" is genuinely useful. "This may contain errors" is not. Localised uncertainty tells the user where to look; global uncertainty just adds anxiety.

Let the system decline. A model that answers everything is a model that fabricates. Designing a real path for "I don't have enough information" - and making that a visible, non-embarrassing outcome - is one of the highest-leverage trust decisions available, and one of the least implemented.

Failure UX When Failures Look Like Successes

Conventional error handling assumes errors announce themselves. The request fails, the validation catches it, the exception throws. You design an error state and move on.

AI failure is different in kind: the most consequential failures are indistinguishable from successes at the point of delivery. A fabricated citation is formatted exactly like a real one. An incorrect summary reads as fluently as a correct one. The user cannot detect the failure from the artifact, because the artifact looks right.

This means error handling stops being about error states and becomes about making verification cheap. If a user has to leave your product to check whether the output is true, they will not do it, and your product's real accuracy becomes whatever the model's accuracy is - unfiltered by any human judgement.

Practical patterns:

Cite at claim level, not response level. A source list at the bottom is nearly useless, because the user still has to work out which claim came from where. Attaching sources to individual claims, hoverable in place, makes spot-checking take seconds instead of minutes.

Show the retrieved context, not just the answer. For anything built on retrieval, let the user see the passage the answer came from. This single pattern catches a large share of errors, because the mismatch between source and summary is usually obvious once both are visible.

Make the original one click away. If the AI summarised a document, the document opens in place. Verification friction is the variable that determines whether verification happens at all.

Degrade to something useful. When the system cannot do the full task, returning partial value beats returning nothing. If it can extract eight of twelve fields, show the eight and flag the four. Falling back to plain search when generation fails keeps the product useful rather than broken.

Design the correction path as a primary flow. Users will fix outputs constantly - this is normal operation, not an edge case. Correcting a generated result should be at least as easy as accepting it. Teams routinely spend weeks on the generation flow and ten minutes on the editing flow, which is backwards relative to how much time users spend in each.

Human-in-the-Loop and Blast Radius

As products move from generating suggestions to taking actions, permission design becomes the central problem. Ask too often and you destroy the value of automation - if the user approves every step, they are doing the work with extra ceremony. Ask too rarely and you eventually take a consequential wrong action on someone's behalf.

The resolution is to stop treating approval as a single global setting and size it to blast radius: how bad is this if it is wrong, and how hard is it to reverse?

• Reversible and low-impact - drafting, sorting, tagging, filtering. Act without asking. Provide undo. Approval here is pure friction.
• Reversible but visible - posting internally, moving files, changing shared state. Act, then notify clearly with a prominent undo. Notification after the fact, not permission before it.
• Hard to reverse - sending external email, making payments, deleting data, modifying production. Confirm explicitly, showing precisely what will happen. This is where a preview of the interpreted action earns its cost.
• Irreversible and high-impact - anything with legal, financial, or safety consequence. Require deliberate confirmation with full detail, and consider requiring a second signal.

The key insight is that undo is usually better than confirmation. A confirmation dialog interrupts every action including the correct ones, and users learn to dismiss them reflexively - which means by the time an action genuinely warrants attention, the habit of dismissal is already trained. Undo costs nothing when the system is right and rescues the user when it is wrong. Design for reversibility first, and reserve confirmation for what genuinely cannot be undone.

This is the territory our work on Factory AI occupied - a product whose central design problem was making autonomous engineering feel safe to trust. Trust in an autonomous system is not created by a reassuring visual tone. It is created by the accumulation of small structural decisions: what the system shows before it acts, what it can undo, where it stops and asks, and how legible its work is afterwards. Get those right and users grant autonomy willingly. Get them wrong and no amount of polish compensates.

Agentic UX: Designing Long-Running Autonomous Work

Agents introduce a problem interfaces have rarely faced: the system works autonomously for minutes or hours, taking many steps, while the user is not watching.

Traditional progress indicators fail here. A spinner communicates nothing over a ten-minute task. A percentage bar is dishonest when the system does not know how many steps remain. And unlike a file upload, the user often needs to evaluate the work in progress, not just wait for it.

Show the plan before execution. For any multi-step autonomous task, present the intended sequence first and let the user amend it. Correcting a plan costs seconds; correcting completed work costs far more, and correcting side effects may be impossible.

Make progress semantic. "Step 3 of 7: searching the codebase for authentication handlers" tells the user the system is on track. "Working..." tells them nothing and invites cancellation out of anxiety. Semantic progress is also the cheapest debugging surface you can give a user.

Make it interruptible at any point. Users must be able to stop, and stopping must be clean - clear about what was completed, what was not, and what state things are in. An agent that cannot be safely interrupted will not be trusted with anything important, regardless of how good it is.

Design the summary as a first-class artifact. When a long task finishes, the user needs to understand what happened without replaying every step. A good completion summary states what was done, what was changed, what was skipped and why, and what needs their attention. This is often the most important screen in an agentic product and frequently the least designed.

Keep an inspectable trace. Users who want to audit the reasoning should be able to, without that detail being imposed on users who do not. Progressive disclosure applies cleanly here: summary by default, full trace on demand.

Latency and Streaming as Design Material

AI products are slow in a way modern web products have not been for a decade, and variably slow, which is worse. Treating that latency as a problem to hide is the wrong instinct. It is material to design with.

Streaming changed the perception of speed more than any optimisation. Token-by-token output is not faster in total, but it converts dead waiting into reading, and it lets the user abandon early when the answer is heading somewhere unhelpful. If your product generates text and does not stream, that is the highest-value change available to you.

Make the wait informative. Showing retrieval steps or reasoning while the system works does three things at once: it makes the wait tolerable, it builds understanding of how the system operates, and it surfaces errors earlier - a user who sees the system searching the wrong document can stop it immediately.

Be honest about duration class. Users behave differently for two seconds, thirty seconds, and ten minutes. Signal which one this is up front. A ten-minute task should tell the user to go away and be notified, not imply an imminent result.

Never block the interface on generation. Long-running work should be backgroundable. Forcing a user to sit on a loading screen for four minutes is a design decision, and a poor one.

Trust Calibration and Onboarding a Probabilistic Product

The goal is not maximum trust. It is calibrated trust - users trusting the system approximately as much as it deserves, on the specific tasks where it deserves it.

Both miscalibrations are costly. Over-trust means unverified errors reaching production, and the eventual discovery destroys the relationship. Under-trust means users double-check everything, which eliminates the value and eventually the usage.

Calibration is largely an onboarding problem, and conventional onboarding does not solve it. A feature tour teaches where buttons are. It cannot teach that the system is excellent at summarising your documents and unreliable at arithmetic across them - which is exactly what the user needs to know.

Onboard with real user data. A demo on sample data teaches nothing about performance on the messy, domain-specific, edge-case-ridden content the user actually has. Let the first run be on their material, where the result is meaningful.

Be explicit about the competence boundary. Stating plainly what the system is good at and what it is not is one of the strongest trust-building moves available. It seems risky and consistently reads as confidence rather than weakness. Users who know the boundary use the product more, not less, because they stop wasting attempts on the wrong tasks.

Let early failures be small. Structure the first sessions so that mistakes are cheap and visible. A user who catches a small error early calibrates correctly and continues. A user whose first error is a large one that surfaced late leaves.

Close the feedback loop visibly. Thumbs up and down widgets are near-worthless: the signal is coarse and the user sees no consequence. Better patterns capture the correction itself - when a user edits an output, that edit is the highest-quality training signal available. And when feedback changes behaviour, say so. "Got it, I'll use the shorter format going forward" makes the loop real; silent collection trains users that feedback is theatre.

Trust calibration also has a research dimension that is easy to skip. You cannot infer it from analytics, because over-trust and correct trust look identical in usage data. You have to watch people work and ask what they checked and why. Our guide to UX research methods covers the observational techniques that surface this.

Conclusion

Designing AI-native products is not a matter of adding a new component to an existing practice. The determinism assumption underneath conventional UX no longer holds, and most of the interesting work follows from that: designing for uncertainty rather than states, making verification cheap rather than making errors visible, sizing autonomy to consequence, treating latency as material, and building trust that is calibrated rather than maximised.

The single highest-leverage decision most teams face is resisting the chat box. It is fast to ship and it defers every hard question - what the system is actually good at, how the user knows, what happens when it is wrong. Those questions do not disappear; they get answered by the user, badly, on first contact.

If you are building a product where the model is the core and the interface is what makes it trustworthy, that is the problem we find most interesting. Tell us what you are building.

elysiumdesigns.in/intro

AI in Product Design: Hype vs Reality