Zendesk Open Service Directory: o que é, como funciona e o que já está no ar

O que é o Zendesk Open Service Directory?

O Open Service Directory é a resposta da Zendesk a um novo tipo de solicitação de suporte: a que chega do assistente de IA pessoal de um cliente em vez do próprio cliente. No post de lançamento da Zendesk, escrito por Jad Chamoun (Senior Director of Applied AI) e Will Poon (Director of Product Management para Messaging e AI), ele é descrito como "a specification and public directory of verified support destinations."

Eu construo integrações para viver, então li o lançamento como leio qualquer anúncio de API: qual é o contrato, quem hospeda o quê e o que está sendo entregue versus prometido. Aqui vai a versão curta.

Se os nomes de assistentes dessa lista são novos para você, escrevi separadamente sobre OpenAI Dots, Instinct AI e Grok Bot. O OSD é a primeira vez que um fornecedor de helpdesk tenta dar a todos eles uma porta de entrada comum.

Por que um assistente de IA precisaria de um diretório para encontrar suporte?

Porque hoje ele adivinha. O exemplo da própria Zendesk é um cliente perguntando a um assistente: "Can you move my air conditioner repair appointment to Monday?" O assistente encontra os artigos de ajuda da empresa, mas remarcar o atendimento exige chegar ao suporte real da empresa, e não existe uma forma comum e confiável de checar se o "suporte" encontrado é da marca e não uma imitação.

Isso não é um problema de futuro distante. Já vi assistentes direcionarem compradores reais: um prospect contou à equipe da eesel numa call de vendas que encontrou a eesel porque um assistente de IA a recomendou diretamente, junto com a dica de um amigo no jantar da noite anterior. Se os assistentes já escolhem fornecedores em nome de um comprador, também vão escolher centrais de suporte em nome de um cliente, e uma escolha errada ali significa um cliente entregando dados do pedido a um falso help desk.

Os céticos têm um ponto justo sobre onde isso vai parar quando houver algo a ganhar. Quando a especificação ARD do Google, a camada base sobre a qual o OSD se apoia, chegou ao Hacker News, o comentário mais votado resumiu:

"This seems useful as a standard interface, but, again, doesn't solve the harder discovery problem. Once there is value in appearing in the top results, the system inherits the same adversarial dynamics as SEO/app stores, spam, scams, etc."

wslh, Hacker News

A resposta do OSD a isso é a regra de endosso da próxima seção, e acho que é a decisão de design mais importante de toda a especificação.

Como o Open Service Directory funciona

A Zendesk descreve em três passos: listar o suporte aprovado, encontrar o negócio certo, conectar ao suporte oficial. A documentação para desenvolvedores do OSD detalha a mecânica, e ela é refrescantemente pequena.

Passo 1: a marca publica uma listagem no próprio domínio

A marca descreve cada agente de suporte que quer que os assistentes encontrem em um manifesto JSON em https://{brand-domain}/.well-known/ard.json. Cada entrada é uma entrada ARD normal (um identificador, um nome de exibição, uma descrição, consultas de exemplo e um link para o MCP Server Card ou A2A Agent Card do agente) mais dois campos do OSD: osd:brandName e osd:brandDomain. Aqui está o exemplo reduzido da página sobre OSD e ARD, usando a companhia aérea fictícia deles:

{
  "identifier": "urn:air:airline.example:support:assistant",
  "displayName": "Example Air Support",
  "description": "Support for cancelled flights and rebooking.",
  "type": "application/mcp-server-card+json",
  "url": "https://support.airline.example/server-card.json",
  "osd:brandName": "Example Air",
  "osd:brandDomain": "airline.example"
}

O agente em si pode ficar em qualquer lugar, inclusive nos servidores da Zendesk ou de outra plataforma. O que importa é que o endosso é servido a partir do próprio domínio da marca. A marca pode manter o arquivo ela mesma ou autorizar sua plataforma de suporte a gerenciá-lo.

Passo 2: o assistente encontra um candidato

Se o assistente já conhece o domínio da marca (por exemplo, por um itinerário de voo), ele lê o manifesto diretamente. Se só conhece o nome da marca ou o problema, busca em um registro OSD pelo POST /search do ARD, que retorna entradas completas com uma pontuação de relevância. A documentação é cuidadosa ao dizer que essa pontuação "measures query match, not trust."

Passo 3: o assistente confere o endosso e se conecta

Este é o passo que responde à preocupação com spam. Um resultado do registro é apenas um candidato. Ele só conta como endossado se a entrada completa corresponder a uma publicada no manifesto da própria marca.

