DEV Community: rohit raghuvansh

Designing Error States for AI Products: A UX Deep Dive

rohit raghuvansh — Thu, 09 Jul 2026 04:04:33 +0000

Seven. That's how many publicly logged AI errors researchers counted in Q1 2024, the kind serious enough to make it into an incident tracker: wrong medical advice, fabricated legal citations, that sort of thing. By Q1 2026 that number was 226. Thirty two times higher, in two years, while the underlying models got objectively more capable on every benchmark that matters.

That gap is the whole problem. Models are getting smarter and failing more often in ways users actually notice, because more of them are shipping into more products, touching more edge cases, in front of more people who never signed up to be QA testers. Traditional software fails in predictable, discrete ways: a null pointer, a 500 error, a timeout. You write a try/catch and move on. AI products fail continuously, probabilistically, and often while sounding completely confident about it. That's a UX problem before it's an engineering problem, and most teams are still designing for it like it's 2019.

Here's what the data and the pattern libraries actually say about handling it.

Four failure modes, and only one of them looks like a bug

Most design systems have one error state: something broke, show a red banner, offer a retry button. AI products need at least four, because the failures aren't the same shape.

Hallucination. The system generates false information and presents it with the same tone and formatting as true information. Nothing crashes. No error code fires. The output just isn't real, and a user who doesn't already know the answer has no way to tell.

Timeout and latency collapse. Long-running inference, tool calls, or multi-agent chains can stall well past what a normal API user tolerates. Where a REST call fails in 200ms, an agent workflow can hang for 30 seconds before you know anything went wrong.

Partial results. A multi-step task completes 3 of 5 subtasks and stalls on the rest. Traditional software treats this as failure. AI products need to treat it as a different kind of success, one that requires very deliberate framing.

Low-confidence ambiguity. The system understood the request but isn't sure which of several interpretations is right, and guesses instead of asking.

Only the second one, timeout, resembles a failure state a pre-AI design system already knows how to handle. The other three require new patterns, and treating all four as "just show an error" is where most AI product UX breaks down.

Confidence is not accuracy, and your interface can't pretend otherwise

The most dangerous failure mode in production AI systems isn't the system being wrong. It's the system being confidently wrong, in a way that looks identical to the system being confidently right.

Look at how the major assistants already handle this, because the pattern is more consistent than you'd expect. High-confidence outputs (roughly 90%+ by the model's own internal signal) get delivered as direct statements or immediate actions, "Setting alarm for 7 AM," no hedging. Medium-confidence outputs (60-89%) get softened with a verification prompt: "This seems likely, but you may want to double check." Low-confidence outputs (under 60%) get an explicit disclaimer: "I'm not sure about this, you should verify with current sources."

Three tiers, three visual and linguistic treatments. That's the minimum viable pattern. What most teams skip is the part where the interface actually surfaces which tier it's in, instead of letting every response look identical regardless of how uncertain the model actually was internally. If your product has access to a confidence score and isn't using it anywhere in the UI, you're sitting on a signal that could prevent a real number of bad outcomes, and just not showing it to anyone.

Ambiguity handling follows the same logic. When Siri can't confidently resolve a request, it doesn't guess and hope: it says "I found several options" and shows a list, or asks a direct clarifying question. That's a deliberate design decision to trade one extra tap for a much lower chance of doing the wrong thing. Most AI chat interfaces default to guessing instead, because a clarifying question feels like friction. It is friction. It's also usually cheaper than the alternative.

A useful 80% answer beats a useless 0% answer

When part of a multi-step AI task fails, the instinct in traditional engineering is to fail the whole operation and surface one clean error. That instinct is wrong here, and the research on agent failure handling is blunt about why: graceful degradation means the system answers with what it has and tells the user what it couldn't get, and that's the difference between a useful 80% answer and a useless 0% answer.

