Designing Agent-Based Experiences That Actually Help Users Finish Things

The trap: treating the agent like a chatbot

The first mistake most teams make is designing the agent as a chat interface that happens to do something. The conversational metaphor is appealing because it feels natural — people know how to talk — but it often produces products that feel like a slightly more patient FAQ bot.

The reason is that chat-style agents put the user in the driver's seat. The user has to know what to ask. They have to know the right vocabulary. They have to understand what the agent can and can't do. That's a lot of cognitive work, and it's the opposite of intelligent assistance.

Genuinely useful agents don't wait for a query. They understand the user's goal and drive toward it — asking for what they need, providing options when there's ambiguity, and skipping the parts the agent can already infer. The difference between a chatbot and an agent, in my view, is agency: the agent is trying to help the user finish something, not just respond.

Goal clarity before task design

Before you can design a good agent-based experience, you need to be honest about whether you've defined the user's goal precisely enough to build toward it. This sounds obvious, but it's the step that gets skipped most often.

"Help the user find the right product" is not a precise goal. "Help the user narrow from a catalogue of 500 items to a shortlist of 3 that match their stated constraints, within 4 minutes, without requiring them to know product specifications" — that's a goal you can design for.

The specificity matters because every design decision in an agent flow — what questions to ask, what information to surface proactively, when to offer alternatives, when to confirm versus proceed — depends on what "done" looks like. Without that, you're building a conversation, not an experience.

Handling ambiguity without losing the user

One of the hardest parts of agent design is handling the moments where the user's input is ambiguous or incomplete. There are two failure modes here: over-clarifying (the agent asks too many questions and the user gives up) and under-clarifying (the agent guesses and gets it wrong).

The right balance depends heavily on the stakes of the decision. For low-stakes steps, I generally prefer the agent to make a reasonable assumption, state it explicitly, and let the user correct it rather than asking. For high-stakes steps — ones the user can't easily undo — confirmation is worth the extra friction.

The worst outcome is when an agent proceeds silently on a wrong assumption and the user doesn't notice until three steps later. That breaks trust in a way that's very hard to recover from, especially in AI products where users are already holding the product at arm's length.

The exit always needs to be visible

Users need to feel in control of agent-based experiences, even when the agent is doing most of the work. This means the exit — the ability to pause, restart, or override — should always be visible and never require more than one action.

When users feel trapped in a flow, they don't engage more carefully. They either abandon or they click through without reading, which is worse. An agent that a user trusts is one where the user understands they can stop at any time. Counterintuitively, making the exit easy usually increases completion rates.

Measure completion, not engagement

The instinct in most product analytics is to look at engagement: time on task, messages sent, interactions per session. For agent-based experiences, these are mostly the wrong metrics. High engagement can mean the user is confused. Low engagement can mean the agent is doing its job.

The metric that matters is task completion: did the user finish what they came to do? And specifically — did they finish it accurately, meaning the outcome reflects their actual intent and not just their final response to an exhausted agent that kept asking questions?

That's harder to measure, but it's the only number that tells you whether the agent is actually working.