Zendesk Open Service Directory: qué es, cómo funciona y qué está activo

¿Qué es el Zendesk Open Service Directory?

El Open Service Directory es la respuesta de Zendesk a un nuevo tipo de solicitud de soporte: la que llega desde el asistente de IA personal de un cliente en lugar de desde el propio cliente. En la publicación de lanzamiento de Zendesk, escrita por Jad Chamoun (Senior Director of Applied AI) y Will Poon (Director of Product Management para Messaging y AI), se describe como "a specification and public directory of verified support destinations."

Me dedico a construir integraciones, así que leí el lanzamiento como leo cualquier anuncio de API: cuál es el contrato, quién aloja qué y qué se entrega frente a qué se promete. Esta es la versión corta.

Si los asistentes de esa lista te suenan nuevos, he escrito por separado sobre OpenAI Dots, Instinct AI y Grok Bot. OSD es la primera vez que un proveedor de helpdesk intenta darles a todos una entrada común.

¿Por qué un asistente de IA necesitaría un directorio para encontrar soporte?

Porque hoy adivina. El ejemplo de Zendesk es un cliente que le pregunta a un asistente: "Can you move my air conditioner repair appointment to Monday?" El asistente encuentra los artículos de ayuda de la empresa, pero mover la cita implica llegar al soporte real de la empresa, y no hay una forma común y de confianza de comprobar que el "soporte" que encontró es de la marca y no una imitación.

Este no es un problema de un futuro lejano. Ya he visto asistentes dirigir a compradores reales: un prospecto le contó al equipo de eesel en una llamada de ventas que encontró eesel porque un asistente de IA lo recomendó directamente, junto con el consejo de un amigo en una cena la noche anterior. Si los asistentes ya eligen proveedores en nombre de un comprador, también elegirán mesas de soporte en nombre de un cliente, y una mala elección ahí significa que un cliente entrega los datos de su pedido a un falso servicio de ayuda.

Los escépticos tienen un punto razonable sobre adónde lleva esto cuando hay algo que ganar. Cuando la especificación ARD de Google, la capa base sobre la que se apoya OSD, llegó a Hacker News, el comentario más votado lo dijo claro:

"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

La respuesta de OSD a eso es la regla de respaldo de la siguiente sección, y creo que es la decisión de diseño más importante de toda la especificación.

Cómo funciona el Open Service Directory

Zendesk lo describe en tres pasos: listar el soporte aprobado, encontrar el negocio correcto, conectar con el soporte oficial. La documentación para desarrolladores de OSD detalla la mecánica, y es refrescantemente pequeña.

Paso 1: la marca publica una ficha en su propio dominio

Una marca describe cada agente de soporte que quiere que los asistentes encuentren en un manifiesto JSON en https://{brand-domain}/.well-known/ard.json. Cada entrada es una entrada ARD normal (un identificador, un nombre visible, una descripción, consultas de ejemplo y un enlace a la MCP Server Card o A2A Agent Card del agente) más dos campos de OSD: osd:brandName y osd:brandDomain. Aquí está el ejemplo recortado de la página de OSD y ARD, con su aerolínea ficticia:

{
  "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"
}

El agente puede estar en cualquier sitio, incluso en los servidores de Zendesk o de otra plataforma. Lo que importa es que el respaldo se sirve desde el dominio propio de la marca. La marca puede mantener el archivo ella misma o autorizar a su plataforma de soporte para gestionarlo.

Paso 2: el asistente encuentra un candidato

Si el asistente ya conoce el dominio de la marca (por ejemplo, por el itinerario de un vuelo), lee el manifiesto directamente. Si solo conoce el nombre de la marca o el problema, busca en un registro OSD mediante el POST /search de ARD, que devuelve entradas completas con una puntuación de relevancia. La documentación aclara que esa puntuación "measures query match, not trust."

Paso 3: el asistente comprueba el respaldo y se conecta

Este es el paso que responde a la preocupación por el spam. Un resultado del registro es solo un candidato. Solo cuenta como respaldado si su entrada completa coincide con una publicada en el manifiesto propio de la marca.

