Written by: Tegan Henderson, Principal Designer, Vihan Patel, Head of AI Solutions, and Dr. Haijun Xia, Assistant Professor, University of California, San Diego
Chat won; then, it didn’t. Nine principles of agentic design:
For a couple of years, every product roadmap in sight had the same slide on it. Type what you want, in plain language, and the agent handles the rest. It didn’t matter whether the product was a customer support tool, a research assistant, a coding tool, or something that managed your calendar. The pitch was identical: get rid of the menus, let the conversation carry the whole interaction.
While a good first step, customer expectations are evolving. People often don’t know exactly what they want until they see some options in front of them. They compare. They change their mind halfway through. Someone opens a tool looking for one thing and ends up caring about something else entirely once they’ve seen what’s available. A chat box is a rough place to have that kind of back and forth, because typing assumes you already know what you’re asking for, and a lot of real tasks start without that clarity.
At Mantel we’re working hard to unpick what separates a great agentic experience from an average one. As part of our ongoing partnership, the following nine principles of agentic design were originally developed for a customer of ours by Assistant Professor Haijun Xia, who leads the Foundation Interface Lab at the University of California, San Diego. Each is shown twice below in a realistic industry setting: once as a working pattern and once as the anti-pattern that we’ve witnessed in market. The examples are deliberately abstract, pointing at shapes and concepts rather than product detail. In every pattern the agent stays visibly present, conversation layered on a working surface, not replaced by one.
Principle 01
Do not become over-reliant on chat
Whatever the agent is doing, whether it’s booking travel, managing a project, or answering support questions, the graphical interface hasn’t gone anywhere. Chat should sit on top of it, not instead of it. People struggle to type a clear request when they don’t yet have a clear goal, and in most agentic products, that’s the starting condition, not the exception. The stronger products treat chat as one entry point among several rather than the whole product.
Workforce management example
Why it works: the roster stays visible and directly editable while the agent acts and reports from the rail; chat is one entry point among several, not the whole product.
What it costs: the state is hidden, so the manager types from memory and interrogates the roster one question at a time; seeing one week takes ten prompts.
Principle 02
Let the interface carry the interaction
The same request phrased ten different ways should still land somewhere sensible, and the same person will often change what they’re optimising for after they’ve seen the first set of results. Ask a research agent to “find relevant papers” and the person may start caring about recency, or methodology, or whether it’s open access, only after the first list comes back. A usable agent needs an interface flexible enough to hold that shift: a customisable set of results rather than one fixed view, the attributes people actually care about surfaced instead of buried, direct manipulation of those attributes, and a way to resolve constraints that conflict with each other rather than silently picking one. Most of that has to live on the screen. Chat can’t carry it well.
Procurement example
Why it works: the ask starts in conversation, but refinement lives on screen: the attributes people care about are directly manipulable, and the agent raises conflicts openly instead of silently dropping one.
What it costs: every refinement is a full round trip through prose; nothing sits side by side long enough to compare, so the person re-asks instead of adjusting and gives up early.
Principle 03
Use the interface for exploration, not just resolution
Not every interaction should end at a single “best” answer. Sometimes the value is in browsing, in the small discoveries that happen along the way, whether that’s someone stumbling on a resource they weren’t looking for or a researcher noticing an adjacent paper worth reading. An agent that optimises too early forecloses that. The interface is where this kind of exploration can happen without the interaction collapsing into one recommendation the moment it’s technically possible to give one.
Corporate travel example
Why it works: the agent opens the field instead of closing it: options stay browsable, adjacent discoveries survive, and the person can take the scenic route and leave with something better than they asked for.
What it costs: optimising the moment an answer is technically possible forecloses discovery; the $298 mid-morning flight is never seen, and the person books worse or bails out to a browser.
Principle 04
Preserve context across short and long-term journeys
Real tasks rarely wrap up in a single session. Someone starts a piece of research on Monday, comes back to it Wednesday from a different device, and finishes it Friday. A good agent carries that thread through, rather than resetting each time someone opens it. Over a longer horizon, it should also start to recognise a person’s actual patterns, the kind of work they habitually do, and use that to shape what it surfaces next, instead of treating every session like the first one.
Legal services example
Why it works: the thread resumes exactly where it stopped, across days and devices, and over time the agent learns the person’s habitual patterns and shapes what it surfaces next.
What it costs: every session starts cold; the person re-briefs the agent, re-uploads the same contract, and Wednesday’s progress evaporates. Momentum, and eventually the user, leaves.
Principle 05
Make personal collections a first-class surface
A lot of work is repetitive in ways that are easy to underestimate: the same references get reused, the same templates get pulled up, the same kinds of decisions get made on a cycle. A usable agent should let people gather and reuse the things that matter to them, whether that’s saved sources, snippets, prior outputs, or recurring constraints, and put that collection somewhere visible rather than leaving it as something the system quietly infers in the background. Treated as an active surface rather than a static archive, that collection can help someone rebuild a familiar workflow, flag what’s missing, and adapt to new constraints. Because it’s visible and editable, the person keeps control of their own history while the agent gets something concrete to work from.
Professional services bids example
Why it works: the agent drafts in the open, from a collection the person can see, edit and reuse; they curate what it works from and keep control of their own history.
What it costs: invisible memory fails quietly; a stale case study ships to a client before anyone can catch it, and the person can neither audit nor correct what the agent draws on.
Principle 06
Lean on showing rather than telling for suggestions
Suggestions can save real time, and they can also feel presumptuous the moment the system seems too confident about what someone wants. Format does a lot of the work here. A suggestion shown as a set of options someone can scan, ignore, or compare keeps their sense of choice intact. The same suggestion delivered as a confident sentence in a chat window reads more like being told what to do, because a sentence is harder to skim past and dismiss than a row of cards. For most agentic products, this argues for defaulting to visual, dismissable suggestions and saving direct language for when someone has actually asked for a recommendation.
Grocery retail example
Why it works: a row of cards is scannable, comparable and dismissable; the buyer stays the decision-maker and the agent stays a suggestion, not a directive.
What it costs: a confident sentence is harder to skim past than a card, so it reads as an instruction; buyers either comply without conviction or push back on everything, and both erode trust.
Principle 07
Make the agent’s scope of knowledge legible
Every agent gets asked things outside its lane eventually, medical questions to a scheduling tool, legal questions to a customer support bot, health advice to a fitness app. People get frustrated not because the agent has limits, but because they assumed it didn’t and found out the hard way. It’s worth stating the boundary plainly rather than leaving it implicit, and when a request falls outside it, offering something useful instead of a flat refusal: what the agent can actually help with, plus a pointer somewhere more appropriate if one exists.
HR and payroll example
Why it works: the boundary is stated plainly before it’s tested, and an out-of-scope ask gets a useful redirect plus the parts the agent can actually handle, instead of a flat refusal.
What it costs: the person assumed the agent had no limits and now acts on unqualified advice; the injury worsens, the incident goes unlogged, and the employer wears the clinical and legal risk.
Principle 08
Handle ambiguity explicitly
Most real requests are underspecified on purpose, or at least by accident. “Make it professional,” “find something good,” “keep it short” all depend on context the agent doesn’t automatically have. Pretending otherwise just pushes the disagreement to later, when it’s more annoying to unwind. The better move is to either ask a targeted question or state a visible assumption up front, something like “I’ve assumed you want a formal tone, let me know if that’s off.” When there’s a specific factor to confirm, a quick interface choice usually resolves it faster than a paragraph of back-and-forth in chat.
Banking communications example
Why it works: the assumption is visible before the work happens and a one-tap choice resolves it; when there’s a specific factor to confirm, an interface choice beats a paragraph of back-and-forth.
What it costs: silent guessing defers the disagreement to rework: three drafts and a frustrated reviewer where one visible assumption would have done, and a hardship customer nearly got legalese.
Principle 09
Design for graceful failure and trust repair
Every agent will get something wrong eventually: a missed constraint, an outdated fact, a recommendation that doesn’t hold up. The instinct, especially under pressure to look polished, is to paper over that. It’s the wrong instinct. Trust isn’t preserved by hiding mistakes, it’s rebuilt through visible correction and giving people a way back in. A good agent doesn’t claim to be infallible. It flags uncertainty honestly, and gives people a real path to fix things, adjust an assumption, undo a step, or check what the recommendation was actually based on.
Demand planning example
Why it works: the agent flags its own uncertainty at the moment it matters and offers the repair itself: adjust the assumption, undo a step, or check what the number was based on.
What it costs: a polished wrong number flows silently into rosters and stock orders; when the miss surfaces a week later, there’s nothing to inspect or unwind, and trust collapses retroactively.
Closer to a colleague than an oracle
A couple of years ago, the promise was an assistant that would just know what you wanted. What actually works, based on people who’ve spent years studying how humans use these systems, looks a lot more familiar: something closer to a good colleague than an oracle. Attentive, upfront about what it doesn’t know, quick to say “let me check that” instead of guessing, and willing to let you take the scenic route when that’s what you actually came for.
Read across the nine principles, and the same thing keeps surfacing: the patterns that work give people something to react to, whereas the anti-patterns ask people to supply certainty they don’t have yet, usually at the start, in a text box, before they’ve seen anything.
None of that needs new technology. It needs decisions made on purpose rather than by default: where the agent can assume and where it has to ask, what stays on screen while it works, what a person can undo afterwards, and how much of its reasoning it shows when the stakes are high. Those questions tend to get answered implicitly during a sprint and never revisited, which is how a product ends up with a chat box where a menu would have done the job.
These questions are cheap to answer at design time but expensive to retrofit, which is why at Mantel, we start there. If you’re scoping an agentic build now, the interface decisions are worth settling before the model work begins, not after it.
See how we’re helping businesses scale with AI-first solutions
