Designing AI that shows its work: A deep dive into transparency patterns

If you read my post about the AX Pattern Library, you’ll know that the patterns are organized into five categories: Transparency, Control, Error Handling, Onboarding, and Conversation.

This post goes deeper into the first one, Transparency. I’m starting there because the other categories rely on it. It’s difficult to design good controls for something the user can’t see. The same goes for error handling. If the user doesn’t know what happened, it’s much harder to help them recover.

For this post, I’m using three scenarios we worked through in a guild workshop, one for each pattern. I find these more useful than simple textbook examples, because the interesting design questions usually come up when you start thinking about what could actually happen in a real product.

The trust problem nobody designed for

Traditional software tends to be fairly predictable. You click something, and it does what you expect. When something goes wrong, there is usually a clear interaction that caused it, and over time people learn how the system behaves.

AI agents make this more complicated. The same input can produce different results, and an answer can sound confident even when it isn’t correct. In an agentic interface, the AI also isn’t just answering questions. It can take actions, sometimes while the user isn’t even looking.

That can lead to two very different behaviors.

Some users might trust the output too much because it looks polished and confident. They might take a number the agent generated and send it to a client without checking it.

Others might do the opposite. After one bad experience, they start checking everything the agent does manually, which can take almost as much time as doing the work themselves.

That’s where these three patterns come in, each addressing a slightly different part of the problem.

Pattern 1: Confidence Disclosure

The problem here is that users often can’t tell when an agent is unsure. A suggestion that is basically a guess can look exactly the same as something the agent is highly confident about.

The scenario

In our workshop, we looked at an AI calendar agent that knows the user prefers to have some uninterrupted time for deep work. It notices an opportunity and quietly moves a few meetings around to create that space.

The user comes back from a break and finds that their calendar has changed.

The difficult part is that the agent might actually have different levels of confidence about those changes. It might be fairly certain that one meeting can move, while being much less certain about another.

But none of that uncertainty reaches the interface.

“I moved your 3pm” can sound exactly the same whether the agent was confident that the meeting was low priority or was mostly guessing.

Because the output sounds confident, we tend to read that as competence. That’s not necessarily a model limitation. It can also be a result of what we choose to show, or not show, in the interface.

What could a better experience look like?

When we mapped this out, a few things became clear.

The agent should ask before acting when it’s unsure, especially when other people are involved. It can offer an alternative when confidence is low, instead of making the decision silently.

It should be clear about what it changed and what it didn’t change. For example, if it moved the time, it should also make it clear that it didn’t change the duration, the attendees, or the description.

There should also be some kind of trail showing what happened. That way, the user doesn’t have to simply trust that everything is fine. They can actually check it.

I’d also be careful about turning confidence into a number. Something like “87% confident” might look objective, but it doesn’t really tell the user what that means. Is 87% good enough? Compared to what?

For me, confidence disclosure is more about language and timing than putting a percentage next to an action. The useful information is usually what the agent is uncertain about, and whether that uncertainty affects the action it wants to take.

This isn’t a new idea. Google’s PAIR Guidebook grouped it under Explainability and Trust and talked about model confidence displays. What’s changed is that the agent now acts on that confidence, not just reports it.

There’s another layer to this once the agent is connected to other systems. Imagine the calendar is connected to Google Calendar or an HR system. A change that looks safe from the agent’s point of view could have consequences somewhere else.

Recurring meetings make this even more complicated. Does the agent move this one meeting, all future meetings in the series, or something in between?

Pattern 2: Decision Explanation on Demand

This pattern covers situations where the agent makes a decision the user doesn’t quite understand.

The scenario

Imagine a trip-planning tool that recommends a hotel as the “best choice”. The user looks at the recommendation and notices that another hotel nearby is cheaper and has better reviews. So naturally, they want to understand why it chose the first one.

The important part of this pattern is the on-demand aspect. I don’t think users need an explanation for every decision an agent makes. If the interface constantly explains itself, it can quickly become distracting. Most of the time, people just want the result.

When something feels unexpected, an explanation becomes useful. The user should be able to ask something like “why this one?” and get an answer based on the actual decision the agent made.

A useful explanation shows which alternatives were considered, why they weren’t selected, and which criteria influenced the decision. It can also surface the trade-offs around things like location, travel time, price, or quality.

That was one of the main failure cases we discussed. The agent might satisfy some requirements, ignore others, and never tell the user that it made that trade-off.

