The Invisible Shift · Part 2 of 3
Designing the Handshake
April 2026 10 min read
Five moments to examine when designing an agent workflow: preview, permissions, progress, debrief and recovery. Each helps people understand what the agent is doing and retain control. Use them as a checklist for a design review.
How does someone stay in control when an agent is doing the work? I use five moments to think through that question: before it acts, when setting its permissions, while it works, after it finishes and when something goes wrong.
In Part 1, I described the agent as the Proxy and the person supervising it as the Governor. This essay looks at the interaction between them.
I call these moments the Handshake, a checklist for design reviews that the following illustrative examples put into practice.
How Trust Develops
Trust develops through repeated experiences of a product doing what someone expects, respecting their limits and explaining what went wrong. A settings page or transparency dashboard can support that experience, but confidence depends on how the product behaves throughout use.
Think about the people you trust in your own life. You did not decide to trust them because they showed you a report card. You trust them because of a hundred small things: they showed up when they said they would, they told you when something went wrong instead of hiding it, they asked before making a big decision that affected you. Trust was built in the ordinary moments, not the impressive ones.
A successful task is only part of the experience. People also need to know whether an agent will respect a limit, ask before an important decision and explain a mistake. Each of those behaviours needs to be designed.
The Five Moments of the Handshake
I keep returning to these five moments because they offer a practical way to review an agent-powered feature. Considering each one helps a team identify where someone may need more information, a choice or a way to recover.
Moment 1: Before the agent acts
Before an agent acts, the person needs to understand the proposed action well enough to approve it or ask for a change.
The challenge is choosing the right level of detail, since a vague promise to “optimise your schedule” gives someone little basis for agreement, while an exhaustive account of every calendar change can obscure the decision they need to make.
A useful preview explains the proposed action and its most consequential tradeoff, including any cost, loss or disruption the person would want to consider before agreeing.
A travel agent could suggest an alternative to a cancelled flight by saying, “I found a direct flight that lands two hours later and costs $80 more, while still allowing you to make your hotel check-in. Would you like me to book this flight for you?” The person can assess the tradeoff and choose whether to proceed or explore other options.
A preview adds a step, so it needs to justify the attention it asks for. I would keep that step when the action carries a meaningful cost or is hard to undo, especially while someone is learning what the agent can do.
Moment 2: How much freedom to give
This one is about letting the user decide how autonomous the agent gets to be. And it is one of the hardest things to get right because different users want wildly different levels of control.
Some people prefer to approve every action, while others want the agent to handle routine work independently. Their preference can change with the task, the stakes and their experience of the product.
The level of autonomy needs to reflect the task, since someone may be comfortable with an agent responding to routine meeting requests but want to review any email it sends to a client. Controls should let that person express both preferences without choosing one global level of freedom.
A finance tool could let a business owner describe spending boundaries in plain language: “Automatically reorder office supplies when the total is under $200, but ask me before spending more or approving a new vendor.” The product would need to make those rules visible and apply them consistently.
A product that asks for approval on every routine action can become tiring, while one that acts freely can leave people uncertain about its limits. I would begin with clear boundaries and offer additional autonomy as the person gains confidence, allowing them to decide which responsibilities they are ready to delegate.
Moment 3: While the agent is working
This moment is easy to overlook because, from a technical standpoint, there might be nothing for the user to "do" while the agent works. But from an emotional standpoint, this is one of the most anxious moments in the whole experience.
When you request a rideshare, the moving car on the map helps you understand that the driver is on the way and whether the journey is progressing as expected. That visible progress offers reassurance while you wait for something you cannot directly control.
An agent-driven product needs a similarly useful signal that work is progressing and whether anything needs attention. The design challenge is providing enough visibility to reduce uncertainty without creating a stream of updates people learn to ignore.
An e-commerce agent repricing 500 products overnight could send a quiet midpoint update: “I have updated 280 of the 500 products without encountering any issues, and the remaining work is still in progress.” This gives the person useful context without requiring a response.
Complete silence can leave someone wondering whether the agent is working, while a live log of every action can make them feel they need to supervise it. I would give people a concise progress signal and a way to inspect the detail when they need it.
Moment 4: After the agent finishes
This is the moment most designers think about first, but I think it actually only works if the earlier moments were handled well. Because the debrief is where the user decides: "Did this thing actually do what I wanted?"
A useful debrief explains what changed, why it changed and anything the person needs to review, with access to the detailed record when that becomes necessary.
I would lead with the outcome, make the reasoning available and clearly identify exceptions that need attention, so the person can assess the result and act on any unresolved issue.
A hiring agent that reviewed 200 applications could summarise its work this way: “I moved 12 candidates to the interview stage and flagged four as strong matches for the senior role. I held one application for your review because the experience was unclear but the portfolio was strong.” The summary brings the outcome, reasoning and exception together for the person making the decision.
The "exception" piece is the most important part, and it is where I think good design really shows. Because the exception is where the agent is admitting: "I was not sure about this one." That moment of honesty is what builds trust over time. An agent that pretends to be confident about everything feels slippery. An agent that says "I made a judgment call and here is why" feels like something you can actually work with.
Moment 5: When something goes wrong
This is the most important moment of all. And it is the one that gets the least design attention.
An agent can act on incomplete information before a person notices the problem. Recovery therefore needs to be part of the main workflow: what can be stopped, what can be reversed and what the person needs to know.
A useful recovery explains what happened in plain language, contains the damage where possible and gives the person a clear next step. When the agent can safely reverse an action within its permissions, it should explain what it has restored and what still requires attention.
A scheduling agent that detects conflicting calendar availability could hold the overlapping bookings and explain, “Your Google Calendar and Calendly show conflicting availability for Thursday at 2pm, so I have paused confirmation of both meetings. Which meeting would you like me to keep at that time?” This gives the person a clear way to resolve the conflict before either booking is confirmed.
The recovery experience reveals whether a product can remain useful when something goes wrong. I would trust it more if it explained a mistake and helped me recover than if it left me to discover the problem and work out a remedy alone.
The Things I Got Wrong (So You Do Not Have To)
I want to share a few things I have learned the hard way while trying to apply this thinking. Because I think the theory always sounds cleaner than the reality.
I initially asked for too much approval. My focus on transparency led to detailed previews even when an action had little consequence. The lesson was to match the interruption to the stakes, summarising routine actions afterward when appropriate and pausing for a real decision before consequential or irreversible changes.
I underestimated how much tone affects understanding. Early agent messages were technically accurate but sounded like system notifications, leaving the person to interpret what had happened. I wanted the explanation to make the next step clear, such as, “I paused this action because the numbers looked inconsistent, and I need you to review them before I continue.”
I expected confidence to grow more steadily than it does. A single poorly handled failure can undermine trust built over many successful tasks, while an honest explanation and useful recovery can help rebuild it.
Reviewing these recurring moments together helps a team see where the product asks for attention, where it gives control and how it handles mistakes.
A Practical Place to Start
If you are reading this and thinking "okay but where do I actually begin," here is what I would suggest.
Choose one workflow that an agent already handles or will handle soon, then map how a person reviews its plan, sets boundaries, follows progress, assesses the result and recovers from a mistake.
The exercise can reveal interactions that have been left to technical defaults or have not yet been designed. Those gaps give the team specific questions to investigate with users.
Working through one workflow at a time gives the team a manageable way to improve the experience and test whether those changes help people understand and direct the agent.
For any agent-powered feature in your product, ask these five questions:
1. Does the user know what the agent is about to do before it does it?
2. Can the user control how much freedom the agent has, and does that control feel contextual rather than global?
3. Does the user get any signal while the agent is working, or is it silence until the end?
4. After the agent finishes, does the user get a clear summary or a data dump?
5. When something goes wrong, does the system tell the user honestly and help them fix it, or does it fail silently?
If the answer to any of those is "no" or "I am not sure," you just found your next design sprint.
Bring These Questions into the Design Review
Permissions, progress updates and failure recovery involve product, engineering and design. Designers can help the team understand what the person needs to know, when they need a choice and what it takes to recover from a mistake.
Start with one workflow and walk through all five moments together. The gaps should give you something specific to test. Part 3 looks at the skills this work asks us to develop.
the series
The Invisible Shift