Zendesk Open Service Directory: was es ist, wie es funktioniert und was schon live ist

Was ist das Zendesk Open Service Directory?

Das Open Service Directory ist Zendesks Antwort auf eine neue Art von Support-Anfrage: eine, die vom persönlichen KI-Assistenten eines Kunden kommt statt vom Kunden selbst. In Zendesks Launch-Beitrag, geschrieben von Jad Chamoun (Senior Director of Applied AI) und Will Poon (Director of Product Management für Messaging und AI), wird es beschrieben als „a specification and public directory of verified support destinations."

Ich baue beruflich Integrationen, also habe ich den Launch gelesen wie jede API-Ankündigung: Was ist der Vertrag, wer hostet was, und was ist ausgeliefert und was nur versprochen. Hier die Kurzfassung.

Falls Ihnen die Assistenten auf dieser Liste neu sind: Ich habe separat über OpenAI Dots, Instinct AI und Grok Bot geschrieben. OSD ist das erste Mal, dass ein Helpdesk-Anbieter versucht, allen einen gemeinsamen Zugang zu geben.

Warum braucht ein KI-Assistent ein Verzeichnis, um Support zu finden?

Weil er heute rät. Zendesks eigenes Beispiel ist ein Kunde, der einen Assistenten fragt: „Can you move my air conditioner repair appointment to Monday?" Der Assistent findet die Hilfeartikel des Unternehmens, aber den Termin zu verschieben heißt, den echten Support des Unternehmens zu erreichen, und es gibt keinen gemeinsamen, vertrauenswürdigen Weg zu prüfen, ob der gefundene „Support" der der Marke ist und keine Fälschung.

Das ist kein Problem der fernen Zukunft. Ich habe schon erlebt, dass Assistenten echte Käufer lenken: Ein Interessent erzählte dem eesel-Team in einem Sales-Call, er habe eesel gefunden, weil ein KI-Assistent es direkt empfohlen habe, zusammen mit einem Tipp eines Freundes beim Abendessen am Vorabend. Wenn Assistenten schon im Auftrag eines Käufers Anbieter auswählen, wählen sie bald auch Support-Desks im Auftrag eines Kunden aus, und eine falsche Wahl heißt dort, dass ein Kunde Bestelldaten an einen gefälschten Helpdesk gibt.

Die Skeptiker haben einen berechtigten Punkt dazu, wohin das führt, sobald es etwas zu gewinnen gibt. Als Googles ARD-Spezifikation, die Basisschicht von OSD, auf Hacker News landete, brachte der oberste Kommentar es auf den Punkt:

"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

OSDs Antwort darauf ist die Bestätigungsregel im nächsten Abschnitt, und ich halte sie für die wichtigste Designentscheidung der gesamten Spezifikation.

So funktioniert das Open Service Directory

Zendesk beschreibt es in drei Schritten: genehmigten Support auflisten, das richtige Unternehmen finden, sich mit dem offiziellen Support verbinden. Die OSD-Entwicklerdokumentation füllt die Mechanik aus, und sie ist erfrischend klein.

Schritt 1: Die Marke veröffentlicht einen Eintrag auf ihrer eigenen Domain

Eine Marke beschreibt jeden Support-Agenten, den Assistenten finden sollen, in einem JSON-Manifest unter https://{brand-domain}/.well-known/ard.json. Jeder Eintrag ist ein normaler ARD-Eintrag (eine Kennung, ein Anzeigename, eine Beschreibung, Beispielanfragen und ein Link zur MCP Server Card oder A2A Agent Card des Agenten) plus zwei OSD-Felder: osd:brandName und osd:brandDomain. Hier das gekürzte Beispiel von der Seite OSD und ARD mit ihrer fiktiven Fluglinie:

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

