This is part 2 of a 2-part episode. Listen to Part 1 (episode 175) first.

In this episode of Experiencing Data, I continue my deep dive into the MIRRR UX Framework for designing trustworthy agentic AI applications. Building on Part 1’s “Monitor” and “Interrupt,” I unpack the three R’s: Redirect, Rerun, and Rollback—and share practical strategies for data product managers and leaders tasked with creating AI systems people will actually trust and use. I explain human-centered approaches to thinking about automation and how to handle unexpected outcomes in agentic AI applications without losing user confidence. I am hoping this control framework will help you get more value out of your data while simultaneously creating value for the human stakeholders, users, and customers.

Highlights / Skip to:

• Introducing the MIRRR UX Framework (1:08)
• Designing for trust and user adoption plus perspectives you should be including when designing systems. (2:31)
• Monitor and interrupt controls let humans pause anything from a single AI task to the entire agent (3:17)
• Explaining “redirection” in the example context of use cases for claims adjusters working on insurance claims, so users can focus on important decisions. (4:35)
• Rerun controls: lets humans redo an angentic task after unexpected results, preventing errors and building trust in early AI rollouts (11:12)
• Rerun vs. Redirect: what the difference is in the context of AI, using additional use cases from the insurance claim processing domain  (12:07)
• Empathy and user experience in AI adoption, and how the most useful insights come from directly observing users—not from analytics (18:28)
• Thinking about agentic AI as glue for existing applications and workflows, or as a worker  (27:35)

Quotes from Today’s Episode

"The value of AI isn’t just about technical capability, it’s based in large part on whether the end-users will actually trust and adopt it. If we don’t design for trust from the start, even the most advanced AI can fail to deliver value."

"In agentic AI, knowing when to automate is just as important as knowing what to automate. Smart product and design decisions mean sometimes holding back on full automation until the people, processes, and culture are ready for it."

"Sometimes the most valuable thing you can do is slow down, create checkpoints, and give people a chance to course-correct before the work goes too far in the wrong direction."

"Reruns and rollbacks shouldn’t be seen as failures, they’re essential safety mechanisms that protect both the integrity of the work and the trust of the humans in the loop. They give people the confidence to keep using the system, even when mistakes happen."

"You can’t measure trust in an AI system by counting logins or tracking clicks. True adoption comes from understanding the people using it, listening to them, observing their workflows, and learning what really builds or breaks their confidence."

"You’ll never learn the real reasons behind a team’s choices by only looking at analytics, you have to actually talk to them and watch them work."

"Labels matter, what you call a button or an action can shape how people interpret and trust what will happen when they click it."

Links

Part 1: The MIRRR UX Framework for Designing Trustworthy Agentic AI Applications

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, I’m continuing part two of the MIRRR UX framework for designing trustworthy agentic AI applications. Being part two, this means there was a part one, so if you’re new to the show, you might want to head over in your podcast player and just look at the prior episode, or one of the prior episodes. It’s probably the one right before this, depending on, you know, how things drop. Sometimes I change up the order, and I’m recording this in early August of 2025.

And the MIRRR framework is M-I—triple-R, M-I-R-R-R. This is a UX framework that I’m hoping will be useful to data product managers and data product leaders, primarily. I just wanted to say there’s more to, I think, designing a great agentic AI application from a user experience perspective and an outcomes perspective that designers may find some of this incomplete. And as with a lot of my work, what I’m trying to do is give practical advice, things that are actionable without using jargon, things that you can go out and apply today in your work as a data product leader. So, if you are a designer listening to this episode, I hope you’ll get something useful out of it. You may have some things you want to poke at, which is totally fine.

Feel free to se—I love getting that kind of feedback, whether it’s from our product and data professionals listening, or designers, but I just wanted to say this is really targeted at giving practical advice to non-designers who are effectively owning the role of design of these applications leveraging AI agents right now. So, jumping back in, so the MIRRR framework, in part one, we talked about the M and the I. M being for Monitor, which has to do with what is this agent doing, and how is the system performing. And I this second verb—these are all verbs, and they’re just activities, use cases, things that I want you to think about as you’re designing these systems; you can think of it almost like a checklist or just perspectives that you should be including if you really want to make sure the humans in the loop are going to trust and use the solution.

So, M for monitor, I is for interrupt, and this has to do with the active and passive—we talked about active and passive pausing of a particular AI agent, or even an instance of work, such as a particular job that the agent is doing. And even sometimes, we may need to pause the entire agent and stop it from doing all kinds of work, depending on what the scenario is. That was what part one went into. Again, check your podcast player, or you can also head over to designingforanalytics.com/episodes. That’s the listing page on my website that has all of the episodes. You can search for stuff there, and it’s in chronological order.

