INQUIRING LINE

What proof would actually show people trust an AI agent to act for them, instead of just looking like trust?

What counts as clear data that users actually trust an agentic system?

This explores what kind of evidence would actually show that people trust an AI agent enough to let it act for them, and how that differs from evidence that the agent deserves that trust.


This explores what counts as real evidence that users trust an agentic system, as opposed to signals that only look like trust. The honest starting point is that the corpus has no clean, agreed measure of user trust in agents. What it has is something arguably more useful: a set of warnings about which kinds of data people mistake for trust, and some proposals for what to look at instead. The most practical framing comes from Should agentic AI autonomy expand based on earned trust?. It suggests letting an agent only analyze at first, then letting it act on low-risk tasks, then giving it full autonomy. Each step is unlocked by evidence of trust, not by time passing or features shipping. That puts the question exactly where you'd expect, though, because the proposal doesn't settle what the evidence should be.

One strong candidate is behavior, especially intervention behavior. Does perceived control matter more than actual control for AI trust? argues that people feel safe when they know they *could* step in, not when they're made to supervise constantly. That turns the question upside down. If someone rarely overrides the agent but clearly knows how to, that's a sign of trust. If someone rarely overrides it because they can't see how, that's just lack of access. The same logic runs through How can autonomous agents act safely within defined boundaries?, which sets explicit limits on what an agent may do partly so users aren't swamped by confirmation prompts. A user clicking 'approve' fifty times a day isn't showing trust. They're showing fatigue.

Here's the part you might not expect: a user's comfort and the agent's actual reliability are two separate things, and the data for one says little about the other. Should agent trust signals stay separate or merge together? notes that design libraries split trust signals into three types: showing the agent's process, showing how confident it is, and showing where its information came from. But research on trace interfaces finds that adding these signals doesn't make users' trust match the agent's real reliability. People can feel reassured by a display that tells them nothing true. On the system side, Can a correct outcome hide protocol violations in multi-agent systems? shows agents reaching correct answers while skipping required verification steps. How should we measure agent system performance beyond task success? shows that identical success rates can hide very different levels of reliability. So 'the user was happy and the outcome was right' is weak evidence on both counts.

The stronger evidence the corpus points to is a record the user can check. Should agent accountability be designed for end users instead of engineers? describes 'action receipts': plain-language records of what the agent did, styled like bank notifications, written for the person who handed off the task, not for engineers. Behind that consumer-facing layer, Can execution traces ground honest explanations of agent behavior? shows that explanations built from the agent's actual execution log catch unsupported claims that smooth, LLM-written explanations hide. What must auditors reconstruct to verify agentic workflows? lists what a full audit has to piece together: which agents talked to each other, which tools they used, which approvals they got, and whether records were changed afterward. Put together, the most credible evidence of trust is probably this: users can check receipts that are tied to real execution logs, and over time they choose to give the agent more scope.

One practical warning: trust that rests on rules the agent was simply told to follow is fragile. Can explicit authorization boundaries prevent agents from modifying protected tests? found that telling an agent not to modify protected tests didn't work unless its tools were also restricted. Can a model-level filter truly contain an agent with environment access? makes the same point more broadly. If users trust an agent because it 'knows the rules', their trust is resting on something that doesn't hold. Trust is better justified when the agent physically can't do the dangerous thing. What's missing from the corpus is real user research, such as studies tracking how people's delegation and override behavior changes over time. That gap is worth knowing about.


Sources 11 notes

Should agentic AI autonomy expand based on earned trust?

Yocco proposes three phases—analysis-only, low-risk autonomy, then full autonomy—each gated on evidence of user trust rather than elapsed time or feature completion. Each phase teaches users how the agent thinks before granting expanded decision authority.

Does perceived control matter more than actual control for AI trust?

Gunasekaran argues users need the felt ability to intervene in agentic AI systems to feel safe, not hands-on constant control. The design implication is that UX must make intervention capability visibly available and perceptible, even when users rarely exercise it.

How can autonomous agents act safely within defined boundaries?

OpenAI's Model Spec formalizes agent autonomy through structured scope records listing allowed tools, cost limits, and prohibited high-risk activities, mirroring software security's principle of least privilege while avoiding confirmation overload.

Should agent trust signals stay separate or merge together?

Design libraries name observability, confidence, and citations as separate trust patterns addressing different user questions about process, certainty, and provenance. Yet trace-interface research shows that building these patterns does not guarantee they calibrate trust accurately.

Can a correct outcome hide protocol violations in multi-agent systems?

Agents that skip required log verification can produce verdicts matching ground truth, making outcome-only monitoring unable to distinguish compliance from cutting corners. A correct result does not prove the protocol was followed.

Show all 11 sources
How should we measure agent system performance beyond task success?

Single task-success metrics obscure how agents achieve results across memory, context, and verification layers. Research shows identical success rates can mask enormous differences in efficiency, reliability, and deployment readiness—requiring harness-level benchmarks that measure trajectory, memory hygiene, and verification costs.

Should agent accountability be designed for end users instead of engineers?

The AI UX Playground glossary defines action receipts as bank-notification-style records for task delegators, not engineers. This positions transparency as a UX surface for non-technical users rather than an audit trail, with receipts operating after actions complete to enable verification.

Can execution traces ground honest explanations of agent behavior?

A framework converting execution traces into structured reports and faithful natural-language explanations reliably identifies unsupported claims, unjustified actions, and evidence gaps across multiple architectures and tasks, outperforming naive LLM-generated explanations that may sound coherent without grounding.

What must auditors reconstruct to verify agentic workflows?

Organizations can no longer rely on single human decisions or application logs. Effective audit of agentic workflows must establish which agents communicated, what information exchanged, which tools were invoked, what approvals were obtained, which policies applied, and whether records were modified afterward.

Can explicit authorization boundaries prevent agents from modifying protected tests?

Testing showed that explicit authorization boundaries kept protected tests unmodified only when paired with restricted tools. Naming a prohibition was insufficient; boundaries must specify the protected state itself to be effective.

Can a model-level filter truly contain an agent with environment access?

A filter judges a single output at one point in time; an agent's risk spreads across memory, retrieved content, tool calls, and environmental reach. Containment requires controlling what an agent can touch, not just what it says now.

Papers this line draws on 8

The research behind the notes this line reads — ranked by how closely each paper relates.