Der Agent selbst kann überall laufen, auch auf den Servern von Zendesk oder einer anderen Plattform. Entscheidend ist, dass die Bestätigung von der eigenen Domain der Marke ausgeliefert wird. Die Marke kann die Datei selbst pflegen oder ihre Support-Plattform zur Verwaltung autorisieren.

Schritt 2: Der Assistent findet einen Kandidaten

Kennt der Assistent die Domain der Marke bereits (etwa aus einer Flugreiseroute), liest er das Manifest direkt. Kennt er nur den Markennamen oder das Problem, durchsucht er eine OSD-Registry über ARDs POST /search, die vollständige Einträge mit einem Relevanzwert zurückgibt. Die Doku betont, dass dieser Wert „measures query match, not trust."

Schritt 3: Der Assistent prüft die Bestätigung und verbindet sich

Dieser Schritt beantwortet die Sorge vor Spam. Ein Registry-Treffer ist nur ein Kandidat. Er gilt nur dann als bestätigt, wenn sein vollständiger Eintrag mit einem Eintrag im eigenen Manifest der Marke übereinstimmt.

Ein Betrüger kann also einen gefälschten Eintrag in eine Registry bekommen, aber nicht in airline.example/.well-known/ard.json, ohne die Domain der Fluglinie zu kontrollieren. Das ist derselbe Vertrauensanker, den das Web schon für TLS-Zertifikate nutzt, und eine vernünftige Wahl. Die Doku nennt noch einen ehrlichen Vorbehalt: osd:brandDomain ist eine Behauptung, und der Assistent muss weiterhin selbst entscheiden, ob diese Domain zu dem Unternehmen gehört, das der Kunde gemeint hat.

Sobald eine Übereinstimmung bestätigt ist, liest der Assistent die Karte des Agenten und verbindet sich über dessen natives Protokoll, meist MCP oder A2A. Wenn Sie MCP für den Kundensupport verfolgt haben oder wissen, was einen guten KI-Agent-MCP-Server ausmacht: Hier docken diese Server an.

Wo OSD aufhört und Ihr Support-Agent anfängt

Das ist der Teil, den ich jedem Support-Leiter nach der Lektüre des Launch-Beitrags unterstreichen würde. Zendesk sagt es direkt: „The directory does not access private customer data or carry out support actions." Die Doku geht weiter: OSD „defines discovery and endorsement only."

Alles nach dem Handshake gehört anderen Schichten. Zendesk nennt drei Protokolle, die es dafür übernehmen will:

• Personal Agent Protocol (PAP) von Sierra regelt, wie ein Unternehmen entscheidet, was ein Agent darf, von „search rooms" ohne Anmeldung bis „book a room" mit Zustimmung des Nutzers. Ich habe es in meinem Beitrag zum Personal Agent Protocol behandelt.
• PACT (Personal Agent Consent and Trust) von Decagon baut auf A2A und OAuth auf, damit ein Unternehmen prüfen kann, welcher Agent anruft und was der Kunde autorisiert hat. Es passt zum Personal-Agent-Gateway von Decagon.
• UCP (Universal Commerce Protocol), eine gemeinsame Sprache für agentischen Handel von der Suche bis zum Checkout, aus derselben Familie wie die Arbeit am Agentic Commerce Protocol.

Nicht alle halten Protokolle hier überhaupt für sinnvoll. Im PAP-Launch-Thread widersprach ein Kommentator:

"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

Meine Einschätzung als jemand, der viele Helpdesk-APIs angebunden hat: Der Weg über Website und API funktioniert, bis die Aktion ein Konto, Geld oder Identität betrifft, und dann brauchen beide Seiten eine Möglichkeit zu belegen, wer für wen handelt. Genau diesen Ausschnitt zielen die Protokolle an, und OSD ist nur der Nachschlag davor.

Zusammen sieht der Stack so aus, und nur eine Schicht müssen Sie selbst gut machen:

Was ist heute tatsächlich live?