So, continuing with the MIRRR UX framework, R, the first of the three R’s, R is for Redirect. Let’s jump into this one. In the early adoption phase of agentic AI, I believe that systems should be defined with more human touch points, such that we’re building safe trust along the way, trust between the agentic AI application user, the beneficiaries, the humans in a loop who are benefiting from this, who may not be the users themselves, and then we have our business sponsors or stakeholders who are the ones paying for this. They’re investing in this solution. Allowing a multi-step agent that has been interrupted to prompt the application user for redirection at relevant times allows humans to safely maintain control until such time as you know, these agents can more reliably handle steps autonomously.

So, in the first episode, we were talking about, like, I was trying to put this into the context of, like, some insurance claims use cases, and I tried to pick something that’s, you know, it’s a heavy data space, it’s a place where we can definitely leverage, you know, large language model-driven AI applications, things like this. And it’s fairly relatable. Most people understand the basic concepts of insurance and claims, so I picked that one kind of arbitrarily, but let’s use that again and jump back into our adjuster and put our adjuster’s hat on. So, let’s say that the AI agent is doing some of the claim screening work for the human adjuster, such that this human in the loop is only doing the most important aspects of this job and the work. And so, the net benefit to the customer that’s paying for an insurance coverage, it’s accelerating response times to these customers, so they don’t have to wait as long to get their claims processed.

So, we might ask, why might the user of the application need to redirect the agent in the first place? Well, in complex systems, there will likely be situations where there are multiple decision points along the way between start and finish, and we may not want to automate all these steps because we’re not yet confident in the agent’s ability to properly handle all use cases correctly and safely. Earlier we might have had an automated or manual interrupt that had occurred, but what do we afford the user of the application when the agent is paused or interrupted? So, in our claims adjustment scenario, let’s look at this redirection user experience.

So, I’m going to kind of outline a few steps here. Step one, oh, we send a Slack or a Teams or an email alert to a human user that an agent’s task has been interrupted or held. And then the second step, we might provide logical next steps for this human user, whether they might be invoking a new agent, or a new model with different capabilities to continue the work, you know, from some kind of list of choices, or we might just simply say, I’ve reviewed this and I’m going to allow the agent to continue as it was doing its work. Or we might C, option C, do a manual override and return the remaining parts of this job that the agent was doing to a human to complete.

Next we want to provide affordances to properly monitor these exceptional cases, right? So, from a design perspective, these might be more closely observed than your typical claims, for example because for whatever reason, there was an interrupt and there was a need to do a redirection here, and so this has kind of been raised up as a case we need to, quote, “Keep our eye on.” So, this is a place where our deterministic application, our wrapper application, may need to make sure that there is, like, a watch list or something that’s escalating the views of these special situations to the user because they probably have more meaning than the 90% of—or 80% of—claims, in this insurance use case, that are just getting processed normally and aren’t causing need to be escalated, they don’t really require human attention.

But why might we need multiple redirect options like this? So, an insurance company might have logical policy break points whereby, like, claims above a certain monetary threshold need to go through a human review step. So, let’s just make up a situation. Let’s say claims over 1 million US dollars need to have a human review. But why do they need a human review?

And this is where it gets interesting. It could just be that the product team and the business have identified that they’re just not ready to allow an agent to handle claims of this amount. It just doesn’t feel good, it feels risky, maybe in testing there were situations where there could have been financial loss or risk and/or maybe it wasn’t that risk, but the person who would have been responsible didn’t want to take that chance, for whatever reason. The point is, it could simply just be a feeling, like, the culture of the company and the humans in the loop simply don’t feel ready yet. That might be the justification.

From a business analyst perspective, it might seem like the claims processing workflow is the same regardless of the amount of the claim, but in reality, when it comes to quote, “AI trust,” the humans in the loop aren’t ready to hand the keys over to a bot to process claims of this amount, possibly incorrectly, probably being the implied reason why they’re not comfortable with this, and then some downstream ramification for that, whether it be I’m going to get fired, or someone else is going to get fired, or the reputation and trust of this automation work that we’re doing with an AI agent is at risk, and we don’t want to take a big hit because not everyone in the company was a champion of doing this in the first place, and they’re perhaps looking for a reason to shut this stuff down, and so we might want to tread more conservatively early on. Because AI value is based in large part on whether users will actually adopt the solutions—I’m going to say this again—the value of the AI is based in large part on whether the end-users of the system will actually use them or not, then we have to design for trust such that we’re facilitating this user adoption that is required for the business or the organization to get the value out of whatever it is that the agent is doing. So, knowing when to automate, regardless of what is technically possible to automate, is part of a smart product and design-informed approach to making successful AI solutions. I want to say this again, knowing when in your organization it’s the right time to automate something, regardless of what could technically be automated or using AI in some way, that’s part of a smart product and design-informed approach to making successful AI solutions.