Concretely, that means three things at the interface level. First, streaming matters more than people give it credit for: a response that renders token by token can deliver real value even if the connection drops before the final sentence, where a response that appears all at once has nothing to show for a failure at the 90% mark. Second, partial completions need explicit framing, not silence: "Completed 3 of 5 steps, the pricing lookup failed, here's what I have" is a fundamentally different user experience than the same output with no caveat attached, even though the underlying data is identical. Third, retries should default to resuming from the failure point, not restarting the whole chain, because nothing erodes trust in an agentic product faster than watching it redo work it already finished successfully.

The pattern that keeps showing up in agent-system postmortems is connection recovery through automatic reconnection with exponential backoff, paired with a visible status indicator so the user isn't left guessing whether the system is still working or just silent. Silence is the one state users trust the least, more than an explicit error message.

Recovery patterns worth stealing

Across the products that handle this well, a small set of recovery patterns repeat, and they're worth treating as defaults rather than reinventing per feature.

Plain-language explanations beat error codes every time; "the pricing service didn't respond in time" tells a user something actionable, "Error 504" does not. Pairing that explanation with 2 to 3 concrete next steps, retry now, wait in a queue, or fall back to a simpler mode, gives users a path forward instead of a dead end. Surfacing what succeeded before what failed matters too: leading with the win and following with the gap keeps the interaction from feeling like a wholesale failure when it mostly wasn't. And for anything irreversible, a generated email, a filed ticket, a code change, a confirmation step before the action fires is worth the extra click, because AI systems fail exactly the times you didn't expect them to.

None of this is exotic. It's mostly discipline: building four failure states instead of one, wiring confidence signals into the interface instead of hiding them, and treating partial success as its own state rather than a lesser form of failure. The teams getting called out publicly for bad AI UX right now aren't failing because their models are worse. They're failing because their error states were designed for software that doesn't fail the way this software fails.

👨‍💻 Connect With Me

Rohit Raghuvansh
💡 UX Thinker · AI Builder · Making complex tech human-centered

Connect & Follow

LinkedIn — Rohit Raghuvansh

📢 Found This Article Helpful?

If this article added value to your learning journey:

✅ Share it with your network ✅ Bookmark it for future reference ✅ Follow for more

Keep Learning. Keep Building. Keep Growing. 🚀

RAG Systems Explained With Diagrams: What Every Tech Writer Should Know

rohit raghuvansh — Wed, 08 Jul 2026 03:56:07 +0000

RAG Systems Explained With Diagrams: What Every Tech Writer Should Know

Ask a product team what RAG stands for and you'll get a confident answer within two seconds. Ask them to sketch what actually happens between the moment a user types a question and the moment an answer shows up on screen, and the room goes quiet. That gap, between knowing the acronym and understanding the mechanism, is where most bad product decisions about AI search get made.

Retrieval-Augmented Generation isn't a single model or a single feature. It's a pipeline with several distinct stages, and each stage fails in its own particular way. If you write documentation, specs, or user-facing copy for a product that touches RAG, you need the mechanism, not the buzzword.

So What Is RAG, Really?

Here's the simplest way to think about it: a language model only knows what it learned during training, plus whatever you hand it in the prompt. RAG is the system that decides what to hand it.

When someone asks a question, the system doesn't just send that question straight to the model. First it searches a knowledge base, usually a vector database, for chunks of text that are semantically related to the question. Those chunks get stuffed into the prompt alongside the original question. Only then does the model generate an answer, now grounded in whatever text got retrieved.

That's the whole idea: retrieval before generation, instead of generation alone. It sounds simple. The complexity lives entirely in how well the retrieval step actually finds the right text.

The market has caught up to this idea fast. The RAG market was valued at roughly $3.33 billion in 2026 and is projected to reach $81.51 billion by 2035, growing at a compound rate above 40% a year. Enterprise adoption is following the same curve: about 80% of enterprise software developers now say RAG is the most effective way to ground a language model in factual data, and roughly 65% of Fortune 500 companies are piloting RAG-based internal knowledge bases right now. Companies that deploy it well are reporting 30 to 70% efficiency gains in knowledge-heavy workflows, the kind of work that used to mean digging through wikis and shared drives by hand.