Weniger, als die Schlagzeilen vermuten lassen, was bei einem Spezifikations-Launch normal ist. Das konnte ich am 14. Oktober 2026 verifizieren:

Nichts davon ist ein Vorwurf. Die Marken sollen „to help shape the Directory" beitreten, und das Bestätigungsmodell ist der schwierige Teil, den man zuerst richtig machen muss. Wer als Support-Leiter aber wissen will, ob diese Woche etwas zu tun ist: Nein. Sie haben noch einige Monate.

Die Doku erwähnt außerdem eine OSD-CLI für Discovery, Verifizierung und direkte MCP-Befehle, aber sie sei „intended for internal developer workflows only", also würde ich damit noch nicht planen.

Was bedeutet das Open Service Directory für Sie?

Die Antwort hängt stark davon ab, auf welcher Seite der Verbindung Sie sitzen. Wählen Sie Ihre:

Was es für ein Zendesk-Support-Team bedeutet

Wenn Sie Ihren Support auf Zendesk betreiben, ist das Verzeichnis selbst der leichte Teil. Die Frage, die es aufwirft, ist eine andere: Wenn sich der Assistent eines Kunden mit Ihrem Support verbindet, was erreicht er tatsächlich?

Die Kosten fallen beim Agenten an, nicht beim Verzeichnis

Das Verzeichnis ist kostenlos. Der Agent an seinem Ende nicht. Werden Assistenten-Anfragen von Zendesks eigenem KI-Agenten bearbeitet, werden sie wie jede andere Unterhaltung abgerechnet. Laut Zendesks Preisseite kostet Suite Team 55 $ pro Agent und Monat und Suite Professional 115 $ (jährliche Zahlung), jeweils mit einem kleinen Kontingent automatisierter Lösungen (5 pro Agent und Monat bei Suite Team, 10 bei Suite Professional), und jede weitere automatisierte Lösung kostet 1,50 $ (Commitment) oder 2,00 $ (Pay-as-you-go). Meine Aufschlüsselungen zu Zendesk-AI-Preisen und automatisierten Lösungen gehen tiefer.

Eine Marke mit 1.000 Assistenten-Anfragen im Monat, alle vom Zendesk-KI-Agenten über dem enthaltenen Kontingent gelöst, zahlt also 1.500 bis 2.000 $ zusätzlich zu den Lizenzen. Das ist kein Grund, OSD zu überspringen. Es ist ein Grund, die Kosten pro Anfrage zu kennen, bevor Sie sich leichter erreichbar machen, und zu beobachten, wohin die ergebnisbasierte Preisgestaltung diese Rechnung als Nächstes führt.

Ihre Richtlinien werden zum Produkt

Zendesk betont, dass sobald sich ein Assistent verbindet, „the brand decides what customer information can be accessed, which actions are permitted and when a human needs to step in." In der Praxis heißt das: Drei Dinge müssen irgendwo festgehalten sein, wo eine Maschine ihnen folgen kann:

1. Antworten. Antwortet Ihr Agent aus Ihren echten Richtlinien und früheren Tickets oder aus einem dünnen Help Center? Ein Assistent stellt die Fragen Ihrer Kunden, nur präziser formuliert.
2. Aktionen. Welche Schreibaktionen laufen selbstständig, welche warten auf einen Menschen, und welche sind aus? Einen Termin zu verschieben ist eine Sache; Erstattungen und Kündigungen sind eine andere. Mein Leitfaden zu Freigabe-Workflows und die Erstattungs-Freigabematrix zeigen, wie man diese Grenzen zieht.
3. Übergabe. Wenn der Agent nicht sicher ist, bekommt der Mensch den vollständigen Verlauf? Zendesks eigenes Beispiel verspricht, die Anfrage „can move to the support team with the conversation history and actions already taken." Siehe Übergabekontext und Eskalationen von KI-Agenten in Zendesk für Setups, die das wirklich tun.

