An ink-wash illustration of a craftsman kneeling at the exact joint where an unfinished, sketched scaffold meets a solid, finished wooden bridge over misty mountains.

← All posts

Designing for AI Agents: Where UX Judgment Still Matters

An AI agent doesn't ask you to design its screens. It asks you to design its judgment — what it's allowed to decide on its own, and what it has to check with a person before it acts. That's the part of the job that doesn't disappear when an agent takes over an interaction. It's the part that gets harder.

The interface stops being the hard problem

Most UX training is built around a simple loop: a person makes a choice, the interface shows them what happened, they make the next choice. An agent breaks that loop on purpose. It makes several decisions in a row without asking, then reports back. The screen didn't get more complicated — it might even get simpler, a chat box instead of a form. The decision about what the agent is allowed to do unsupervised is where the real design work moved to, and that decision doesn't have a UI pattern for it yet the way a dropdown or a modal does.

Take something as ordinary as an agent that reschedules a meeting when it detects a conflict. The interface question is trivial — a confirmation toast, maybe. The actual design questions are: does it need to ask first, or just do it and tell you? What counts as "detected a conflict" versus a guess? Does it ever touch a meeting with an external client without a human in the loop? None of that shows up in a wireframe. All of it decides whether the feature is trusted or muted within a week.

It's also, not coincidentally, the part that's easy to skip when vibe coding makes the interface trivial to stand up. The screen takes an afternoon; the judgment behind it still doesn't design itself.

Reversibility does the work confirmation dialogs used to do

A confirm/cancel dialog exists because the interface can't tell whether an action is safe — so it asks a person every time, regardless of the actual stakes. An agent can be more precise than that, but only if someone designed the precision on purpose:

  • - Low-stakes, easily reversible actions (drafting a reply, tagging an item, summarizing a thread) can run without asking.
  • - Medium-stakes actions (sending on someone's behalf, modifying a shared record) should be visible and undoable, not blocking.
  • - High-stakes or hard-to-reverse actions (deleting data, spending money, anything external-facing) still need a real checkpoint — not because the agent is untrustworthy, but because the cost of being wrong is asymmetric.

The question that actually matters

Not "can the agent do this correctly most of the time," but "what does it cost when it's wrong, and can that cost be undone." Design the checkpoint around the second question, not the first.

That's a judgment call per action, not a global setting, and making it well is genuinely design work — it's about consequence, not confidence scores.

Where this shows up in customer-facing work

This isn't abstract for support and customer success work specifically, because the failure mode is public. A UI bug is annoying. An agent that confidently tells a customer the wrong refund policy, or closes a ticket a person actually needed escalated, damages trust in a way a broken button doesn't — because it looked like a considered decision, not an error state. The design response isn't "make the agent smarter." It's the same reversibility question from above, applied to the moments where being wrong is expensive: let the agent draft, summarize, and triage freely; keep a person in the loop on anything that closes a case, commits to a policy exception, or speaks with authority the team hasn't actually verified.

What this doesn't mean

None of this is an argument for adding more confirmation dialogs. That's the old pattern reapplied to a new problem, and it produces exactly what it always produced: users clicking "confirm" without reading, because they've been asked so many times the checkpoint stopped meaning anything. The goal isn't more checkpoints. It's fewer, placed where the cost of being wrong actually justifies stopping to ask — and real autonomy everywhere else. An agent that asks permission for everything isn't safer. It's just a slower form you didn't design on purpose.

The interface layer of agent design is genuinely easier than what it replaced. The judgment layer — what the agent is trusted to decide alone — is where the actual design work is now, and it's not optional just because it doesn't render as a component.

Related

← All posts