So why, with all that investment, do RAG answers still go wrong so often?

Where the Pipeline Actually Breaks

Here's a finding that surprises most people the first time they hear it: when a RAG system produces a bad answer, the retrieval step is at fault about 73% of the time, not the generation step. The model isn't usually the weak link. The search is.

That reframes the whole problem. Teams spend months tuning prompts and swapping models, when the actual defect is upstream: the system searched the knowledge base and pulled back the wrong chunks, or fragments of the right chunk with the middle cut off.

There's an even stranger failure mode buried in the research: cases where the system retrieves exactly the right document, hands it to the model, and the model still answers incorrectly. Researchers don't fully agree on why this happens. Leading theories point to attention drifting toward irrelevant tokens in the context window, or the model averaging across conflicting signals when multiple retrieved chunks disagree with each other. Retrieval isn't the only place things break. It's just where they break most often.

This is exactly why teams evaluating RAG products need a way to talk about failure precisely instead of just saying "the AI got it wrong." A framework called RAGAS breaks evaluation into four measurable dimensions: faithfulness (does the answer avoid contradicting the retrieved text), answer relevancy (does it actually address the question), context precision (how much of what got retrieved was useful), and context recall (did retrieval miss something important that existed in the knowledge base). Writing about a RAG feature without naming which of these four is failing is like writing a bug report that just says "it's broken."

Chunking: The Decision Nobody Documents

If retrieval is where most failures happen, chunking is where most retrieval failures start. Chunking is the process of breaking a knowledge base into pieces small enough to search and embed individually. Get the chunk size wrong and everything downstream inherits the problem.

Fixed-size chunking is the naive default: split every document into blocks of, say, 500 tokens, regardless of what's in them. It's fast to implement and it's also how you end up with a chunk that ends mid-sentence, or a table split across two unrelated fragments, or a code function cut in half. A 2026 benchmark found that recursive splitting around 512 tokens hit roughly 69% end-to-end accuracy, the best result of any single strategy tested in isolation, but "best single strategy" and "good enough" aren't the same thing.

Semantic chunking tries to fix this by splitting where meaning actually shifts. It computes embeddings sentence by sentence and starts a new chunk when the similarity between adjacent sentences drops below a threshold, instead of counting tokens blindly.

The pattern that's become the default in production by 2026, though, is hierarchical chunking. It keeps small chunks for precise matching and larger parent chunks for context, resolving a real tension: small chunks are easier to search accurately, but large chunks give the model more surrounding context once something is found. You retrieve on the small piece and hand the model the bigger piece it belongs to.

One more myth worth killing: chunk overlap, the practice of duplicating 10 to 20% of text between adjacent chunks so context isn't lost at the boundary, has long been treated as free insurance. A systematic analysis published in January 2026 found that overlap produced no measurable accuracy benefit in several test sets and only added indexing cost. The lesson for anyone documenting or spec'ing a RAG system: don't inherit best practices as gospel. Test them against your own queries.

What This Looks Like in Production

None of this is theoretical. GitHub Copilot's retrieval architecture has run in production on AWS for eight months, serving around 2,000 active developers across three enterprise deployments, referencing internal documentation and code context alongside the model's training data. A marketing analytics SaaS company built hybrid retrieval, combining vector search with traditional keyword search (BM25), over two million documents, then added a reranking step. The result: a 42% drop in irrelevant citations, with latency held to 900 milliseconds at the 95th percentile after precomputing query rewrites and batching the reranking calls.

Notice what both examples have in common. Neither one is "add a chatbot." Both are closer to "rebuild the search layer, then let the model speak from it." That's the real shape of a RAG project, and it's worth saying plainly in a spec or a stakeholder update, because it changes the timeline and the skill set the project actually needs.

The enterprise RAG platform market has split into three distinct layers as a result: turnkey platforms like Glean or Vectara that you buy and configure, cloud-native services tied to a specific hyperscaler like AWS Bedrock Knowledge Bases or Azure AI Search, and fully custom infrastructure assembled from open frameworks. Picking between those three is a build-versus-buy decision with real tradeoffs in control, cost, and how fast you can ship, and it deserves to be treated as one instead of getting bundled into a vague "add AI search" ticket.

If you take one thing from all this: the next time someone says a RAG feature "hallucinated," ask which stage actually failed. Was it retrieval pulling the wrong chunks? A chunking boundary that split the answer in half? Or generation genuinely inventing something despite good context? Those are three different bugs with three different fixes, and conflating them is how RAG products stay broken longer than they need to.

👨‍💻 Connect With Me

Rohit Raghuvansh
💡 UX Thinker · AI Builder · Making complex tech human-centered

Connect & Follow

LinkedIn — Rohit Raghuvansh

📢 Found This Article Helpful?

If this article added value to your learning journey:

✅ Share it with your network ✅ Bookmark it for future reference ✅ Follow for more

Keep Learning. Keep Building. Keep Growing. 🚀

How to Design Chat Interfaces That Don't Frustrate Users

rohit raghuvansh — Tue, 07 Jul 2026 12:38:24 +0000

Open any product roadmap in 2026 and there's a chat box on it somewhere. Support, onboarding, search, even settings are getting rebuilt as "just ask." The problem is that most teams ship the chat bubble and skip the interface design underneath it. The result is a box that looks simple and behaves like a black hole: you type something in, and you have no idea if it heard you, understood you, or is about to waste your afternoon.

Chat interfaces don't fail because the model is bad. They fail because of the same handful of UX gaps, over and over: silence where feedback should be, errors that don't help, threads that lose context, and inputs that assume you only ever want to type one line of plain text.

The silence problem: loading states are trust states

Every chat product has a moment between "user hits send" and "response appears." How you fill that gap decides whether people trust the tool at all.

The data on this is blunt. Tidio's 2026 research found that 82% of customers expect an instant response, and abandonment climbs roughly 7% for every additional second of delay. Without a typing indicator or status cue, users don't conclude "it's thinking." They conclude "it's broken," and they either resend the message or leave. For natural-feeling back and forth, end-to-end response time needs to stay under about 800 milliseconds. Anything slower needs to be dressed up with feedback, or it reads as a stall.

The fix isn't making the model faster. It's making the wait legible. A typing indicator is the floor, not the ceiling. Better patterns show what stage the system is in: "searching your documents," "checking three sources," "drafting a reply." That's not decoration, it's the same reason a progress bar with steps feels shorter than a spinner with none. Users tolerate latency they can interpret. They don't tolerate latency they can't explain.

If your product routes to different backends (a fast cached answer versus a slow agent call), the loading state should say so. A generic spinner treats a two-second lookup and a twenty-second agent chain the same way, and that mismatch is where trust erodes fastest.

When it doesn't understand you: error states that keep people moving

Traditional software fails loudly and specifically: a red border, a field-level message, a clear next step. Chat interfaces fail quietly and vaguely, because natural language input has no field to underline. "I didn't understand that" is the chat equivalent of a 500 error with no stack trace.

The fix is specificity. A clarifying question beats a generic failure every time: "Did you mean X or Y?" keeps the user in motion. "I didn't understand that" sends them looking for the exit. The same logic applies to malformed input: "That email doesn't look quite right, did you mean gmail.com instead of gmal.com?" solves the problem in the same breath it names it.

There's a second failure mode that's worse than a bad error message: no way out of the conversation. Bots without an escape route (to a human, a search fallback, or a structured form) turn a single misunderstanding into abandonment within two or three failed exchanges. The conversation the user can't escape, and has to restart from zero by repeating everything they already said, is worse than the form the chatbot replaced.

Four mistakes account for most of the failures here: dumping a wall of text instead of one idea per message, giving the bot an over-humanized personality that sets expectations it can't meet, leaving users unsure what the system can even do, and, again, no escape hatch. Fixing the escape hatch alone removes most of the worst outcomes, because it turns a dead end into a recoverable moment.

Threading and memory: don't make people repeat themselves

