Smartphone notification confirming an AI-booked plumber appointment — the trust question at the heart of agentic commerce

What Happens to Trust When an AI Books My Plumber?

Will’s Take is editorial perspective — opinion, future-casting, and industry observation from Will Tygart. Not analysis. Not client work. Just how I see it.

I’ve been thinking about a specific moment.

You get a notification. Your agent booked a contractor to come to your house tomorrow at 9am. You didn’t pick them. You didn’t talk to them. You didn’t Google them, read their reviews, ask a neighbor, or get a gut feeling from a phone call. The agent evaluated capability profiles, checked availability, cross-referenced ratings data, and made a call.

Do you feel okay about that?

I think most people’s honest answer right now is no. Or at least — not yet.

And that gap between what the technology can do and what people are actually willing to hand over is the most interesting design problem in agentic commerce. More interesting than the protocol spec. More interesting than the payment rails. More interesting than the latency optimization.

Because trust isn’t a feature you ship. It’s something that accumulates slowly and disappears fast.

We’ve been here before, sort of.

When Uber launched, people thought it was insane to get in a car with a stranger. No medallion. No background you could verify. No dispatcher who knew the driver. Just a rating system and a prayer.

It worked because the feedback loop was tight and visible. You rode, you rated, the system updated. Enough rides happened that the aggregate signal became trustworthy even if any individual data point wasn’t. And critically — you were in the car. You could see the driver. You made the final call to get in.

Agentic service booking removes that final human checkpoint. The agent doesn’t just surface the option — it commits. By the time you’re involved, the appointment is made, the contractor is on their way, and the authorization has been captured.

That’s a different trust architecture than anything we’ve built before.

The trust problem has three layers and most people only talk about one.

The first layer is competence trust. Can the agent find a good contractor? Does it have access to enough signal — licensing, insurance, ratings, response history — to make a reasonable selection? This is the layer most people argue about and honestly it’s the most solvable. Data problems are solvable. You aggregate enough verified signal and the selection quality gets good.

The second layer is intent trust. Is the agent actually optimizing for me? Or is it optimizing for something else — speed, cost, a preferred network, a kickback structure I don’t know about? This is where it gets uncomfortable. Because the agent’s incentive structure isn’t always visible and in a world where agents are making consequential decisions on your behalf, that invisibility matters.

The third layer is accountability trust. When something goes wrong — and something will go wrong — who is responsible? The contractor? The platform? The agent that made the selection? The company that trained the agent? This layer is almost entirely unresolved and it’s the one that will determine how fast agentic service commerce actually scales.

The industries I work in deal with this constantly, just in analog form.

When an insurance carrier assigns a preferred contractor to a water damage job, the homeowner didn’t choose that contractor. The carrier did. Based on their network, their pricing agreements, their performance data. The homeowner gets who shows up.

Most homeowners don’t love this. But they accept it because the carrier is a known entity with accountability and the relationship is structured — there’s a claim number, there’s documentation, there’s a process for dispute.

UCP-native service booking needs that same accountability scaffolding. Not just a capability profile and a rating. A clear chain of responsibility. A structured dispute process. Something that answers the question: if this goes wrong, what happens next?

The protocol can carry that information. The question is whether the industry builds it in or bolts it on after the first wave of failures.

Here’s my honest take.

I think the trust problem is real but it’s not permanent. Every new transaction modality goes through this. Credit cards felt unsafe. Online shopping felt unsafe. Getting in a stranger’s car felt unsafe. The feedback loops get established, the accountability structures get built, and the behavior normalizes.

What worries me more is the transition period. The window where the technology is capable enough to make consequential decisions but the trust infrastructure hasn’t caught up. That’s where the bad outcomes happen that set the narrative for years.

The companies and platforms building on UCP for service industries need to think hard about accountability architecture before they think about scale. Because the first high-profile failure — the contractor who shouldn’t have been in someone’s house, the job that went wrong with no clear recourse — is going to land on the entire category.

Trust is slow to build and fast to break. That’s as true for protocols as it is for people.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *