Zendesk's Open Service Directory:
How Personal AI Assistants find Customer Support

On Friday we looked at WebMCP, and where it stops: a shopper's agent can search, fill a cart and check out, but after checkout the tools end at the order history page. So what happens when that agent needs a return, an exception or a person?

It has to find the brand's real support first. That's the problem Zendesk's Open Service Directory (OSD) is built to solve, and the one we said we'd dig into back in agentic checkout is here.

What Open Service Directory is

Zendesk introduced OSD in October as "a specification and public directory of verified support destinations." Its opening line sets up the problem well: "Your company's next support request may come from a personal AI assistant."

Thomas Verschoren, who writes about Zendesk at Internal Note, has the simplest description: "Think of the Open Service Directory as a phonebook for AI Agents."

Two details matter more than the name suggests:

• It isn't Zendesk-only. "Any brand using Zendesk or another service platform can list on OSD," and per Zendesk's OSD page, "You do not need to be a Zendesk customer and there is no cost to participate."
• It's built for the assistants shoppers already use. Zendesk lists it as compatible with ChatGPT, Claude, Gemini, Muse, Instinct and Grok Bot, and brands including Betterment, ElevenLabs and Telekom Payment are helping shape it.

How will OSD work in the real world

Zendesk describes three steps:

1. Listing. A brand opts in and approves a support listing through its service platform. "Listings are checked against the business's own domain and screened for impersonation."
2. Discovery. A shopper's AI assistant looks the brand up in participating registries and verifies the match before using it.
3. Connection. The assistant connects directly to the brand's support, under the brand's own authentication, permissions and policies, using "the protocols they support which may include PAP, PACT or UCP."

Verschoren adds useful detail on the hand-off. The listing can point to a brand's AI agent, but also to an email address or an existing support form. The assistant passes along the task-specific details, not the whole conversation, and the interaction is logged in the brand's support platform like any other. His summary: "The AI Assistant drives the interaction, the Open Service Directory provides the route; the AI Agent handles the task."

OSD is more like a phonebook than a help desk

Like WebMCP, OSD is easy to over-read:

• It's not where the work happens. "It provides a discovery layer, not the runtime that executes the request." OSD builds on the Agentic Resource Discovery (ARD) spec, which handles finding things, not doing them.
• It's not a knowledge base. "The listing is a directory entry: it does not contain a knowledge, procedures or internal business logic."
• It doesn't touch customer data. In Zendesk's words: "The directory does not access private customer data or carry out support actions."

In other words, OSD gets the shopper's agent to the right door. Everything that happens after it walks through is up to the brand.

The open questions

OSD is a draft, and it's worth being clear-eyed about what isn't settled yet.

Will the assistants actually use it? Keith Kirkpatrick at Futurum makes the sharpest point: "Compatibility means an assistant could use OSD; it does not mean OpenAI, Anthropic, or Google will query it by default." The launch partners are brands, not assistant makers. His conclusion: "Until they do, OSD is a well-reasoned proposal, not a market standard." He also flags the risk that rival CX platforms like Salesforce, ServiceNow, Genesys and NICE back their own discovery approaches, which would fragment the very thing OSD is trying to unify.

Who is the agent acting for? A verified listing tells the assistant it found the real brand. It doesn't tell the brand who the customer is, or whether the assistant is allowed to act for them. Verschoren is direct about it: a listing doesn't authenticate the customer, and "a listing alone does not make every action possible." Zendesk says it's building controls to identify the assistant and the customer it represents, with the goal of "visibility into who acted, with what permission and what happened."

None of that makes OSD less important. OSD answers one question: where is this brand's real support? The rest of a trustworthy hand-off is being worked out in other specs, and some of them already cover what OSD's own controls don't yet:

• Which agent is calling. Web Bot Auth, an IETF draft from authors at Cloudflare and Google, has an agent sign its HTTP requests so a site can verify them cryptographically. OSD verifies the brand. It doesn't yet verify the assistant.
• Who the agent acts for, and what it may do. Sierra's draft Personal Agent Protocol (PAP) has a personal agent identify itself and sign in with "a session token that grants only the access the customer approved." Its own example is a jacket return, where the retailer lets the agent "start a return but not change the payment details on file." That's the scoped permission OSD is still building, and Zendesk is one of PAP's design partners.
• Proof of what the customer agreed to. Google's Agent Payments Protocol (AP2) records consent as signed mandates: a Checkout Mandate for the items and purchase details, and a Payment Mandate that "authorizes a payment against a specific payment instrument." Nothing comparable exists yet for a support request like "exchange this for a medium." The customer's side of that consent is the most mature piece: passkeys, built on WebAuthn, let a customer approve on their own device without handing an agent a password, and the FIDO Alliance behind passkeys is now where AP2's standardization continues.
• A shared vocabulary for the order. The Universal Commerce Protocol (UCP) publishes a store's commerce capabilities at a well-known location (/.well-known/ucp), including an order capability that reports fulfillment, returns and refunds. But like Shopify's Order MCP, it reads the order. It doesn't change it.
• The connection itself. Once the assistant finds the brand, the conversation runs over whatever both sides support: MCP, A2A, PAP, PACT or UCP. OSD is deliberately agnostic about that.

Put together, OSD is the address, Web Bot Auth the caller ID, PAP the permission slip, AP2 the signed receipt, a passkey the customer's signature and UCP the shared language for the order. What none of them standardize yet is the post-purchase action itself: start the return, approve the exchange, change the address. That part is still each brand's to build, which is why the brand side has to be ready for the day all of this works.

What commerce brands need behind the door

Picture the request that comes through. A shopper tells their assistant the jacket they ordered arrived in the wrong size and they want the right one before a trip on Friday. The assistant finds the brand through OSD and connects to its AI agent in Zendesk.

Now that agent has to actually resolve it:

• Find the order, wherever it was placed: the online store, Shop, Google's Universal Cart or a marketplace.
• Check the policy for that product, that market and that customer, including whether a loyal customer gets a free expedited exchange.
• Check stock for the right size, and where it would ship from.
• Act: create the exchange, generate the return label with the 3PL, ship the replacement and adjust the payment.
• Confirm it back to the assistant, and leave a full record for the team if the customer follows up.

That's not a directory problem. It's the order, the customer and the actions across the retailer's whole back office, available to the AI agent at the moment it needs them. And it's exactly the part WebMCP's tools and OSD's listings both leave to the brand.

A few things worth doing now:

• Register interest. It's free, and Zendesk says customers using Messaging with an AI agent or bot can sign up on the OSD page.
• Decide what an outside agent may do. Tracking is easy to say yes to. Exchanges, cancellations and address changes need a policy before an assistant asks.
• Give your AI agent real actions. An agent that can only answer questions will hand most of these requests to a person anyway.
• Mark agent-originated conversations. Your team should know when they're picking up a conversation an assistant started.

What's next

Zendesk says it will share more about OSD at its Zendesk AI Summit this Thursday, November 12. We'll be watching for the identity and permission controls in particular, and we're looking forward to leaning in further on Zendesk's industry Specialized AI Agents, starting with commerce. More on those soon.

On our side, agnoStack's Actionable Options already let agents run custom actions on an order straight from the Order Details panel in Zendesk, and the agnoStack API, in Early Access, gives Zendesk AI agents one secure path to data across commerce, payments, shipping, loyalty, CRM and more.

If you're thinking about what your AI agent needs once a shopper's assistant finds you, or want to join the agnoStack API EAP, email us at support@agnostack.com.