Long conversations create a structural problem plain chat UI wasn't built for: as the thread grows, earlier context becomes invisible, and users can't tell what the system still remembers. Visual separators, timestamps, and light indentation for replies help, but the deeper question is whether you need branching threads at all.

Full threading, with conversation branching and merge logic, is a real pattern for multi-agent or research-heavy tools where a user genuinely explores parallel lines of inquiry. But for most SaaS products, that's more complexity than the use case needs. A linear conversation, backed by solid history and search, gets the same job done with a fraction of the interaction cost. The mistake isn't picking linear over threaded, it's picking threaded because it looks sophisticated rather than because the workflow requires branching.

Where this shows up concretely: a user references something from ten messages ago, and the system either has to re-derive it or admit it lost the thread. Products that handle this well summarize and surface prior context instead of hiding it, so the user never has to re-explain themselves. Products that handle it badly ask the same qualifying questions twice in one session, which reads as the system not paying attention.

Input affordances: chat isn't only text

The "input box" in most chat UIs is still a single-line text field with an ambitious name. But conversational interfaces increasingly need to accept more than typed sentences: images, file attachments, voice, and structured selections all need a home in the same input surface.

This matters for a concrete reason. Intercom's data on conversational lead-qualification flows found 35 to 40% higher completion rates compared to traditional multi-field forms, largely because the input adapts to what's actually being asked rather than forcing every answer through a keyboard. A well-designed chat input offers quick-reply chips for constrained choices, drag-and-drop or paste for images, and a visibly distinct treatment in the thread so a pasted screenshot doesn't get flattened into "user sent a message."

The rule of thumb: if the answer is naturally a choice from a short list, don't make the user type it. If the answer is naturally visual, don't force it through text. The input should flex to the question, not the other way around.

Putting it together

None of these fixes require a better model. They require treating the chat window like the interface it is, one with states, failure modes, and affordances, rather than a text field bolted onto an AI endpoint. Show your work while the system thinks. Fail specifically, and always leave a way out. Don't add threading complexity the workflow doesn't need. Let the input match the question. Do those four things and the "just ask" interface stops being a black hole and starts being something people actually trust.

👨‍💻 Connect With Me

Rohit Raghuvansh
💡 UX Thinker · AI Builder · Making complex tech human-centered

Connect & Follow

LinkedIn — Rohit Raghuvansh

📢 Found This Article Helpful?

If this article added value to your learning journey:

✅ Share it with your network ✅ Bookmark it for future reference ✅ Follow for more

Keep Learning. Keep Building. Keep Growing. 🚀

Model Context Protocol Explained for Designers and PMs

rohit raghuvansh — Mon, 06 Jul 2026 04:11:03 +0000

Model Context Protocol Explained for Designers and PMs

Someone on your engineering team said "we're adding an MCP server for that" in standup, and you nodded like you understood. You didn't, and that's fine, because most of what gets written about MCP is written by developers, for developers, full of JSON snippets and SDK references that tell you nothing about what it means for your product.

Here's the plain version: Model Context Protocol is quietly becoming the wiring standard for how AI agents connect to the rest of the software you already use. If you're a PM scoping an agentic feature or a designer trying to figure out what's actually possible, you need the concept, not the code.

What MCP Actually Is

Think about USB-C for a second. Before it existed, every device had its own charging cable, its own port shape, its own adapter. Then one standard showed up and suddenly your laptop, phone, and headphones all plugged into the same kind of port. MCP is that idea applied to AI.

Before MCP, if you wanted an AI model to read your company's Notion docs, check Slack, and create a Jira ticket, someone had to build three separate custom integrations, each with its own authentication, its own data format, its own maintenance burden. Multiply that across every tool and every AI product your company ships, and you get a combinatorial mess: N tools times M AI products equals N times M custom connectors, each one fragile and none of them reusable.

MCP replaces that mess with three defined roles. The Host is the application the user actually sees, something like Claude Desktop, an IDE, or a custom agent your team built. The Client lives inside the Host and manages the connection to one specific server. The Server is the external program, maybe a Slack integration or a database connector, that exposes what it can do in a standard format the model understands.