Der zweite Punkt ist der, den ich am häufigsten von Support-Leitern höre. Ein CX-Leiter einer DTC-Supplement-Marke mit rund 7.000 Tickets im Monat formulierte es gegenüber dem eesel-Team so:

"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."

Ein Assistent, der über ein verifiziertes Verzeichnis kommt, legt die Latte höher, nicht niedriger. Der Kunde vertraut der Verbindung mehr, also kostet eine schlechte Antwort mehr. Mein Leitfaden zu Konfidenzschwellen und Zendesks eigene Einstellungen für Intent-Konfidenz wären mein Startpunkt.

Wo eesel passt

eesel ist ein KI-Teammitglied, das Sie für eine bestimmte Aufgabe einstellen, und bei Zendesk ist diese Aufgabe der Helpdesk. Es tritt Ihrem Konto als Agent bei, lernt aus Ihren früheren Zendesk-Tickets, Help-Center-Artikeln und Makros, und Sie legen pro Aktion fest, ob sie selbstständig läuft, auf Freigabe wartet oder aus ist.

Um klar zu sein, was es nicht ist: eesel ist nicht im Open Service Directory gelistet, und noch ist niemandes Eintrag öffentlich. Es ist die Schicht, an die OSD übergibt, der Agent, der den Anruf annimmt, samt den Regeln, was er darf, und es funktioniert gleich, ob die Anfrage von einer Person, einer Chat-Blase oder später dem Assistenten von jemandem kommt.

Da OSD ein Developer-First-Launch ist, lohnt sich der Hinweis, dass eesel ebenfalls eine Developer-First-Oberfläche hat. Die eesel CLI (npm install -g @eesel/cli) führt denselben Agenten wie im Dashboard von einem Terminal aus, und jeder Befehl gibt JSON aus, sodass ein Skript oder ein Coding-Agent wie Claude Code, Codex oder Cursor ihn steuern kann. Für ein Zendesk-Team, das sich auf Assistenten-Traffic vorbereitet, sind die nützlichen Befehle die, die den drei Punkten oben entsprechen:

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

Schreibzugriffe aus der CLI folgen denselben Freigaberegeln wie das Dashboard, und --dry-run gibt den exakten Server-Aufruf aus, den ein Schreibvorgang machen würde, ohne ihn zu senden. So würde ich eine Richtlinienänderung prüfen, bevor sie live geht. Jeder Workspace ist außerdem ein MCP-Server, mit dem Sie sich von Claude Code aus mit einem eesel mcp token-Befehl verbinden können. Dieser Server ist dafür da, dass Sie Ihren Agenten bedienen, nicht für die Assistenten Ihrer Kunden, verwechseln Sie ihn also nicht mit einem OSD-Eintrag. Mein Beitrag zur KI-Agent-CLI erklärt, warum dieser Terminalzugang für Support-Teams wichtig ist.

eesel in Ihrer Zendesk-Queue testen

Wenn Sie das Open Service Directory darüber nachdenken lässt, wer antwortet, wenn ein Assistent anklopft, beginnen Sie mit dem Agenten statt mit dem Eintrag. eesel verbindet sich in etwa 30 Minuten mit Zendesk, lernt aus den Tickets, die Ihr Team bereits beantwortet hat, und lässt sich an früheren Unterhaltungen testen, bevor es irgendjemandem antwortet. Sie legen fest, welche Aktionen einen Menschen brauchen, und jeder Lauf erscheint in einem Aktivitätsprotokoll, das Sie prüfen können.

Der kostenlose Plan enthält 100 Credits und alle Funktionen, und bezahlte Pläne beginnen bei 299 $ im Monat für 500 Credits, wobei ein Ticket ein Credit ist, egal wie lange es läuft (eesel-Preise). Wenn Sie zuerst den Vergleich möchten: Hier ist eesel vs. Zendesk AI. Andernfalls: eesel testen an Ihren eigenen Zendesk-Tickets.