Progress, Evidence, and Trust

Agentic systems can look productive while making no progress. They can stream tokens, open tools, revise plans, call APIs, and produce confident summaries without reducing the user’s uncertainty or changing the relevant state.

The reverse is also true. A system may appear stalled while waiting for an approval, reconciling an unknown effect, or running a slow verification step that matters more than all previous visible activity. If the product does not distinguish these states, users cannot supervise the work. They either over-trust the performance or interrupt the system at the wrong time.

Trustworthy UX does not mean making the system appear confident, friendly, or magical. It means helping people rely on the system in proportion to evidence, uncertainty, consequence, and their role in the task.

Thesis

Trustworthy agent UX should make the current state, material actions, sources, assumptions, uncertainty, limits, and completion evidence inspectable enough for the user’s decision, while avoiding false precision and persuasive explanations that exceed evidence.

The product should distinguish three ideas:

• Activity: the system did something.
• Progress: an unmet success condition was reduced or relevant state changed.
• Completion: accepted evidence supports the promised outcome.

The model may narrate activity. The product should ground progress and completion in accepted state, tool results, source records, checks, approvals, and human decisions.

Show the run state honestly

Users should know whether work is:

• created but not started;
• queued or admitted;
• running;
• waiting for the user;
• waiting for another person;
• waiting for a dependency, schedule, callback, or approval;
• blocked;
• partially complete;
• cancelled;
• failed;
• succeeded; or
• escalated.

These states should map to the runtime states in the architecture, but product language may be friendlier. The important rule is honesty. Do not show “working” when the system is waiting for user approval. Do not show “done” when verification is incomplete. Do not show “failed” when a useful partial result exists. Do not show “cancelled” as if no effect occurred when an in-flight action is still unknown.

WCAG 2.2 requires status messages to be programmatically determinable so assistive technologies can present important changes without stealing focus (W3C, 2023). Agentic status updates are not decoration. They are part of user control.

Build progress from success conditions

A good progress display answers:

• What goal is being pursued?
• What has been completed and verified?
• What is currently being attempted?
• What remains?
• What changed since the last update?
• What evidence supports that change?
• What is uncertain, blocked, or waiting?
• What can the user do now?

Avoid theatrical progress such as “thinking hard,” fake percentages, animated busyness, or long tool logs that look impressive but do not help the user act. For uncertain tasks, prefer milestone and evidence-based progress:

Goal: compare three vendors for SOC 2 evidence and data-retention fit.

Done:
- Found vendor-owned security pages for all three vendors.
- Verified SOC 2 availability for two vendors.

Current:
- Checking retention terms in primary documentation.

Blocked:
- Vendor C requires login for the trust portal.

Next user action:
- Approve using vendor-provided summary, or exclude Vendor C.

This is more useful than 72% complete unless the product can explain the numerator, denominator, and uncertainty behind that percentage. Percentages fit tasks with known units and comparable work. They mislead when discovery changes the plan.

Separate evidence levels

Not all evidence deserves the same visual or product weight. A source can be:

• user-provided;
• retrieved from a connected system;
• inferred by the model;
• generated as a draft;
• verified by a deterministic check;
• accepted by a human reviewer;
• read back from a system of record;
• stale or outside its freshness window;
• contradicted by another source; or
• unavailable.

The UI should preserve those distinctions where they affect decisions. A support agent’s recommendation based on policy text, current order state, and read-back confirmation is different from a recommendation based on a generated summary of old emails. A coding agent’s “tests passed” should identify which tests, under which command, with which failures or skips. A research agent’s “sources agree” should show which sources, publication dates, and claim limits.

Different tasks need different evidence:

Task type	Evidence users may need
Research	sources, publication dates, access dates, conflicts, unsupported claims, relevance limits
Coding	files changed, diffs, commands run, tests passed or failed, lint/build status, review state
Support	policy rule, customer facts, action staged or committed, refund ID, escalation reason
Operations	systems touched, approvals, logs, current state, rollback or compensation path
Personal productivity	calendars, recipients, drafts, messages sent, changes since approval
Procurement or risk	criteria, source authority, missing evidence, assumptions, reviewer acceptance