Okay, that was our first R, Redirect. The second R—there’s three of them in the MIRRR framework—R is for rerun after unexpected results. I’m not talking about the Andy Griffith Show or old Star Trek, even though I like old Star Trek. We’re talking about re-running a job or a task that the agent did and gave us unexpected results. And you might think of this as one of our redirection options, and I don’t know, maybe it doesn’t deserve to be called out separately, but to me, it kind of feels like it does.

But why? Well, I’m going to tell you. Early on in an agentic AI rollout, if we’re designing for trust, I think we should design for the unexpected, situations that we cannot anticipate, and ensure that systems cannot create disastrous consequences that close the door on opportunities to use AI in a human-centered, value-creating way. Reruns, to me, are a bit different from redirections because a redirection is changing the upcoming path that the agent will continue down after it started one of these jobs that it’s doing, these workflows. A rerun, though, to me, is different the job, such as, like, this insurance claim that’s being processed, if we go back to that use case, this job needs to be rerun from the start or a prior step, usually due to problems such as, one, the agent or code failed in a human observable way, resulting in an incorrect outcome.

In our insurance use case, the failure may be classifying a claim as deny, as opposed to approve, right? So, this is this idea, like, hey, my baggage got lost on this flight, and I’m filing a claim because I had travel insurance, and so the company has to decide that’s a deny, nope, we’re not going to pay that out because it wasn’t, you know, a full four hours after the flight and the bags got lost, or approve, right? So, the failure might be that classifying a claim as deny when this is observably wrong, or noticing that the handwriting on a claim form was not OCR’ed properly, and so the AI agent, made wrong conclusions because it didn’t actually read the handwriting on, like, a paper form—you know, there’s probably still some paper forms out there—or perhaps seeing that an incorrect medical code, like, an ICD code, was entered next to a procedure, an incorrect code was entered next to a procedure that actually happened on the patient, triggering a false negative. What are some other reasons or other problems here that could create this rerun scenario, right?

Number two, a dependency in the agent’s work has changed. So, some earlier set of jobs that were completed are now out of date or incorrect for some reason. So, what’s an example of this? This could be, like, let’s say that a claim is being paid out in a local currency instead of a customer’s home currency, but today, there’s been huge news about something, and there’s been a large swing in the currency rate tables, and as such, the insurer manually refreshed these currency rate tables and needs to reprocess a set of claims or rerun them that earlier had been approved for specific payout amounts, but perhaps they were going to be paid out at the wrong amounts because they hadn’t done this adjustment, and for whatever reason—I’m just making it up—that it’s not automated. Let’s say it only runs every 24 hours, but you know, there was a massive run on the banks at nine o’clock in the morning and the values have already changed, and the company wants to be on top of this right now; they don’t want to wait a whole 24 hours for these claims to sit on the wrong valuations and then basically pay out too much money. So, I’m not saying that’s the right thing to do, or necessarily a great customer experience. I’m just trying to give a very clear example of how something could work in that situation.

Number three, while the system was interrupted for human feedback, the human claims adjuster talked to the customer, and maybe they received some new information that the model, or our AI agent, is not aware of because this was a phone call that happened, and let’s say that data was not necessarily captured and rerouted back into the agent, let alone to this specific job that’s being done, this claim that’s being processed. So, either for regulatory reasons like auditability, or because it’s simply easier for the claims adjuster, they want to rerun the job with this new customer information included in it.

