The Invisible Shift · Part 2 of 3
Designing the Handshake
April 2026 10 min read
Trust is not a feature you ship; it is a feeling that accumulates through five moments. The Preview (what the agent will do). The Leash (how much autonomy it gets, contextually not globally). The Pulse (a heartbeat while it works, not a log dump). The Debrief (outcome first, reasoning second, exception last). The Repair (when something goes wrong). Most products design the first four and ignore the fifth, which is exactly where trust leaks out. The Repair is the character test: a product that handles its own mistakes well will outperform one that gets things right 95 percent of the time and falls silent the other 5. Trust is non-linear; one bad moment can set you back weeks, one great one can jump you forward.
If you read Part 1, you know the big argument: the screen is fading into a status report, and the real product is becoming invisible. But the question I kept circling back to after writing it was more practical than philosophical. It was some version of: "Okay, but what do I actually do about this on Monday morning?" Fair question. I did not have a great answer at the time. This post is my attempt at one.
In Part 1, I talked about how our user is splitting in two: The Proxy (the agent that does the work) and The Governor (the human who has to trust the work got done right). I think most of us get the concept by now. What we do not have yet is a shared vocabulary for how to actually design the relationship between those two.
So that is what this post is about. Not theory. Patterns. Real, tangible things you can start thinking about in your next design review. Things I have been experimenting with, reading about, and in some cases getting wrong. I want to walk through what I have been calling "The Handshake," the set of design moments where the human and the agent negotiate trust with each other.
Trust Is Not a Feature. It Is a Feeling.
Before we get into the patterns, I want to say something that I think gets lost in the way people talk about this stuff.
Trust is not a toggle you turn on. It is not a settings page. It is not a "transparency dashboard" you tack onto the side of your product and call it done. Trust is a feeling that accumulates (or erodes) through dozens of small moments over time.
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.
Agent-driven products work the same way. The user does not trust the agent because it completed a task successfully once. They trust it because of how it behaved across many tasks, across edge cases, across the moments where things did not go perfectly. Those small moments are design decisions. And right now, most teams are not designing them deliberately. They are treating them as edge cases, or worse, leaving them to engineering defaults.
That is the gap I want to help close.
The Five Moments of the Handshake
As I have been thinking about this, I keep seeing the same five moments come up over and over. Every interaction between a human and an agent passes through some combination of these. They are not a rigid framework. Think of them more like a checklist. If you are designing an agent-powered feature and you have not considered each of these, something is probably going to feel off to the user.
Moment 1: Before the agent acts
This is the moment where the agent says "here is what I am about to do" and the human gets to say "go ahead" or "wait, not like that." It sounds simple. It is not.
The challenge is specificity. If the preview is too vague ("I will optimize your schedule"), the user does not know what they are agreeing to. If it is too detailed ("I will move your 2pm meeting to 3pm, cancel your 4pm, and block 5pm for focus time based on your last 30 days of calendar data"), you have just given them a wall of text they will not read.
The sweet spot is showing the headline action plus the one thing the user would most want to know about. For most people, that is the potential downside. What could go wrong. What they might lose. Lead with that, and the rest of the preview feels manageable.
A travel agent suggests rebooking a cancelled flight. Instead of listing every option it considered, it shows: "I found a direct flight that lands 2 hours later than your original. It costs $80 more. Your hotel check-in still works. Want me to book it?" Three sentences. The key trade-off is clear. The user can say yes in five seconds or dig deeper if they want to.
I have seen teams skip this moment entirely because they think it slows the product down. And it does, a little. But here is the thing. A preview that takes five seconds builds trust. An agent that acts without asking and gets it wrong destroys trust in a way that takes weeks to rebuild. The five seconds is worth it. Especially early in the relationship, when the user is still figuring out whether they can rely on this thing.
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 want to approve every action. Some people want to set it and forget it. Most are somewhere in between, and where they land changes depending on the task, the stakes, and how long they have been using the product.
The key insight I keep coming back to is that the leash should not be a global setting. It should be contextual. A user might be totally comfortable letting an agent auto-respond to routine meeting requests but would never want it to send an email to a client without checking first. Same user, different leash length, different context.
A finance tool lets a business owner set spending thresholds per category. "Reorder office supplies under $200 automatically. Anything over, ask me first. Never auto-approve new vendors." Each rule is a simple sentence, not a complex settings panel. The user is drawing boundaries in plain language. The agent respects them.
What I have noticed is that most products default to either "the agent asks every time" (which gets annoying fast) or "the agent does everything unless you tell it to stop" (which feels unsafe). Neither extreme works. The right answer is almost always graduated autonomy. Start with more check-ins, and as the user builds confidence, offer to handle more on its own. Like training a new employee. You hover at first. Then you gradually let go.
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.
Think about hailing a rideshare. You press the button and then you wait. The map showing the driver's car moving toward you is doing almost nothing functional. But emotionally, it is doing everything. It is telling you "this is happening, it is on track, you can relax."
Agent-driven products need the same thing. Not a loading spinner. A pulse. Some lightweight signal that the agent is active, that things are progressing, and that nothing has gone sideways. The design challenge is giving just enough visibility to prevent anxiety without creating noise the user learns to ignore.
An e-commerce agent is repricing 500 products overnight based on competitor data. Instead of silence until morning, it sends a single quiet notification at the midpoint: "Repricing in progress. 280 of 500 done. No issues so far." Not asking for anything. Just a heartbeat.
I think this is the one most products get wrong right now. Either there is total silence (which feels like a black box) or there is a live log of every action (which is overwhelming and makes the user feel like they need to supervise). The sweet spot is somewhere between a heartbeat and a headline. Enough to feel present. Not so much that it demands attention.
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?"
The temptation is to dump everything: every action, every decision, every data point. Do not do this. The user does not want a log. They want a story. "Here is what I did, here is why, here is the one thing I need you to look at."
The structure I keep coming back to is: outcome first, reasoning second, exception last. Start with the result. Then explain the logic if they want it. And if something went off-script, surface that clearly and give them a path to fix it.
A hiring agent screened 200 applications overnight. The morning debrief: "12 candidates moved to interview stage. 4 were flagged as strong matches for the senior role. 1 application was held because the candidate's experience did not clearly match your requirements, but their portfolio was strong. Want to take a look?" Outcome. Logic. Exception. One screen.
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.
In traditional products, error handling is an edge case. In agent-driven products, error handling is the main event. Because the agent is going to get things wrong. That is not a bug. That is the reality of autonomous systems making judgment calls with imperfect information. The question is not "will it make mistakes?" The question is "when it makes a mistake, does the experience fall apart or does it recover gracefully?"
The repair needs to do three things. First, be honest. Tell the user what happened clearly, without jargon or hedging. Second, contain the damage. If the agent can undo or mitigate what went wrong, it should do that automatically and explain what it did. Third, give the user a clear next step. Not "an error occurred." Something like "this happened, here is what I did about it, and here is what you might want to do next."
A scheduling agent double-booked a client meeting because two calendar sources had conflicting availability. Instead of silently breaking, it catches the conflict, holds both bookings without confirming, and messages the user: "I found a conflict between your Google Calendar and your Calendly. Two meetings are overlapping on Thursday at 2pm. I have not confirmed either one yet. Which would you like to keep?"
I keep telling people this: the repair moment is your product's character test. It is the difference between a system that feels like a competent partner and one that feels like a liability. Every product ships with bugs. But an agent-driven product that handles its own mistakes well will outperform one that gets things right 95% of the time but falls silent when it gets them wrong.
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 over-designed the preview at first. I was so focused on transparency that I turned every agent action into a detailed approval flow. Users hated it. It felt like the agent was asking permission to breathe. The lesson: the preview should match the stakes. Low-stakes, routine actions can be summarized after the fact. High-stakes or irreversible actions need a real pause. You have to earn the right to skip the preview, and the way you earn it is by getting the low-stakes stuff right consistently over time.
I underestimated how much tone matters. The way the agent communicates changes everything. Early on, the messages from our agent were technically accurate but felt robotic. Very "system notification" energy. When we rewrote them to sound more like a helpful coworker ("Hey, just a heads-up, I paused this one because the numbers looked off. Want to take a look?"), engagement with the debrief went up significantly. People were actually reading them. Tone is not cosmetic. It is structural.
I forgot that trust is not linear. I assumed trust would build steadily over time. It does not. One bad repair moment can set you back weeks. One great repair moment can jump you forward. Trust is more like a stock price than a progress bar. It reacts to events. Design accordingly.
The five moments are not a funnel. They are a loop. Every cycle through them either adds a little trust or takes some away. The product is always either earning confidence or losing it. There is no neutral.
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.
Pick one workflow in your product that an agent currently handles or will soon handle. Just one. Map the five moments for that workflow. Where is the preview? Where is the leash? What does the pulse look like? What does the debrief say? And most importantly: what happens when something goes wrong?
I am willing to bet that when you map it out, you will find that two or three of those moments have no design at all right now. They are either handled by engineering defaults or they just do not exist. Those gaps are where trust leaks out.
You do not need to overhaul your product. You just need to start filling those gaps. One workflow at a time. One moment at a time.
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.
Why This Is Still a Design Job
I want to close with something I have been thinking about a lot.
There is a narrative out there that says agent-driven products are an engineering challenge, and that design is just window dressing on top. I do not buy that. At all.
Every single one of these five moments is a human question dressed up as a technical one. "How much autonomy should the agent have?" is not an algorithm question. It is an empathy question. It requires understanding what the user is afraid of, what they value, and what they are willing to let go of. "How should the agent communicate a failure?" is not a notification-system question. It is a relationship question. It requires understanding how honesty feels, and how the difference between "something went wrong" and "here is what happened and here is what I did about it" is the difference between anxiety and confidence.
These are the questions designers have been answering for decades. The surface has changed. The craft has not.
We know how to make things feel trustworthy. We know how to make complexity feel approachable. We know how to turn a confusing experience into a clear one. We have just never had to do it for a relationship between a person and an autonomous system before.
But the muscle is the same. I really believe that. And I think the designers who lean in here, who claim this territory instead of waiting for someone else to define it, are going to have the most meaningful careers of anyone in this industry over the next ten years.
Part 3 is about what that career actually looks like. How our skills evolve, how our identity shifts, and what it means to be a designer when the job stops looking like what we were trained for. See you there.
the series
The Invisible Shift