Assim, um golpista pode colocar uma listagem falsa em um registro, mas não em airline.example/.well-known/ard.json sem controlar o domínio da companhia aérea. É a mesma âncora de confiança que a web já usa para certificados TLS, e é uma escolha sensata. A documentação acrescenta mais uma ressalva honesta: osd:brandDomain é uma alegação, e continua sendo tarefa do assistente decidir se aquele domínio pertence ao negócio que o cliente quis dizer.

Uma vez confirmada a correspondência, o assistente lê o card do agente e se conecta pelo protocolo nativo dele, geralmente MCP ou A2A. Se você acompanha MCP para atendimento ao cliente ou o que torna bom um servidor MCP de agente de IA, é aqui que esses servidores se encaixam.

Onde o OSD termina e seu agente de suporte começa

Esta é a parte que eu sublinharia para qualquer líder de suporte lendo o post de lançamento. A Zendesk diz diretamente: "The directory does not access private customer data or carry out support actions." A documentação vai além: o OSD "defines discovery and endorsement only."

Tudo depois do aperto de mão pertence a outras camadas. A Zendesk cita três protocolos que planeja adotar para essa parte:

• Personal Agent Protocol (PAP), da Sierra, cobre como uma empresa decide o que um agente pode fazer, de "search rooms" sem login a "book a room" com aprovação do usuário. Falei dele no meu post sobre o Personal Agent Protocol.
• PACT (Personal Agent Consent and Trust), da Decagon, se apoia em A2A e OAuth para que a empresa possa verificar qual agente está chamando e o que o cliente autorizou. Combina com o gateway de agentes pessoais da Decagon.
• UCP (Universal Commerce Protocol), uma linguagem comum para comércio com agentes, da descoberta ao checkout, na mesma família do trabalho em torno do agentic commerce protocol.

Nem todos estão convencidos da ideia de protocolos aqui. No thread de lançamento do PAP, um comentarista discordou:

"As a human directing my personal agent, why does it need a protocol? It has that with the websites and APIs businesses expose."

dividedcomet, Hacker News

Minha leitura, como alguém que conectou muitas APIs de helpdesk: o caminho de site e API funciona até a ação envolver uma conta, dinheiro ou identidade, e aí os dois lados precisam de uma forma de provar quem age em nome de quem. É exatamente essa fatia que esses protocolos miram, e o OSD é apenas a consulta que vem antes.

Juntando tudo, a pilha fica assim, e só uma camada é sua para fazer bem:

O que realmente está no ar hoje?

Menos do que as manchetes sugerem, o que é normal em um lançamento de especificação. Isto é o que consegui verificar em 14 de outubro de 2026:

Nada disso é uma crítica. As marcas são descritas como entrando "to help shape the Directory", e o modelo de endosso é a parte difícil de acertar primeiro. Mas se você é líder de suporte e se pergunta se precisa fazer algo esta semana, a resposta honesta é não. Você tem alguns meses.

A documentação também menciona uma CLI do OSD para descoberta, verificação e comandos MCP diretos, mas diz que ela é "intended for internal developer workflows only", então eu não planejaria em torno dela ainda.

O que o Open Service Directory significa para você?

A resposta muda bastante dependendo de qual lado da conexão você está. Escolha o seu:

O que significa para uma equipe de suporte na Zendesk

Se você roda o suporte na Zendesk, o diretório em si é a parte fácil. A pergunta que ele impõe é outra: quando o assistente de um cliente se conecta ao seu suporte, o que ele realmente alcança?

O custo cai no seu agente, não no diretório

O diretório é gratuito. O agente no fim dele não. Se as solicitações dos assistentes forem tratadas pelo agente de IA da própria Zendesk, elas são cobradas como qualquer outra conversa. Segundo a página de preços da Zendesk, o Suite Team custa US$ 55 por agente por mês e o Suite Professional US$ 115 (pagos anualmente), cada um inclui um pequeno lote de resoluções automatizadas (5 por agente por mês no Suite Team, 10 no Suite Professional), e cada resolução automatizada extra custa US$ 1,50 com compromisso ou US$ 2,00 no pay-as-you-go. Meus detalhamentos de preços do Zendesk AI e resoluções automatizadas aprofundam o assunto.

Assim, uma marca que receba 1.000 solicitações mensais originadas por assistentes, todas resolvidas pelo agente de IA da Zendesk acima da franquia incluída, soma de US$ 1.500 a US$ 2.000 além das licenças. Isso não é motivo para ignorar o OSD. É motivo para saber seu custo por solicitação antes de se tornar mais fácil de alcançar, e para observar para onde o preço baseado em resultados leva essa conta.