Once a server speaks MCP, any MCP-compatible host can use it without custom code. Your Slack connector doesn't need to be rebuilt every time a new AI tool wants to talk to Slack. It just needs to speak the protocol once.

The Three Things a Server Can Actually Offer

This is the part that matters most for product thinking, because it defines the shape of what your agent can do.

A server exposes three kinds of capability. Tools are actions the model can take: send a message, create a record, run a query, book a meeting. These are the things that make an agent feel like it's actually doing work instead of just talking about it. Resources are data the model can pull in as context: a file, a customer record, a document, a support ticket. This is how an agent grounds its answers in your actual company data instead of guessing. Prompts are reusable templates the server provides, a standardized way of telling the model "when someone asks about refunds, approach it this way." This is less visible to users but it's how organizations bake their own playbooks into how an agent behaves.

When you're scoping a feature and an engineer says "we can expose that as an MCP tool," what they mean is: the model will be able to actually perform that action, not just describe it. That distinction should change how you write the spec. A chatbot that can tell you your order status is a resource problem. A chatbot that can cancel your order is a tool problem, and it needs a completely different level of confirmation UX, error handling, and audit logging.

Why This Is Showing Up on Your Roadmap Whether You Asked For It Or Not

MCP isn't a niche developer preference anymore. Since Anthropic introduced it in late 2024, the ecosystem has grown at a pace that's genuinely unusual even by AI standards. By March 2026, the protocol was seeing roughly 97 million monthly SDK downloads, a 970x increase in about 18 months, with the official MCP registry tracking more than 9,600 active servers. Fortune 500 enterprise adoption has reportedly reached around 28% in under two years, and analysts estimate close to a third of enterprise application vendors will ship their own MCP server sometime in 2026.

More concretely, the tools your company probably already uses have first-party MCP servers now. Slack's server lets an agent search threads and post updates. GitHub's official server lets an agent read repos, open issues, and submit pull requests. Notion shipped a server that lets an agent read, write, and search across your workspace. Zapier's MCP server acts as a bridge to thousands of other apps, so instead of waiting for a native integration, a team can often get "close enough" connectivity immediately.

For product teams, this changes the build-versus-connect calculus. A feature that once required a dedicated integration sprint might now be a matter of wiring up an existing MCP server. That's good news for velocity. It also means the differentiation in your product is shifting away from "we connected to Salesforce" (increasingly commoditized) toward how well you design the experience around what the agent does with that connection: the confirmations, the context it shows, the way it recovers when something goes wrong.

The Questions You Should Be Asking Before You Ship

Here's the part that doesn't show up in the marketing copy. MCP servers are, by design, giving a model the ability to take real actions and pull in real data, and that creates a genuinely new risk surface that product and design decisions directly affect.

Security researchers have flagged a handful of specific concerns worth knowing the names of, even if you're not the one fixing them. Over-privileged access happens when an agent is connected to a server with far broader permissions than the task requires, the equivalent of giving an intern the admin password because it was easier than setting up a limited account. Tool poisoning is when an attacker manipulates a tool's description or metadata to smuggle in hidden instructions the model might follow without the user ever seeing them. One analysis of open-source MCP servers found roughly 5.5% exhibited these kinds of attack patterns. Indirect prompt injection, where malicious instructions arrive embedded in a document or webpage the agent reads rather than in the user's own request, remains, in the words of one well-known security researcher, an issue the industry has known about for years without a convincing fix.

The 2026 update to the MCP spec introduced incremental scope consent, meaning a client can request only the minimum access needed for a specific operation rather than a blanket grant upfront. That's an engineering fix, but it's also a design opportunity. If your product asks a user to authorize "full calendar access" once during onboarding and never mentions it again, you've built the fragile version. If it asks, in context, "this agent wants to create one event on your calendar, allow it?" every time the stakes go up, you've built the version that survives an incident without losing user trust.

