Blog · November 5, 2026

When the customer's AI comes knocking: the front door, the permission slip and the approve button

Personal AI agents now contact customer support for shoppers. How brands can verify them, limit what they can do, and keep a human approving the risky steps.

By Adam Grohs, Co-Founder / Head of Product - Stackable Labs

Here's my favorite (least favorite?) customer service story of the fall...

It's one sentence, tucked into Decagon's guide to serving personal agents: "One early Grok Bot user's agent worked around a failed login by finding a sign-in link in the inbox and completing a cancellation on its own."

Nobody hacked anything. The agent did what it was asked, through a door nobody meant to leave open, and the brand never got to check whether a person actually wanted that cancellation.

Get used to it.

As Decagon put it in its Dialogues recap, "Customers are starting to send personal agents like Instinct, Muse, and dots to book, buy, cancel, and negotiate on their behalf." Zendesk opens its Open Service Directory announcement with the line every support leader should tape to a monitor: "Your company's next support request may come from a personal AI assistant."

Commerce is moving the same way. After agentic checkout came Shopify's shop.md, which lets a shopper's own AI assistant track their orders too. The first "where's my order?" from a customer's AI is not far off.

In Beyond the FAQ bot we wrote about the four jobs of an agent that acts: show the state, confirm with a real control, leave a receipt, and hand off with context. All four still apply. What's changing is who's on the other end of the conversation. Sometimes it's a person. Increasingly, it's the person's AI.

When that AI reaches your support, three things have to happen.

1. Find the real front door

First, the customer's AI has to find your actual support, not a lookalike with a convincing logo and a "refund processing" form. That's the job of Zendesk's Open Service Directory (OSD), "a specification and public directory of verified support destinations." Brands opt in, and "Listings are checked against the business's own domain and screened for impersonation."

For a lot of brands, the door it finds will be a messenger. Zendesk's OSD page says that for its own early access program, "Customers using Messaging with an AI agent or bot can register interest."

We'll be covering the commerce side in an upcoming post on the agnoStack blog. I'll stay on the conversation side.

On this side, what matters most is what OSD doesn't do: "The directory does not access private customer data or carry out support actions." It gets the customer's AI to your door. What that AI may do once inside is a different question.

2. Get permission to act

A verified front door tells the customer's AI it found the real brand. It doesn't tell the brand who the customer is, or what their AI may change. That's where this fall's consent work comes in.

• Decagon's PACT (the Personal Agent Consent & Trust Protocol, open-sourced October 6) is built on the Agent2Agent protocol (A2A) and OAuth 2.0. The flow is plain: "The customer signs in directly with the business, then chooses which permissions to approve," with scopes "such as orders:read or orders:cancel." And every action comes back with a record: replies "include signed receipts recording the scopes used and actions taken."
• Decagon's Personal Agent Gateway, announced at Dialogues on October 1, gives personal agents a dedicated channel and detects the ones that don't identify themselves.
• The draft Personal Agent Protocol (PAP, or "Poppy"), published by Sierra with Zendesk among its design partners, starts from the same place: "customers decide what access to give their personal agents." When an agent signs in for the customer, it gets "a session token that grants only the access the customer approved."

The shared idea: permission is a scope the customer granted, not a vibe the agent inferred. orders:read is not orders:cancel, and the brand should be able to tell which one it got.

It's also exactly what went wrong in the Grok Bot story. Inbox access isn't approval, and Decagon's guide says so: "A one-time code sent to the email on file establishes inbox access, but not necessarily customer approval when an agent has that access too."

3. Hand the risky step back to the human, in a real interface

Scopes cover what the customer said yes to ahead of time. Some things shouldn't be pre-approved at all.

Decagon's guide draws the line clearly: "Low-risk, reversible requests can proceed with delegated authorization. Actions that require direct participation or are costly to reverse should involve the customer." And: "Anything beyond those permissions should return to the customer for approval through an authenticated experience."

Zendesk puts the brand in charge of that line. Per its OSD page, "The brand decides what information can be accessed, which actions are permitted and when human review is required."

Helpdesk AI vendors are building the same loop from the inside. Intercom's Fin 4 added Human in the Loop: "When a conversation needs a review, piece of information, or an approval, Fin will loop in a human to approve, edit, or take over." There the human is a support teammate. With a personal agent on the other end, sometimes the human who has to approve is the customer.

Everyone agrees there's an approval moment. Almost nobody says what it should look like. "An authenticated experience" is right, and also not a screen. Here's what I think that screen needs. It's the four jobs from August with the stakes turned up:

Show the exact thing being approved. The order, the items, the amount, the date. Not "your recent order." If the customer's AI asked to cancel order #48213, the human sees order #48213.

Use a real control, not a typed "yes." In August I wrote "never let free text be the only confirmation for something irreversible." With an AI on the other side, that moves from good UX to basic security: a customer's agent can type YES as easily as anything else. A button isn't proof of a human by itself (the sign-in is), but it's where a signed-in person sees exactly what they're agreeing to and decides.

Leave a receipt in the thread. PACT's signed receipt is for machines. People need one too: "Cancellation approved for order #48213, $84.00 refunded to your card," right in the conversation, where the customer, their agent and your team can all see it.

Hand off with context. When the brand's AI loops in a teammate, they should know the conversation started with a personal agent, which permissions it had and what it already tried, with the order and customer right in front of them in Zendesk.

Where Stackable fits

That approval moment is the part of the stack we work on. Stackable extensions render real UI in surfaces around the Zendesk messenger, and each of the four jobs maps to something in the SDK:

• Show the state: data.fetch calls your systems through Stackable's proxy, only to domains on the extension's allowlist. API keys are injected server-side, so the real secret never enters extension code. context.read gives the extension the customer's identity state, so it can tell whether someone is signed in before it shows anything sensitive.
• Confirm: cards, badges and buttons that inherit the brand's theme, not a magic word.
• Leave a receipt: messaging.send posts text, images, files or carousels into the active conversation.
• Hand off: actions.invoke can start a new conversation or set conversation tags and fields, like the order ID in a ticket field, so the teammate who picks it up knows exactly what's going on.

There's a nice symmetry in how extensions are governed, too. PACT asks the customer's agent to work within approved scopes. A Stackable extension declares the permissions it needs in its manifest, and marketplace submissions go through an automated scan against that manifest and a review. If you're going to ask a customer's AI to prove what it's allowed to do, the UI on your side of the conversation should meet the same standard.

What we don't do: we're not a directory, a consent protocol or an AI agent. OSD handles the directory, PACT and PAP handle consent, and your AI agent (Zendesk's own, a Custom Agent or another) stays the brain of the conversation. We're the screen where a person says yes.

Agents on both sides

Until now, "agents that act" meant the brand's agent. Now the customer has one too, and a conversation in your messenger can be two AIs and a person who'd rather not be bothered until it matters.

That's fine. Let the agents find each other, check the permission slip and handle the routine stuff. In Meet Jev we called the top layer of the stack "perform." With an agent on each side, its most important job is making sure that when it does matter, the person sees exactly what's about to happen and taps the button themselves.

If you want to see what that layer looks like in a real messenger, see it in action. If you're building, the developer docs go from create to a live preview in minutes.