Show evidence at the level that helps the user decide. Raw traces can overwhelm; polished summaries can omit decisive facts. Use progressive disclosure: concise status first, then expandable sources, actions, checks, and records.

Explain decisions without inventing certainty

Microsoft’s human-AI guidelines recommend explaining what the system can do, why it did what it did, and how certain it is at appropriate times (Amershi et al., 2019). Google’s People + AI Guidebook likewise emphasizes mental models, explainability, and trust calibration (Google PAIR). For agents, explanation must include environmental evidence, not only the model’s rationale.

Useful explanations connect:

Goal -> evidence -> action or recommendation -> uncertainty -> next choice

Weak explanation:

I chose this option because it is best for your needs.

Stronger explanation:

I ranked Vendor A first because its current security page lists SOC 2 Type II,
the data-retention setting is configurable by workspace administrators,
and it supports the EU region requirement you set.
I did not verify the DPA because it requires account login.

Do not expose hidden chain-of-thought as if it were evidence. Users need the grounds for action: sources, observations, checks, assumptions, alternatives, rejected options, and limits. A generated explanation that cannot be tied to those records can become persuasion.

Preserve uncertainty in usable form

Useful uncertainty is specific:

• which fact is unknown;
• why it matters;
• what evidence was checked;
• which assumption is being made;
• how strong or weak the evidence is;
• what could change the conclusion;
• what action is safe while uncertain; and
• whether the user needs to decide.

Avoid vague disclaimers such as “AI can make mistakes” as the main control. They are true but weak. Prefer:

I found only vendor documentation for this API behavior; no independent implementation evidence is in the brief.

or:

The payment write timed out after dispatch, so the outcome is unknown until status is reconciled.

or:

This answer uses documents uploaded on July 18, 2026. It does not include policy changes after that date.

Confidence scores can help only when they are calibrated and meaningful to the user. A precise number with unclear basis can be worse than a plain limitation. A label such as “high confidence” should not mix source quality, model self-assessment, policy compliance, and user acceptance into one unexplained badge.

Explanations can also increase overreliance. A 2024 study found that explanations did not uniformly reduce reliance on incorrect AI recommendations (Cecil et al., 2024). The durable design lesson is to test whether users notice seeded errors, challenge unsupported claims, and make better decisions, not merely whether they report that the interface feels transparent.

Show material actions and effects

When the system uses tools or affects external state, users should be able to see:

• what was requested;
• what was allowed, denied, or staged;
• which identity or authority was used;
• what result came back;
• what state changed;
• what remains pending, partial, or unknown;
• what evidence confirms the effect;
• what action is next; and
• whether the user can undo, compensate, or escalate.

This does not require exposing every internal token, model message, or implementation trace. It does require preserving action provenance. A user should not have to infer from a final answer whether the system actually sent an email, filed a ticket, opened a pull request, submitted a refund, or only drafted text.

Action evidence should be especially clear at authority boundaries. If the system moved from “prepare” to “send,” “stage” to “commit,” or “recommend” to “decide,” the user should see the transition and its basis.

Design for the user decision

The right evidence density depends on what the user can do with it:

User decision	Evidence needed
Let work continue	Current state, remaining work, budget, blockers, expected next effect.
Approve an action	Target, data, authority, policy check, changes since last approval, reversibility.
Accept final result	Completion evidence, limitations, unresolved questions, artifacts, external effects.
Correct the task	Current assumptions, affected pending actions, old versus new scope.
Escalate or take over	Goal, state, evidence, attempts, partial or unknown effects, owner, deadline.
Audit later	Event trail, source provenance, approvals, versions, outcome evidence.

Progress views should therefore be role-aware. An end user may need a simple “waiting for your approval” card with the exact action. An operator may need queue age, dependency status, and unknown-effect count. A reviewer may need citations and diffs. A support manager may need customer impact and policy reason.

Do not dump the same raw trace on everyone. A trace is a production artifact. An evidence trail is a user-facing account of the material sources, actions, checks, assumptions, and unresolved limits.

Make completion an evidence claim

Use completion language carefully:

Label	Meaning
Done	Accepted evidence satisfies the product promise.
Ready for review	The system produced a candidate, but a person must accept it.
Partially complete	A subset is usable and the limits are clear.
Blocked	A named missing input, authority, dependency, or policy prevents progress.
Failed	The system ended without satisfying the promised outcome.
Escalated	Ownership moved to a person or another process.
Cancelled	An authorized stop was processed, with effect status reported.

Do not let the model’s statement “I completed the task” become the product state. Completion should reflect accepted outcome evidence from the control loop.

Completion evidence should be proportional to consequence:

• A brainstorming task may end with a draft and a note that no claims were verified.
• A research task may require sources, limitations, and unsupported claims.
• A coding task may require changed files, tests, and remaining failures.
• A support task may require policy match, committed action ID, and escalation record.
• A regulated decision may require a human decision owner, explanation, audit trail, and recourse path.

Avoid trust theatre

Trust calibration is not a trust-maximization exercise. Over-trust causes users to accept wrong or unauthorized work. Under-trust causes them to ignore useful automation or duplicate work manually. The product should help users see when reliance is warranted and when scrutiny is needed.

Common trust-theatre devices include:

• polished final text without source or action evidence;
• badges such as “verified” without explaining the verifier;
• fake precision in percentages or confidence scores;
• animated activity that masks waiting or failure;
• summaries that omit caveats, failed checks, or manual repair;
• hidden human intervention presented as autonomous success;
• generated rationales that sound like proof; and
• always-positive language that makes failure states feel dishonest.

Prefer evidence over reassurance. A calm “I could not verify this claim from primary sources” is more trustworthy than a confident answer with a generic disclaimer.

Failure modes

Busy-motion trust

The UI displays many steps, tokens, animations, or tool names, but users cannot tell what changed or what evidence exists.

Fluency as evidence

The final answer is polished, so the product treats it as verified. Sources, actions, checks, and state changes are missing.

False precision

The system shows a confidence percentage or progress bar that is not calibrated or meaningful for the task.

Trace dumping

The product exposes raw logs instead of decision-relevant evidence. Users cannot find the few facts they need.

Hidden waiting

The system appears to be working but is actually waiting for approval, a dependency, a timer, or a human handoff.

Overpersuasive explanation

Generated rationale makes the system sound more certain than the evidence supports.

Summary as completion

A generated recap says the work is done even though required checks, approvals, or external effects are unresolved.

Fieldbook guidance

1. Represent the current run state honestly.
2. Show progress as evidence against success conditions, not as activity volume.
3. Make material sources, actions, assumptions, checks, and state changes inspectable.
4. Preserve uncertainty and limits in specific, actionable language.
5. Use completion labels that match accepted evidence.
6. Adapt evidence density to the user’s decision, role, and consequence.
7. Test whether users calibrate trust and catch errors, not only whether they like the interface.

Checklist

• Can users tell whether work is running, waiting, blocked, partial, failed, escalated, cancelled, or done?
• Does progress show what changed, what remains, and what evidence supports the change?
• Are sources, actions, checks, assumptions, and state changes inspectable at the right level?
• Are unknown, stale, inferred, generated, human-accepted, and verified facts distinguished?
• Are tool actions and external effects visible enough for user control?
• Does the UI avoid fake percentages and unsupported confidence scores?
• Are status changes accessible to assistive technologies?
• Are completion labels tied to evidence rather than generated claims?
• Does the product show waiting, blocked, and unknown-effect states honestly?
• Has the team tested for overreliance, missed errors, and evidence comprehension?

References and how they are used

• Cecil et al., “The effects of AI explanations on human decision-making” - peer-reviewed evidence used to caution that explanations do not automatically prevent overreliance.
• Google People + AI Research, People + AI Guidebook - Google People + AI Research design resource used for mental models, explainability, feedback, control, and graceful failure; it is not evidence that any specific explanation UI prevents overreliance.
• Microsoft Research, “Guidelines for Human-AI Interaction” - peer-reviewed human-AI interaction paper supporting expectation setting, uncertainty, explanation, correction, and control.
• W3C, Web Content Accessibility Guidelines 2.2 - W3C Recommendation used for accessible status messages, input assistance, and operable controls.