As a PM or designer, you don't need to architect the permission system. You do need to ask your engineering team, explicitly, what scope of access every MCP server connection actually grants, and whether the user has any visibility into that scope at all. That question alone puts you ahead of most teams shipping agentic features right now.

Where This Leaves You

MCP is infrastructure, and infrastructure is usually invisible until it breaks or until it unlocks something your competitors ship faster than you do. Understanding it at the level covered here, host, client, server, tools versus resources versus prompts, and the consent questions that come with real action-taking agents, is enough to sit in a planning meeting and ask the right questions instead of nodding along.

The teams that win the next round of agentic product design won't be the ones who understand the JSON-RPC handshake. They'll be the ones who understood early that a "tool" is a real action with real consequences, and designed the experience around that fact instead of discovering it after launch.

👨‍💻 Connect With Me

Rohit Raghuvansh
💡 UX Thinker · AI Builder · Making complex tech human-centered

Connect & Follow

LinkedIn — Rohit Raghuvansh

📢 Found This Article Helpful?

If this article added value to your learning journey:

✅ Share it with your network ✅ Bookmark it for future reference ✅ Follow for more

Keep Learning. Keep Building. Keep Growing. 🚀

The UX of AI Agents: Designing for Autonomy and Trust

rohit raghuvansh — Mon, 29 Jun 2026 10:11:54 +0000

The UX of AI Agents: Designing for Autonomy and Trust

Your agent works perfectly in the demo. Your users still don't trust it. Here's why, and what to actually do about it.

The question used to be "can AI do this?" In 2026, that question is largely settled. The harder question now is: "Can I trust AI to do this for me, without watching every step?"

Gartner projects that 40% of enterprise applications will embed task-specific AI agents by end of 2026, up from under 5% in 2025. That's a massive wave of agentic products about to land on real users. Most of them will fail the trust test, not the capability test.

This is a UX problem. And it's yours to solve.

Why AI Agents Break Traditional UX Assumptions

Traditional software does what you tell it, when you tell it. The user is always in control. The feedback loop is instant: click, then result.

AI agents operate on a completely different contract. You describe what you want, and the agent decides how to get there, taking multiple steps, using multiple tools, making micro-decisions you never explicitly authorised. The result might arrive 30 seconds later, or 5 minutes later, after a chain of actions the user never saw.

This breaks three UX assumptions that designers have relied on for decades.

Predictability breaks. Users can't anticipate what the agent will do next, because the agent is making judgment calls.

Reversibility breaks. Some agent actions like sending an email, booking a meeting, or submitting a form can't be undone. The stakes of a misstep are real.

Visibility breaks. The traditional feedback loop is gone. The agent works in the background, and silence feels like nothing happening.

When these three assumptions break, trust breaks too. And unlike a slow-loading page, a trust deficit is very hard to recover from.

Transparency Is a Design Surface, Not a Setting

The instinct of most teams is to hide complexity. Clean UI, minimal chrome, just show the output. This is exactly wrong for agentic products.

The "black box launch" is one of the most common failure patterns in agentic UX. A team ships an agent with a polished interface that shows inputs and outputs but nothing in between. Users see a spinner, then a result. They have no idea what happened. Because they don't know what happened, they can't verify the result. Because they can't verify it, they don't trust it.

What to build instead:

Reasoning panels are collapsible sidebars or inline sections showing the agent's step-by-step actions in plain English. Not a raw log. Something like: "Searched your emails for invoices from March, found 3 matching, summarised totals." Users rarely read this in detail, but knowing it exists dramatically increases confidence.

Action cards surface a brief confirmation before the agent executes anything consequential: "I'm about to send this email to your manager. Confirm or edit?" This single intervention point removes most of the fear associated with autonomous actions.

Confidence signals tell the truth about uncertainty. "I found 2 possible matches. Here's the one I think you meant, but check the other if this looks wrong." Uncertainty expressed honestly builds more trust than false confidence.

The key insight: transparency is not a feature you add at the end. It is a design surface you plan from the beginning, the same way you plan navigation or error states.

