Agentic AI · A personal perspective · 4 min read

A good agent workflow needs more than an approval button.

A design system can make an interface look right. It cannot tell us whether the experience makes sense to the person using it.

I’m interested in what happens between a person asking for something and an agent doing it. That space is full of decisions: what the request really means, what information is missing, what the agent is allowed to change, and when the person needs to step back in.

For me, human-in-the-loop design starts there. Not with a confirmation dialog added at the end, but with understanding the whole journey.

First, understand what is at stake.

Before deciding what to automate, I want to understand what the person is trying to achieve. Where are they unsure? What do they check manually? Who else depends on the result? What happens if the system gets it wrong?

Product data helps me identify where something is breaking down. Customer research helps me understand why. I need both. A step that looks slow in a funnel might be unnecessary friction — or it might be the moment someone is carefully checking a consequential decision.

That distinction changes what I design. Removing a step is not automatically an improvement. Sometimes the better experience is a clearer explanation, a useful comparison, or a chance to correct an assumption before work continues.

An approval should be a meaningful decision.

If I ask someone to approve an agent’s work, I need to give them enough context to make that approval real. “Continue?” is not enough when the person cannot see what will happen next.

• Intent: What is the agent trying to achieve, and does that match my request?
• Scope: What will change, and what will remain untouched?
• Evidence: What information supports this proposal? What is still uncertain?
• Control: Can I edit, narrow the scope, reject, or stop?
• Recovery: If something goes wrong, can I understand it and take a useful next step?

I also don’t want to ask for approval so often that it becomes a reflex. The question is where human judgment genuinely matters, not how many approval buttons I can add.

Design the awkward parts, too.

A polished happy path tells only part of the story. I want to explore what happens when the input is incomplete, two sources disagree, the agent loses context, or someone changes their mind halfway through.

These are experience-design problems as much as technical ones. A status label, a handoff, or an explanation can determine whether someone feels able to continue. The interface needs to show what happened, what did not happen, and what the person can do now.

In Uxi, I’m exploring this through visible plans, human checkpoints and reviewable evidence. It is an independent working prototype, a place to test these interaction ideas rather than assume that adding a human gate has solved the problem.

Follow the decision into the implementation.

Building has made me more attentive to the gap between a design and its actual behaviour. A component can match the design system and still respond at the wrong time, hide an important state, or make recovery confusing.

That is why I like staying involved beyond the design file: working through the logic, checking the implemented journey, and revisiting it when evidence shows that something is not working. The intended experience needs to survive the details of delivery.

To judge success, I want to look beyond whether the agent finished its task. Could the person recognise an error? Make an informed choice? Recover without starting over? Did the change actually help them achieve what they came to do?

The question I keep returning to: can the person understand what is happening, make a meaningful choice, and recover when it goes wrong?

For me, that is the designer’s responsibility in an agentic workflow. Not just making the output look good, but going deeply enough into the customer’s experience to make the work genuinely better.