Number four, another option here, a key step in the agent’s work, such as, let’s say, like, a fraud classifier model, let’s say it was upgraded after a job was done, like, the claim was processed, but the claim hasn’t been paid out yet, and as such, the adjuster wants to make sure that you know any and all pending claims, particularly, like, those, some of those really big ones that are ready to be paid out are indeed legitimate. Since, you know, we could pretend that recently, let’s say this insurance company lost a lot of money due to paying out fraudulent claims, and so the machine learning team has been working on their fraud model, and they’ve been rolling out updates regularly. But let’s say that this claims processor, you know, AI system, doesn’t necessarily get access to those models without some kind of manual intervention, so there’s a reason that the agent may want to recheck some of these claims before they’re paid out to make sure the latest and greatest fraud classifier was used against this batch of claims. And the important thing here is that, you know, given these recent losses, this adjuster, this human that’s working in this role, they might be extra motivated to avoid any further payouts on illegitimate claims because they feel like, hey, you know, that doesn’t look good for our team. We’re the ones that have the final, you know, sign off and whether a check is written or not.

And even though maybe the, you know, fraud wasn’t their fault necessarily, they, for personal reasons and career reasons, and this, this team is sensitive to this. They don’t want to be seen as paying these things out, even if it’s not necessarily their fault. So, the point of this is, like, there’s still the feeling that these people may have in their personal motivations—and this is an important user experience concept—you know, the business might be able to logically reason its way into saying that it’s not the team’s fault that there was this fraud that happened, that’s why we have these fraud detection models, but on the ground, the reality of the situation may be that this claims adjuster team does not want to be associated with paying out large claims that are not warranted, that are fake or illegitimate. They don’t want that reputational risk, they don’t want to be associated with it, whether or not it’s their fault or not because maybe they think it’s going to stick. Or in the past, they saw the business blame this team, or whatever the reasons are, the point is, these are things that you’re never going to find out about unless you’re actually going out and getting that customer exposure time, and your data product team, your AI team, is actually hearing from these people, you know, with true empathy, talking and observing these people to start learning some of these anecdotes that actually drive—the feelings that are actually driving some of the real work that happens on the ground, and why they may not adopt a solution like this.

And you’re never going to learn this kind of stuff through analytics or looking at how many people use the tool and counting, you know, product statistics. You know, let’s say you, your wrapper application has Google Analytics or whatever your internal Analytics—which is ironic, your analytics on your analytics, but all this stuff, these are all things that are measuring product attributes, your solutions attributes, but they’re not directly measuring user experience. So, counting logins, counting time spent, these things are very much proxies, and they’re not replacements for getting direct feedback, qualitative feedback, from these users. So anyhow, I’m going to get off my soapbox on that because you’ve all heard plenty of this from me on this show before, so I’m going to move on to the next big R.

So, this is, again, the MIRRR UX framework—M-I—triple-R—for designing trustworthy, agentic AI applications. So, what’s this next R? R is for Rollback, industrial strength, undo. And this kicks in when? Well, when we have significant unexpected agentic AI behavior. So, with agentic AI, things will go wrong, especially if you are an early adopter, but we can plan for wrong ahead of time in many situations, providing our end-users with a user experience that doesn’t necessarily break trust in the system.

I’m still debating about renaming this step in the framework to ‘Undo,’ but rollback seems to have greater scope, and in complex enterprise situations we need, we may need to think beyond, you know, taking a single step backwards, which is often what this concept of undo in computing is often associated with, at least in traditional software applications. Additionally, when we talk about rollback, we’re likely addressing multiple systems that may need to be touched as well, and so, you know, even if the user interface element, the button or whatever it may be, might have an undo label on it, the scope of this undoing behind the scenes might be multi-faceted. And so, this is yet another design concept where we might use a label that is clearer to the end-user, it’s very clear that they’re on the right track. Even if it might be slightly off in terms of the scope of what it does, we may still want to surface what’s about to happen when we almost certainly would want to surface that. So, even if you click undo or whatever it says, there might be a preview screen that explains what’s about to happen.

But the main point is, we wouldn’t want it—like, the word ‘rollback,’ this starts to sound kind of computing-oriented. It sounds like engineer-speak to me. And so like, you know, an insurance claim adjuster, this is not part of their jargon. And so, this is why we always test our designs—or you should be,particularly when developing custom applications—the labels and actions within the applications, they have meaning, and people will assume they mean different things. And sometimes we need to go and validate these labels, especially on our buttons and affordances, to make sure that what people think is about to happen actually maps back to what we actually designed the system to do and that there’s not a gap there.

So again, the label might say ‘undo’ because it’s familiar-sounding and it doesn’t need a lot of explanation, but the scope of undoing in our application might actually be more like what an engineer might call a rollback scenario with multiple application undergoing some type of code change or underlying models maybe change things like this. So anyhow, for now, I’m leaving the word rollback. I’m not calling it undo. But why do we need to allow a user to roll back in the first place? So, let’s get into that.