Suas políticas viram o produto

A Zendesk é explícita: uma vez que o assistente se conecta, "the brand decides what customer information can be accessed, which actions are permitted and when a human needs to step in." Na prática, isso significa que três coisas precisam estar escritas em algum lugar que uma máquina consiga seguir:

1. Respostas. Seu agente responde com base em políticas reais e tickets anteriores, ou em uma central de ajuda rasa? Um assistente fará as perguntas dos seus clientes, formuladas com mais precisão.
2. Ações. Quais escritas rodam sozinhas, quais esperam uma pessoa e quais estão desligadas? Remarcar é uma coisa; reembolsos e cancelamentos são outra. Meu guia de fluxos de aprovação e a matriz de aprovação de reembolso explicam como traçar essas linhas.
3. Repasse. Quando o agente não tem confiança, a pessoa recebe o histórico completo? O próprio exemplo da Zendesk promete que a solicitação "can move to the support team with the conversation history and actions already taken." Veja contexto de repasse e escalonamentos de agentes de IA na Zendesk para configurações que realmente fazem isso.

O segundo ponto é o que mais ouço de líderes de suporte. Um líder de CX de uma marca DTC de suplementos que atende cerca de 7.000 tickets por mês disse à equipe da eesel:

"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

Um assistente que chega por um diretório verificado eleva essa barra, não a diminui. O cliente confia mais na conexão, então uma resposta ruim custa mais. Meu guia de limiares de confiança e as próprias configurações de confiança de intenção da Zendesk são por onde eu começaria.

Onde a eesel se encaixa

A eesel é um colega de IA que você contrata para um trabalho específico, e na Zendesk esse trabalho é o helpdesk. Ela entra na sua conta como agente, aprende com seus tickets anteriores da Zendesk, artigos da central de ajuda e macros, e você define por ação se ela roda sozinha, espera aprovação ou fica desligada.

Para ser claro sobre o que ela não é: a eesel não está listada no Open Service Directory, e a listagem de ninguém é pública ainda. O que ela faz é a camada para a qual o OSD repassa, o agente que atende a ligação e as regras do que ele pode fazer, e funciona igual se a solicitação vier de uma pessoa, de um balão de chat ou, mais adiante, do assistente de alguém.

Como o OSD é um lançamento voltado primeiro a desenvolvedores, vale saber que a eesel também tem uma superfície voltada a desenvolvedores. A CLI da eesel (npm install -g @eesel/cli) executa em um terminal o mesmo agente que você vê no painel, e todo comando imprime JSON, de modo que um script ou um agente de código como Claude Code, Codex ou Cursor pode operá-la. Para uma equipe Zendesk se preparando para o tráfego de assistentes, os comandos úteis são os que espelham os três pontos acima:

eesel integrations connect zendesk     # a Zendesk admin approves the connection
eesel integrations zendesk actions     # every Zendesk action and its approval setting
eesel instructions                     # read or edit the agent's standing rules
eesel approvals list                   # held actions waiting on a person
eesel activity                         # what the agent did, newest first

Escritas pela CLI seguem as mesmas regras de aprovação do painel, e --dry-run imprime a chamada exata ao servidor que uma escrita faria sem enviá-la, que é como eu revisaria uma mudança de política antes de ela entrar em vigor. Além disso, cada workspace é um servidor MCP ao qual você pode se conectar a partir do Claude Code com um único comando eesel mcp token. Esse servidor é para você operar seu agente, não para os assistentes dos seus clientes, então não o confunda com uma listagem do OSD. Meu post sobre a CLI de agente de IA explica por que esse acesso por terminal importa para equipes de suporte.

Teste a eesel na sua fila da Zendesk

Se o Open Service Directory fez você pensar em quem responde quando um assistente bate à porta, comece pelo agente em vez da listagem. A eesel se conecta à Zendesk em cerca de 30 minutos, aprende com os tickets que sua equipe já respondeu e permite testá-la contra conversas passadas antes de responder a qualquer pessoa. Você define quais ações precisam de uma pessoa, e cada execução aparece em um registro de atividade que você pode auditar.

O plano gratuito vem com 100 créditos e todos os recursos, e os planos pagos começam em US$ 299 por mês por 500 créditos, em que um ticket é um crédito, não importa quanto dure (preços da eesel). Se quiser a comparação primeiro, aqui está eesel vs Zendesk AI. Se não, teste a eesel nos seus próprios tickets da Zendesk.