Designing the human-in-the-loop layer of an AI agent product.

AI agents can now do real things inside a product: create a record, send something, change data. That's useful, but it's also where trust breaks if it's designed carelessly. An end user who watches an agent silently execute has no way to catch a mistake before it's made. Designing the checkpoint that prevents that, without turning every action into a tedious approval chore, is what I've been solving in this part of the Dubot product.

Before I designed a single screen, I ran structured discovery interviews across a research program spanning dozens of conversations with prospective and pilot customers in different industries, testing a specific hypothesis: that end users need a real, inspectable confirmation step before an agent's action goes live, instead of a generic "AI assistant" chat window with a vague sense that something happened.

I tracked how many of those interviews converged on the same requirement without being prompted toward it. The answer was most of them. People asked, unprompted and before seeing any design, whether the end user would see the result before it went out. Others said plainly that their own customers need to see what's about to happen before it happens, and not just be told that it did. It's a pattern that kept surfacing on its own, independently, across separate conversations with separate companies. That's the real evidence behind this pattern.

The end-user flow starts wherever the user already is: a prompt box asking what they'd like the agent to do. From there, the agent asks clarifying questions using real UI controls (choices, lookups, short forms) instead of burying everything in chat, so the user is never guessing what's expected of them.

Whatever the agent is about to do, the last step before execution is always the same: a full label/value view of what will happen, editable and cancelable, never just a "Confirm?" button standing in for a decision the user can't actually inspect.

A confirm-and-execute flow is easy to design for the case where everything works. The harder problem is everywhere around it: what the agent says when it can't find a confident answer and declines rather than guesses, what happens when an action needs disambiguation first, or gets blocked outright because an admin restricted it. I designed explicit states for declines, cancellations, execution failures with a retry path, and a walkthrough getting interrupted mid-step, each with its own recovery, not one generic error message standing in for all of them.

Some of that came directly from working closely with an enterprise pilot customer on their specific use case: real interviews with their team, feedback on early versions, and adjustments to fit how their product and their end users actually behaved, not a generic AI-agent scenario worked out in the abstract.

Dubot is currently built inside the infrastructure of the company's existing product, for engineering speed, with a standalone product as the long-term goal. I design every flow standalone-first, what's the right experience for this as its own product, and flag it explicitly whenever the current infrastructure forces a compromise, rather than letting temporary constraints quietly become the permanent design.

Dubot's end-user experience is live and in active development. It's early enough that I'm not sharing specific business metrics or an unreleased roadmap here, so this case study focuses on the design work itself: a full surface, not just a confirmation pattern, grounded in real interview research and a real pilot customer, and held up under real use.