Another possibility is that it decides something is “best” and books it without giving the user a chance to confirm. There can also be issues around recommendations that rely too heavily on one source, especially when something is described as “best rated”.

The useful part is also correction

This pattern isn’t only about making people trust the agent more. It can also make the agent easier to correct.

If the explanation tells me that it chose a hotel because it assumed I was traveling from a particular location, I immediately know what went wrong. I can correct that assumption and continue.

Without that context, I’m left guessing what the agent misunderstood and trying the search again.

This also raised some practical questions during the workshop. How long should the system retain the information behind a decision? Can the agent still explain its reasoning thirty minutes later? What happens if the underlying model changes?

These questions aren’t necessarily visible in the interface, but they affect whether the explanation can actually be useful and accurate.

Pattern 3: Autonomous Action Log

This pattern looks at what happens when an agent keeps working without the user.

It might check information, update records, send something, or take action based on a set of rules. When the user comes back, they need a way to understand what happened.

The scenario

Our workshop example came from quality management. Imagine a pharmaceutical warehouse where vaccines need to stay between 2 and 8°C. A cooling unit fails, and the temperature reaches 10.5°C for more than fifteen minutes.

A Quality Event Management system connected to the sensors and inventory system could automatically start a containment process and record what it did.

Later, a quality manager needs to understand what happened quickly, without going through every detail in the system. This is probably the most complex of the three patterns, because it introduces a situation that traditional UX didn’t have to deal with quite as often: the user coming back to a system that has been working on its own.

I find it useful to think about this similarly to a banking app. You don’t necessarily read every transaction, but you know there is a record there if you need to check something.

The same idea works for an agent. The log shows the timestamp, what triggered the action, what the agent did, the current status, and any relevant risk or alert. The challenge is deciding how much information to show by default.

If there are forty actions and only three actually need attention, showing everything with the same level of importance doesn’t help much. The design work is really in making those important actions easy to find without hiding the context behind them.

It’s also worth thinking about what happens after someone finds a problem. Can they understand why the action happened? Can they trace it back to the event that triggered it? Can they do something about it, such as undoing the action?

That’s where this pattern starts to connect with other categories in the library, particularly Control and patterns such as Undo for Agent Actions.

The categories aren’t really isolated from each other. What happens in one often creates a need for something in another.

Someone from sales also raised an interesting point during the workshop. A log that people don’t trust isn’t only a UX issue. They put it more bluntly: it’s a commercial risk.

If a client can’t see what the agent did, or can’t see what happened when something went wrong, they may decide not to rely on it at all. A deal can stall in the proof-of-concept stage, before the product ever gets a fair trial with real work.

The thread that ties them together

When you look at these three patterns together, they have something important in common.

They don’t make the agent more accurate. They change how much visibility the user has into what the agent is doing.

That distinction matters, because trust is often treated as a model-quality problem. Improve the accuracy, and people will trust the system more.
But even if an agent is usually right, people may still want to check what it has done if they can’t understand how it got there.

For me, that’s where transparency becomes a design problem rather than just a model-quality problem.

The goal isn’t to explain everything the agent does. It’s to give users enough information to understand what happened, question something when it feels wrong, and correct the agent when needed.

Each pattern in the library includes implementation guidelines, including where it can be used and how complex it is to build.

And that’s the part I think we underrate. An agent can be accurate and still go unused, simply because people can’t see what it’s doing.

Frequently asked questions

What are transparency patterns in agentic experience design?

They’re design patterns that help people understand what an AI agent is doing, why it made a particular decision, and how certain it is.
The bigger issue they’re trying to address is that people can’t easily judge how much to trust a system they can’t see into.

Why is transparency important in AI interface design?

Without enough transparency, users can end up either trusting polished output too much, or checking everything manually because they don’t feel comfortable relying on the agent.

Transparency gives people more context to make that judgment themselves.

Should AI agents explain every decision they make?

I don’t think they need to. Constant explanations can quickly become noise, especially when the user already understands what happened.
Decision Explanation on Demand is more about making the reasoning available when the user actually needs it, usually because something surprised them.

What is an autonomous action log?

It’s a reviewable record of what an agent did while working on its own.
It’s closer to a banking transaction list than a traditional server log. The idea is that users don’t need to read every entry, but they know there is a record they can go back to when they need to understand what happened.