Overview
How might we signal when the AI hits a real wall so people trust the product long term instead of calibrating to confident misses?
When silence or hedging would mislead
- Agent or tool flows where a blocked call, empty search, or low confidence is a real miss, not a loading state.
- Products where downstream users or systems need to handle failures differently from successes.
- High-stakes domains where invented completion erodes trust faster than an honest stop.
- Any surface paired with recovery: clear signal first, then retry, fallback, or human handoff.
When failure chrome would cry wolf
- Transient loading moments better served by skeletons than failure chrome.
- Soft hedges on every answer when the system did succeed; reserve failure UI for real blocks.
- Internal-only tooling where structured logs matter more than end-user failure copy.
States
Design the failure lifecycle, not only an error toast at the edge of a normal answer.
Attempting
The agent selected an action or retrieval path. Outcome is still unknown.
Failed
A tool, search, or policy blocked the path. The miss is named, not smoothed over.
Explained
Cause is visible when known: policy rule, rate limit, empty results, or low confidence.
Bounded
What did NOT happen is explicit: no write, no send, no charge, no fabricated result.
Recoverable
Next steps are offered: retry, edit inputs, wait, escalate, or talk to a human.
Resolved
The user acted or accepted the stop. The thread records the honest outcome.
Key UX elements
The parts that must be present for an honest miss to build trust.
Name the failure plainly.
Use a distinct status and title ("Action blocked", "Could not complete") so the miss is unmistakable.
Say why when you know it.
Policy, rate limit, empty search: a concrete cause beats a generic "something went wrong."
State what did NOT happen.
Explicit negatives ("Nothing was written", "No message was sent") prevent users from assuming silent success.
Offer a recovery path.
Retry, edit inputs, request approval, or escalate. Never leave a dead end after a real failure.
Stay factual, not cheerful.
Skip hedging and invented completion. Honest copy calibrates trust better than upbeat prose over a miss.
Anti-patterns to avoid
Cheerful hallucination that invents sources or “completed” tool results.
Generic “Something went wrong” with no cause or next step.
Same visual style as a normal answer, so users miss the failure.
Retry that loops forever without escalating or changing strategy.
How products use it
| Product | Implementation |
|---|---|
| Perplexity | States when search coverage is weak and leans on sources rather than invented claims. |
| Claude | Can decline or state uncertainty instead of fabricating when evidence is missing. |
| Cursor Agent | Surfaces blocked tool calls and failed steps in the agent trace. |
| ChatGPT | Shows clear tool or browsing failures rather than pretending the action succeeded. |
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Failure Disclosure" AI interface design pattern.
Pattern Definition:Frequently asked questions
What is failure disclosure in AI UX?
Failure disclosure means the product visibly names when it cannot answer, a tool failed, or confidence is too low, instead of covering the miss with confident-sounding text. It is a core honesty pattern for long-term trust.
How is failure disclosure different from error recovery strategies?
Failure disclosure is how the UI signals the miss to the user. Error recovery strategies define what the system does next (retry, fallback, escalate). Good products combine both: clear signal plus a recovery path.
What should a failure state include?
State what failed in plain language, why if known (empty search, rate limit, blocked tool) and what the user can do next (rephrase, attach context, retry, or talk to a human).