Así, un estafador puede colar una ficha falsa en un registro, pero no en airline.example/.well-known/ard.json sin controlar el dominio de la aerolínea. Es el mismo ancla de confianza que la web ya usa para los certificados TLS, y es una elección sensata. La documentación añade otra advertencia honesta: osd:brandDomain es una afirmación, y sigue siendo trabajo del asistente decidir si ese dominio pertenece al negocio que el cliente quería decir.

Una vez confirmada la coincidencia, el asistente lee la tarjeta del agente y se conecta por su protocolo nativo, normalmente MCP o A2A. Si has seguido MCP para atención al cliente o qué hace bueno a un servidor MCP de agente de IA, aquí es donde esos servidores se conectan.

Dónde termina OSD y empieza tu agente de soporte

Esta es la parte que subrayaría para cualquier responsable de soporte que lea la publicación de lanzamiento. Zendesk lo dice directamente: "The directory does not access private customer data or carry out support actions." La documentación va más allá: OSD "defines discovery and endorsement only."

Todo lo que viene después del apretón de manos pertenece a otras capas. Zendesk nombra tres protocolos que planea adoptar para esa parte:

• Personal Agent Protocol (PAP), de Sierra, cubre cómo una empresa decide qué puede hacer un agente, desde "search rooms" sin inicio de sesión hasta "book a room" con aprobación del usuario. Lo traté en mi publicación sobre el Personal Agent Protocol.
• PACT (Personal Agent Consent and Trust), de Decagon, se basa en A2A y OAuth para que una empresa pueda verificar qué agente llama y qué autorizó el cliente. Va de la mano con el gateway de agentes personales de Decagon.
• UCP (Universal Commerce Protocol), un lenguaje común para el comercio con agentes, del descubrimiento al pago, de la misma familia que el trabajo del agentic commerce protocol.

No todos están convencidos de la idea de los protocolos aquí. En el hilo de lanzamiento de PAP, un comentarista objetó:

"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

Mi lectura, como alguien que ha conectado muchas APIs de helpdesk: la vía de sitio web y API funciona hasta que la acción involucra una cuenta, dinero o identidad, y entonces ambas partes necesitan una forma de demostrar quién actúa en nombre de quién. Ese es justo el tramo al que apuntan estos protocolos, y OSD es solo la consulta que viene antes.

En conjunto, la pila se ve así, y solo una capa te toca hacer buena:

¿Qué está realmente activo hoy?

Menos de lo que sugieren los titulares, lo cual es normal en el lanzamiento de una especificación. Esto es lo que pude verificar el 14 de octubre de 2026:

Nada de eso es una crítica. Se dice que las marcas se unen "to help shape the Directory", y el modelo de respaldo es lo difícil de acertar primero. Pero si eres responsable de soporte y te preguntas si tienes que hacer algo esta semana, la respuesta honesta es no. Tienes unos meses.

La documentación también menciona una CLI de OSD para descubrimiento, verificación y comandos MCP directos, pero dice que está "intended for internal developer workflows only", así que no planificaría en torno a ella todavía.

¿Qué significa el Open Service Directory para ti?

La respuesta cambia mucho según de qué lado de la conexión estés. Elige el tuyo:

Qué significa para un equipo de soporte en Zendesk

Si gestionas el soporte en Zendesk, el directorio en sí es la parte fácil. La pregunta que plantea es otra: cuando el asistente de un cliente se conecta a tu soporte, ¿a qué llega realmente?

El costo recae en tu agente, no en el directorio

El directorio es gratuito. El agente al final de él no. Si las solicitudes de los asistentes las gestiona el propio agente de IA de Zendesk, se facturan como cualquier otra conversación. Según la página de precios de Zendesk, Suite Team cuesta 55 $ por agente al mes y Suite Professional 115 $ (pago anual), cada uno incluye un pequeño lote de resoluciones automatizadas (5 por agente al mes en Suite Team, 10 en Suite Professional), y cada resolución automatizada adicional cuesta 1,50 $ con compromiso o 2,00 $ de pago por uso. Mis desgloses de precios de Zendesk AI y resoluciones automatizadas profundizan más.

Así, una marca que recibe 1.000 solicitudes mensuales originadas por asistentes, todas resueltas por el agente de IA de Zendesk por encima de la cuota incluida, suma entre 1.500 y 2.000 $ además de las licencias. No es una razón para saltarse OSD. Es una razón para conocer tu costo por solicitud antes de hacerte más accesible, y para vigilar hacia dónde lleva esa factura el precio basado en resultados.