Control Surfaces: Give Users the Wheel Even When They Don't Need It

There's a real paradox in agentic UX. Users want agents to work autonomously, but they also want to feel in control. The trick is designing control surfaces that exist without interrupting.

Progressive autonomy is the most effective pattern here. Start the agent in supervised mode, where every significant action requires a quick confirmation. As the user sees the agent make good decisions consistently, let them unlock more autonomy. The agent now acts without asking for low-stakes tasks, but still surfaces high-stakes ones. This mirrors how you'd delegate to a new colleague: micromanage at first, then step back as trust is earned.

The override button should always be visible. Not buried in a settings menu. Visible, in context, at all times. "Stop" and "Undo last action" are not edge cases. They are the core of the trust contract. If a user knows they can always stop the agent, they are far more willing to let it run.

Sandbox mode is worth a dedicated mention for high-stakes workflows in finance, healthcare, or legal contexts. Let users run a simulation first: "Preview what this agent would do" before it actually does it. This converts the most sceptical users into willing adopters.

Designing for Failure, Because Agents Fail Differently

Traditional software fails with error codes. AI agents fail in much messier ways.

Ambiguous input is where most teams get surprised. The user said "send an update to the team." Which team? What kind of update? Traditional software throws a validation error. An agent might guess, and guess wrong. The design response: when the agent detects ambiguity, it surfaces a clarifying question before acting, not an apology after.

Partial results happen when an agent hits a permission wall or a service error halfway through a task. The wrong response is to fail silently or pretend the result is complete. The right response is to show exactly what was retrieved, mark what's missing, and give the user a clear path to resolve the gap.

Hallucination and low-confidence outputs are the trickiest failure mode. Unlike a 404 error, a hallucinated answer looks like a real answer. The design obligation is to make confidence levels visible at the output level, not hidden in a tooltip or a settings page. If the agent is uncertain, that uncertainty should be in the UI.

Timeout and abandonment will happen on long-running tasks. Design a clear recovery state: "Your agent paused on step 3 of 7. Resume or start over?" Users can tolerate interruption. They cannot tolerate losing their work invisibly.

The New UX Contract

For most of UX history, the designer's job was to make things usable, accessible, and satisfying to use. That contract has expanded significantly.

Designing agentic products now means owning accountability for the rules of engagement between human and machine. When should the agent act independently? When should it ask? When should it refuse entirely? These are not engineering decisions. They are design decisions with ethical weight.

Designers working on agentic products need to think about three things that were not in the job description before:

Consent architecture means asking what the user actually authorised, and whether they understood it when they did. An onboarding toggle labelled "Allow agent to manage my calendar" is not meaningful consent.

Auditability means users can review everything the agent did, after the fact. A full action log is not a developer tool. It is a basic user expectation for any autonomous system acting on their behalf.

Refusal design means thinking carefully about how the agent communicates what it cannot or will not do, without eroding the user's trust in the product overall.

This is genuinely new territory for most UX practitioners. It is also the most interesting design problem of the decade.

Closing Thoughts

The capability gap between humans and AI agents is closing fast. The trust gap is where the real work is.

Trust in agentic products is not built through marketing copy or onboarding tooltips. It is built through every design decision you make about transparency, control, and failure. Users will forgive an agent that makes a mistake and recovers well. They will not forgive one that fails silently.

The teams shipping trustworthy AI agents in 2026 will not necessarily be the ones with the most powerful models. They will be the ones who thought hardest about what users see, what they can control, and how the system behaves when things go wrong.

That is a UX problem. And it is one worth getting right.

👨‍💻 Connect With Me

Rohit Raghuvansh
💡 UX Thinker · AI Builder · Making complex tech human-centered

Connect & Follow

LinkedIn — Rohit Raghuvansh

📢 Found This Article Helpful?

If this article added value to your learning journey:

✅ Share it with your network ✅ Bookmark it for future reference ✅ Follow for more

Keep Learning. Keep Building. Keep Growing. 🚀