Well, we’re not fully confident in our agent. Yet that might be the reason. And when something goes awry beyond the user’s comfort zone and a degree of trust has been lost, the most comforting step for our humans in a loop may be simply to go back to the latest safe state with confidence that all the constituent systems are properly functioning and haven’t been negatively impacted due to this unexpected agent behavior. However, it’s not sufficient to simply walk back all the systems invisibly. Legally, we may need an audit trail, you know, showing that the system, this job was—this claim, for example—was processed a specific way, it went through a bunch of steps, there was a log of an activity about what happened, and then the system shows that it undid the steps.

But the point is, we’re not actually hiding what happened in the past. Instead, we’re logging what happened in the past and then showing that there was an undo here. But we might need this same audit trail to build user trust too, not just regulatory trust. So, here are a couple examples. Like, let’s say that the AI agent actually was allowed to pay out claims and write checks, but it did it in the wrong currency.

So, maybe someone in finance team was like—maybe part of their job is every Friday, I review every dollar that went out the door. I just eyeball the checks, and there’s some step there just to make sure that nothing strange is going on, and someone noticed this and they want to correct the action before the customer calls in and complains. Because that’s not a good customer experience, and it’s obviously costing money when we have to talk to a human customer service person and the like. So, the rollback action would need to possibly do a bunch of things such as cancel the wire payment, or cancel the check that’s about to go out, reopen the claim, or step the claim back to the proper state, such as pending review, or whatever it may be. It might need to draft an apology email for the adjuster to send the customer.

So, we probably wouldn’t—and you know, unless this is a repeating situation, you might not want to actually have it deliver the email, but it might be able to do a really good job of drafting up something that makes it very easy for the adjuster to put a little human touch on a situation that was incorrect, and to catch this really soon, but it comes from a human, and it shows that this company actually cares. Could we deliver it automated? Of course, but maybe this is a chance to add a little bit of delight when we’ve failed or under-delivered, you know, on whatever our promise was. And then finally, we might need this action of rollback to prompt the user that a next action actually needs to be taken. So, you don’t just roll it back, but once you roll it back, it’s like, well, what happens now? Where did we leave things? So, we need to prompt a user that a next action needs to be taken.

Jumping up to another example here about, you know, why do we need to allow a user to roll back? Let’s say that a customer called in to customer service, to the care team, and they complained about a denial notice that they received, feeling that their claim was improperly handled and should have been paid out. Upon review, a human adjuster agrees that the AI agent made an error when it flagged this claim as deny. So, rolling back this step might mean several actions have to occur in order for the internal application user to continue trusting this AI agent. So, the denial letter might need to be marked void, and that might need to be recorded in a few different places, the CRM, in the claims database, or whatever it may be, and the claim status needs to be changed to the correct status, such as ‘Needs a Review.’ And then maybe late fees that were imposed or calculated need to be removed from the customer’s account and maybe even reversed in the official ledger with some kind of comment.

So, the rollback scenarios could be many, and one thing this calls attention to is how much the agentic AI is not about automating everything in some invisible way. Instead, AI can and should be intelligently used for the right types of work and jobs, often—or maybe even usually—inside of a deterministic or traditional software application wrapper that solves for some of these deep, vertical use cases. In some ways, the AI is almost more akin to services and workers, and not a replacement for traditional applications. Instead, it’s like a new form of glue that connects existing applications and infrastructure while helping to accelerate customer and business value.

So, that’s it, for now. The MIRRR UX framework for designing trustworthy, agentic AI applications. It’s a start. I have a lot more to say about this. I’ve been thinking about this space quite a bit. These are just my opinions about how I would think about applying just these concepts in general, to these types of data products that you all are out there building.

So, if you want more, well, you’re in the right place. This podcast, keep listening. You’ll get episodes every two weeks. Also, the home base for my publishing is, of course, my Insights mailing list, available at designingforanalytics.com/list or /podcast, if you head over there—that’s actually the better URL is designingforanalytics.com/podcast—go there, pop your email address in there, I’ll give you little one-page summaries of these emails. I’m sorry, not ‘of these emails.’ One-page summaries of these podcasts with highlights in them.

So, if you don’t have time to digest the entire audio, you can get a nice little one-page summary every two weeks, as well as my latest writing and thinking, as well as updates on my different services that I’m doing in this space and just work in this space. There’s so much going on right now. I know it’s hard to keep up, but I appreciate part of your ear in this little corner of the podcasting world, giving some attention to Experiencing Data. So, thank you so much. Until next time, take care. This is Brian, signing off.