Tus políticas se convierten en el producto

Zendesk es explícito en que, una vez que un asistente se conecta, "the brand decides what customer information can be accessed, which actions are permitted and when a human needs to step in." En la práctica, eso significa que tres cosas tienen que estar escritas en algún lugar que una máquina pueda seguir:

1. Respuestas. ¿Tu agente responde a partir de tus políticas reales y tickets pasados, o de un centro de ayuda escaso? Un asistente hará las preguntas que hacen tus clientes, formuladas con más precisión.
2. Acciones. ¿Qué escrituras se ejecutan solas, cuáles esperan a una persona y cuáles están desactivadas? Reprogramar es una cosa; los reembolsos y las cancelaciones son otra. Mi guía de flujos de aprobación y la matriz de aprobación de reembolsos explican cómo trazar esas líneas.
3. Traspaso. Cuando el agente no está seguro, ¿la persona recibe el historial completo? El propio ejemplo de Zendesk promete que la solicitud "can move to the support team with the conversation history and actions already taken." Mira contexto de traspaso y escalaciones de agentes de IA en Zendesk para configuraciones que de verdad lo hacen.

El segundo punto es el que más oigo de responsables de soporte. Un responsable de CX de una marca DTC de suplementos que gestiona unos 7.000 tickets al mes se lo planteó así al equipo de 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."

Un asistente que llega por un directorio verificado sube ese listón, no lo baja. El cliente confía más en la conexión, así que una mala respuesta cuesta más. Mi guía de umbrales de confianza y los propios ajustes de confianza de intención de Zendesk son por donde empezaría.

Dónde encaja eesel

eesel es un compañero de IA que contratas para un trabajo concreto, y en Zendesk ese trabajo es el helpdesk. Se une a tu cuenta como agente, aprende de tus tickets pasados de Zendesk, artículos del centro de ayuda y macros, y tú decides por acción si se ejecuta sola, espera aprobación o está desactivada.

Para ser claros sobre lo que no es: eesel no figura en el Open Service Directory, y la ficha de nadie es pública todavía. Lo que hace es la capa a la que OSD traspasa, el agente que contesta la llamada y las reglas de lo que puede hacer, y funciona igual si la solicitud viene de una persona, de una burbuja de chat o, más adelante, del asistente de alguien.

Como OSD es un lanzamiento pensado primero para desarrolladores, vale la pena saber que eesel también tiene una superficie para desarrolladores. La CLI de eesel (npm install -g @eesel/cli) ejecuta desde una terminal el mismo agente que ves en el panel, y cada comando imprime JSON, de modo que un script o un agente de código como Claude Code, Codex o Cursor puede manejarla. Para un equipo de Zendesk que se prepara para el tráfico de asistentes, los comandos útiles son los que reflejan los tres puntos anteriores:

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

Las escrituras desde la CLI siguen las mismas reglas de aprobación que el panel, y --dry-run imprime la llamada exacta al servidor que haría una escritura sin enviarla, que es como revisaría un cambio de política antes de publicarlo. Además, cada espacio de trabajo es un servidor MCP al que puedes conectarte desde Claude Code con un solo comando eesel mcp token. Ese servidor es para que tú operes tu agente, no para los asistentes de tus clientes, así que no lo confundas con una ficha de OSD. Mi publicación sobre la CLI de agente de IA explica por qué ese acceso por terminal importa a los equipos de soporte.

Prueba eesel en tu cola de Zendesk

Si el Open Service Directory te hace pensar en quién responde cuando un asistente llama a la puerta, empieza por el agente en lugar de la ficha. eesel se conecta a Zendesk en unos 30 minutos, aprende de los tickets que tu equipo ya ha respondido y te permite probarlo contra conversaciones pasadas antes de que responda a nadie. Tú defines qué acciones necesitan a una persona, y cada ejecución aparece en un registro de actividad que puedes auditar.

El plan gratuito incluye 100 créditos y todas las funciones, y los planes de pago empiezan en 299 $ al mes por 500 créditos, donde un ticket es un crédito sin importar cuánto dure (precios de eesel). Si quieres la comparación primero, aquí está eesel vs Zendesk AI. Si no, prueba eesel con tus propios tickets de Zendesk.