Building an AI Agent Is a Trust Design Problem

When I started building Modulyo, I ran into a problem I didn't expect. The AI underneath was capable. The logic worked. But early testers kept missing features that were sitting right there in the interface. They'd finish a session saying the tool was useful, for the one thing they discovered on their own, without realising it could do five other things that would have saved them an hour. I had built a capable AI agent and wrapped it in a UX that made its capability invisible. That's not a technical failure. It's a design failure.

The NNGroup's analysis of Qwen, one of China's largest AI agent platforms, arrived at four design lessons that every builder in this space should sit with. Not because they're surprising, but because they name something that's easy to skip when you're deep in building mode.

Why does discoverability matter more in AI agents than in any other product?

Discoverability is the gap between what an AI can do and what the user believes it can do. In traditional software, that gap closes over time: you explore the menu, read the tooltip, watch the onboarding video. In an AI agent, the capability is often open-ended and context-dependent. There's no menu. There's no finite list of actions. The user faces a blinking cursor and a blank field, and unless the design actively closes that gap, they'll use the tool for the one use case they already imagined — and nothing else.

Qwen addresses this by surfacing example prompts, capability cues, and contextual suggestions at the right moments. The lesson isn't that AI agents need better onboarding decks. It's that discoverability in AI is a continuous design challenge, not a one-time screen. Every session is potentially a first session for a capability the user hasn't found yet.

When I redesigned parts of Modulyo's creation flow, I stopped thinking about discoverability as an onboarding problem. It became a moment-by-moment question: does the user know what they could ask, right now, in this context? That shift changed where I placed effort in the interface.

What makes familiar interaction patterns so critical when introducing new AI capabilities?

Familiar patterns reduce the cognitive load required to trust an unfamiliar system. When someone opens an AI agent for the first time, they're carrying two uncertainties at once: what can this thing do, and how do I talk to it? Introducing entirely novel interaction paradigms to answer both questions simultaneously is a recipe for abandonment, not because users are incapable, but because you're asking them to learn a new language in a room they've never been in before.

Qwen leans on patterns users already know: conversation threads that feel like chat, structured forms that feel like familiar inputs, progress indicators that feel like loading states from any web app they've used. These aren't constraints on what the AI can do. They're trust accelerators. They let users spend their cognitive energy on the task rather than on decoding the interface.

The counterintuitive truth here is that the most capable AI agents often look the most familiar. The novelty is in what happens behind the interface, not in how the interface itself behaves. When I look at the AI products that have earned real adoption rather than demo applause, this pattern holds.

How should AI agents handle personal data, and why does the approach shape user trust?

The answer is simple and often ignored: data handling should be transparent, minimal, and under the user's control. In practice, most AI agents fail on at least one of these three dimensions.

Transparent means users can see what data the agent is using and when. Minimal means the agent doesn't collect or retain more than the task requires. Under control means users can choose what to share, and they can revoke that choice without losing access to the core tool.

Qwen's approach makes data usage visible at the point of interaction. When the agent accesses a data source, it signals this clearly rather than doing it silently in the background. This sounds like a small UX detail, but it has a disproportionate effect on trust. Silent competence unnerves people. Visible competence reassures them.

This is something I think about constantly with VelaCrew, my personal productivity app for Apple devices. The entire architecture is built around the idea that the user decides what the AI can see, and when. Not because the AI is untrustworthy by default, but because trust requires visibility. You cannot meaningfully trust a system you don't understand.

When is user control not a UX nicety but a product survival requirement?

User control becomes a survival requirement the moment the AI's decisions carry real consequences. If an agent is helping you draft a caption for a post, the stakes are low and control is a nice-to-have. If an agent is managing your calendar, sending messages on your behalf, or structuring your business decisions, control shifts from preference to necessity.

Qwen builds explicit confirmation steps into high-stakes actions. The AI proposes. The user approves. This sounds obvious, but the pressure to demonstrate AI capability often pushes builders in the opposite direction: automate everything, remove friction, let the AI do its thing. The result is an agent that impresses in demos and frightens in real use.

The right frame isn't how much can the AI do. It's how much should the AI do without asking. That boundary is different for every use case, every user, and every risk level. Getting it wrong in either direction damages trust: too much automation feels unsafe; too many confirmations feel patronising. The calibration is a product decision, not a UX afterthought.

These four lessons, discoverability, familiar patterns, data transparency, and user control, aren't a checklist. They're a theory of trust. AI agents fail not when they're not capable enough, but when the user can't form a mental model of what the agent can do, how it works, and where the human stays in charge.

The irony is that the more capable AI becomes, the harder this problem gets. Every new capability is another thing the user doesn't know exists. Another data source they might not realise is being accessed. Another action taken on their behalf without explicit approval. Capability without trust architecture is a product people demo but don't rely on.

I'll probably be thinking about this differently in six months. The field moves fast enough that any current framework has a built-in expiry date. But the core insight, that building an AI agent is as much a trust design problem as a technical one, feels like it has longer legs than any specific implementation.

If you're thinking about how UX philosophy applies to building alone, the post on what user research actually changes in a one-person operation is worth reading alongside this one.