Patterns for Designing Agentic Experiences

This post introduces the AX Pattern Library. It holds 16 design patterns for agentic experiences, organized into five categories. 

INTRO

In my last post, I ended the section on agentic UI with a sentence that kept following me around: “No settled patterns for this yet. We’re building them as we go.” 

Well, we built some. I am now introducing the AX Pattern Library, with 16 design patterns organized into five categories, for agentic experiences. The whole thing started as my personal collection of “wait, how do we solve this” notes from real projects. Over time, it grew into a shared reference for the whole design team, and now we have ready-to-apply patterns, along with a set of fully usable guidelines. 

Why a pattern library, and why now

Every time I worked on an AI feature, I ran into the same situation. A design question that classic UX patterns don’t cover. No best practice to lean on. And a deadline that doesn’t care about either.

How does a user know what the agent just did while they were away? What does “undo” even mean when the agent already sent the email? How do you ask a clarifying question without turning the conversation into a police interrogation?

These questions kept repeating across projects. And when questions repeat, there’s usually a pattern hiding in them. Classic UX has had pattern libraries for decades. Nobody designs a date picker from first principles anymore. AX deserves the same treatment. The only difference is that we have to write the patterns down while we’re still discovering them.

So instead of keeping my answers scattered across Figma files and project notes, I documented them properly → problem, context, guidelines.

How the library is organized

Every pattern in the AX Pattern Library answers three things. What problem it solves. Which interfaces it applies to – chat, voice, agentic, or a combination. And how to implement it, in five guidelines. Some patterns are quick wins. Others are marked medium or high complexity, because they touch product logic and not just the interface.

The five categories map to the five moments where agentic experiences usually break:

1. Transparency – does the user understand what the AI is doing?

Three patterns live here: Confidence Disclosure, Decision Explanation on Demand, and Autonomous Action Log.

My favorite example is the Autonomous Action Log. When an agent works over time – checking emails, updating records, sending notifications – users lose track of what it has done. Then one of two things happens: they either over-trust it and never check. Or they under-trust it and check everything by hand, which defeats the point of having an agent at all. A clear, reviewable log is the difference between “I delegate to this thing” and “I babysit this thing.”

2. Control – can the user stay in charge of actions that matter?

Human-in-the-Loop Checkpoint, Undo for Agent Actions, and Defining What an Agent Can and Cannot Do.

The checkpoint pattern is the one I’d tattoo on every agentic product if I could. When the agent is about to do something irreversible or high-stakes, the user needs a moment to review and approve before it happens. A notification after the fact doesn’t count. Agents will make mistakes; that’s a given. The real design question is whether the user gets a chance to catch them in time.

(Small confession: I went back and forth on whether “Defining What an Agent Can and Cannot Do” belongs here or in Onboarding. It landed in Control, but I can still see the argument for the other side.)

3. Error Handling – what happens when the agent fails?

Graceful Error Recovery and Graceful Agent Failure.

Only two patterns, but honestly, they might be the ones that matter most. Users form their opinion of an AI product in the moment it breaks. A raw technical error with no explanation and no path forward is how you lose someone for good. There’s enough here that I’m planning a separate post just on failure design. For now, a quick test. If your happy path demos beautifully and your error state is a toast saying “Oops!” – start there.

4. Onboarding – how do users build the right mental model?

Progressive Capability Onboarding, Expectation Setting for AI Output, and Permission Scoping.

Users come to AI agents with either too much trust or too little. The first group expects perfection. The second dismisses everything without reviewing it. Onboarding is your one chance to set that balance before the first real interaction. And permission scoping is worth calling out on its own. Asking users to grant broad permissions upfront, without explaining what they’re for, creates exactly the kind of anxiety that makes people close the tab.

5. Conversation – does the dialogue hold up?

The biggest category, with five patterns: Conversation Reset Recovery, Clarification Without Interrogation, Graceful Topic Boundaries, Designing for Silence in Voice UI, and Keeping Users Oriented Without a Screen.

Two of these are voice-specific, because voice is where conversation design gets really hard. Silence in a voice interface is unclear. Is the agent processing, waiting, or dead? There’s no spinner to look at. 

And Clarification Without Interrogation is one of those patterns you notice everywhere once you name it. The agent either runs ahead on wrong assumptions, or it fires six questions at you like a form with a personality. Both are bad in different ways. The better version fits in five guidelines.

This is a living thing

Sixteen patterns is just where we are right now. A snapshot of what we’ve learned so far. The library is a shared resource of our AX guild at Notch. That means it gets challenged and rewritten as we take on more AI-native projects. Some patterns will split. Some will merge. Some will turn out to be plain wrong. Which is fine, honestly – that’s how pattern libraries have always worked.

The field is still forming. That’s not an excuse to design from vibes, though. It just means we write down what works, share it, and fix it in public.