Your next support case may come from a customer's AI assistant. Decide how you will verify it
Zendesk has proposed an Open Service Directory so personal AI assistants can find and verify a brand's official support agent. Whether or not it becomes the standard, service teams on Salesforce and elsewhere should decide now how they will authenticate an assistant, which actions they will delegate, and how they will measure cases it starts.
Every service design I have worked on assumes the person on the other end is the customer. They might be on the phone, in chat or in a portal, but it is a human, and we authenticate them as one.
That assumption is starting to wobble. People already ask AI assistants to book things and chase things for them. Sooner or later one of those assistants will try to open a case with your company. This week a Zendesk proposal made that future concrete, and a Futurum analyst gave a useful reality check on it. Together they are a good prompt to make some decisions early.
What Zendesk proposed
Zendesk announced the Open Service Directory, or OSD, as a specification and public directory of verified support destinations. Its blog opens with a simple line: "Your company's next support request may come from a personal AI assistant." The problem it is trying to solve is that assistants have no shared, trusted way to check they are reaching a brand's official support, which leads to wrong answers, dead ends and customers starting over.
Zendesk describes three steps. A brand opts in and approves a support listing through its service provider, and any brand on Zendesk or another service platform can be listed. Listings are checked against the business's own domain and screened for impersonation. An assistant then searches participating registries, verifies the match and connects to the brand's approved support.
The developer docs add the mechanics. A brand publishes its listings in a manifest at https://{brand-domain}/.well-known/ard.json, and publishing an entry there is the business's endorsement of that agent. A registry result only counts as endorsed if it matches an entry in that manifest. The assistant then connects to the support agent through MCP or A2A, and the brand's agent handles authentication, permissions and the operations it offers.
Zendesk is clear that once connected, the assistant works within the brand's authentication, authorization and service policies. The brand decides what customer information can be accessed, which actions are allowed and when a human steps in. The directory itself does not access private customer data or carry out support actions. Zendesk says it is also developing controls to identify the assistant and the customer it represents, and to decide which providers can connect.
The reality check
Keith Kirkpatrick at Futurum thinks Zendesk has the diagnosis right: discovery and trust, not conversation quality, will be the first thing to break in agent-to-agent service. He also points out the risk for brands if assistants reach support through unofficial channels, including the spoofed support numbers that already catch people out.
But he is careful about adoption. The specification is in draft, core documentation sections are not yet published, and the assistant identity and permission controls are still being built. The launch partners are brands and platforms, not AI assistant providers, and in his words "compatibility means an assistant could use OSD; it does not mean OpenAI, Anthropic, or Google will query it by default." He names Salesforce, ServiceNow, Genesys and NICE as rivals with their own agent platforms, and warns that competing discovery approaches could fragment the market.
His advice is the part I would act on: do not wait for a standard to settle. Audit where your support entry points are discoverable today, decide how you will authenticate an assistant acting for a customer, and define which actions you are willing to delegate.
What I would do on a Salesforce service org
None of this depends on OSD winning. It is groundwork you need whichever discovery approach takes off.
- List your public support entry points. Phone numbers, chat, email addresses, portals and any agent endpoints. Know which ones are official and published on your own domain, so there is a clear answer when anyone, human or assistant, asks.
- Decide what proof an assistant must bring. An assistant acting for a customer is not the customer. Decide what it must present before it can see account data, and keep your normal customer verification in place for anything sensitive.
- Sort actions into tiers. For example: answer general questions with no login; check order or case status after verification; change bookings or issue replacements only after the customer confirms. Write it down per action, not per channel.
- Tag assistant-started cases. Add a value on Case Origin or a similar field so you can tell when an external assistant opened or worked a case. Without it you cannot report on volume, resolution or complaints from this channel.
- Protect the handoff. Zendesk's design moves the request to a human with the conversation history and actions already taken. Check your own routing does the same, so the case arrives with context instead of a blank transcript.
- Agree what counts as resolved. Futurum raises the point that if a customer's assistant deals with your agent, you still need to know whether the issue was solved and whether the customer was happy. Settle that definition before it turns up in a vendor contract priced on outcomes.
The takeaway for CRM and RevOps teams
OSD may or may not become the standard. That matters less than the shift it points to: some of your customer contacts will soon arrive through software working for the customer, not through the customer directly.
The teams that cope well will be the ones that already know their official entry points, have a written rule for what an assistant must prove, have tiered which actions they will delegate, and can report on cases an assistant started. All of that sits in your CRM and service configuration, and all of it can be done now.