Was Decagon tatsächlich vorgestellt hat
Decagon hat das Gateway auf dem Dialogues-2026-Event als eine von vier Neuheiten angekündigt, neben Decagon Voice 3, Agent Modules und Duet Apprentice.
Der Launch-Beitrag der Mitgründer Jesse Zhang und Ashwin Sreenivas beginnt mit dem Anlass: Innerhalb eines Monats hat Meta Muse gestartet, OpenAI hat dots vorgestellt, und Instinct hat begonnen, für seine Nutzer Telefonanrufe zu erledigen.
Das sind persönliche Agenten. Sie arbeiten für einen Verbraucher, nicht für ein Unternehmen, und sie "buchen, kaufen, kündigen und verhandeln" im Namen ihres Besitzers. Wenn sie in einer Support-Warteschlange landen, treffen sie meist auf den eigenen KI-Agenten für den Kundenservice der Marke. Jetzt sitzt also an beiden Enden der Unterhaltung ein Agent. Und das passiert schon auf echten Telefonleitungen:
"This week, Muse called customer service on my behalf. It navigated the phone tree, waited on hold, spoke with a human rep, and resolved the issue (worked great!)."
Das Gateway besteht aus zwei Funktionen und einem Protokoll:
| Baustein | Was er tut | Für wen |
|---|---|---|
| Erkennung persönlicher Agenten | Markiert wahrscheinliche persönliche Agenten in Live-Chat und Sprache | Agenten, die nicht sagen, dass sie Agenten sind |
| Kanal für persönliche Agenten | Ein eigener Kanal neben Chat, E-Mail und Sprache, mit eigenen Agent Operating Procedures (AOPs) | Agenten, die sich selbst zu erkennen geben |
| PACT (Personal Agent Consent & Trust) | Ein Protokoll, mit dem ein Agent belegt, wen er vertritt und was diese Person erlaubt hat | Anbieter persönlicher Agenten und Unternehmen |
Ich baue bei eesel beruflich Integrationen, und mein erster Eindruck war, dass dies vor allem ein Autorisierungsprodukt im Erkennungs-Kostüm ist. Das ist ein Kompliment. Die Erkennung macht die Schlagzeilen, aber die Scopes würde man tatsächlich ausliefern.
Warum persönliche Agenten Support-Regeln aushebeln
Dieser Satz aus Decagons Beitrag lässt mich nicht los. Ein Mensch, dem eine Erstattung verweigert wird, "might ask once more and let it go". Ein persönlicher Agent "might ask for a refund once, or keep trying different approaches to maximize the concession."
Das ist das ganze Problem in zwei Sätzen. Die meisten Erstattungs- und Ausnahmeregeln stützen sich stillschweigend auf die Geduld von Menschen. Der Kunde, der vier Versuche für eine Ausnahme bräuchte, hört meist nach zwei auf. Ein Agent wird nicht müde, ist nicht verlegen und hat keinen anderen Termin. Die am meisten geteilte Einschätzung dazu auf X benennt die Ökonomie offen:
"AI agents reduce the cost of complaints/requests to ~ zero. Anything free is consumed at much higher rates, so we should expect the total volume of this category to explode."
Dasselbe Muster sehe ich von der anderen Seite in den eesel-Warteschlangen, mit denen ich arbeite. Ein Support-Admin von eesel hat eine Sitzung lang dem Zendesk-Agenten von eesel eine einzige Regel beigebracht und es besser formuliert, als ich es könnte:
"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."
A digital-media support admin encoding a "troubleshoot before you cancel" policy into a Zendesk AI agent
Diese Regel funktioniert bei einem Menschen, weil ein Mensch die Fehlersuche akzeptiert. Ein persönlicher Agent mit dem Auftrag "besorg mir eine Erstattung" versucht, sie zu umgehen. Wenn sich Ihr KI-Support-Agent beim fünften Versuch aus einer Regel herausreden lässt, hatte er die Regel nie wirklich. Deshalb entscheidet sich bei KI für Erstattungsanfragen alles daran, was der Agent tun darf, nicht daran, wie freundlich er Nein sagt.
Decagon nennt noch ein zweites Problem: die Berechtigung. "Permission to check a balance doesn't necessarily mean permission to move money." Wenn heute der Agent eines Kunden mit den richtigen Kontodaten anruft, können die meisten Support-Stacks nicht erkennen, was der Kunde tatsächlich freigegeben hat.
So funktioniert das Personal Agent Gateway
Decagon baut das Design um vier Dinge, die ein Unternehmen richtig machen muss: Identifizierung, Zugang, Autorisierung und Lösung. So ordnet sich jedes davon dem Produkt zu.
Identifizierung: Erkennung plus Selbstauskunft
Die meisten Agenten rufen heute an oder öffnen einen Chat wie jeder andere. Laut Decagon kombiniert die Erkennung Signale des Unternehmens, etwa Geräte-Fingerabdrücke und Kontoverlauf, mit Signalen der Support-Plattform, etwa Gesprächsmustern und Anfragetakt. Die Markierung funktioniert in Live-Chat und Sprache. Was danach passiert, entscheidet das Unternehmen.
Bemerkenswert ist: Decagon bewirbt die Erkennung nicht als Hauptschranke. Sie funktioniere "best alongside an easy way for agents to identify themselves upfront", sodass sie nur die erwischen muss, die sich nicht melden. Die Erkennung ist der Notnagel, der Kanal der Plan. Meine Einschätzung: Es ist dieselbe Logik, die den Checkout in Richtung Agentic-Commerce-Protokoll geschoben hat. Eine Eingangstür für Agenten skaliert besser, als zu raten, wer ein Bot ist.
Zugang: ein Kanal nur für Agenten
Agenten, die sich zu erkennen geben, erhalten den Kanal für persönliche Agenten. Er steht neben Chat, E-Mail und Sprache und hat eigene AOPs. AOPs sind Decagons Workflows für seinen KI-Agenten, und ich habe sie im Decagon-Test ausführlicher behandelt.
Praktisch heißt das: Dieselbe Anfrage kann je nach Absender einer anderen Logik folgen. Eine Erstattungsanfrage von einem Menschen kann den einen Weg gehen, die eines Agenten einen anderen. Weniger sensible Anfragen können bestehende Workflows ohne zusätzliche Einrichtung wiederverwenden, und das ist wichtig, denn niemand will jede Regel doppelt pflegen. Decagons anderer Punkt geht leicht unter: Ein Kanal für alle Agentenanbieter bedeutet, dass Sie nicht eine eigene Integration für Muse, eine weitere für dots und noch eine für Instinct bauen.
Autorisierung: Scopes innerhalb der AOPs
Diesen Teil würde ich zweimal lesen. Decagon legt Berechtigungen in die AOPs: Ein Unternehmen definiert die Scopes, die ein Agent anfordern kann, und markiert, welche Abschnitte welchen Scope brauchen. Ohne den Scope werden "those sections are never exposed to the agent". Es ist das OAuth-Modell, das Sie vom Verbinden einer App mit Ihrem Google-Konto kennen, übertragen auf ein Support-Gespräch. Wenn Sie schon Zendesk-API-Scopes eingerichtet haben, kommt Ihnen die Form vertraut vor.
Decagons eigenes Beispiel ist eine Fluglinie:
Der Reisende erlaubt das Ansehen, aber nicht das Umbuchen. Der Agent der Fluglinie zeigt frühere Optionen, kann die Änderung aber nicht vornehmen, also geht der persönliche Agent zu seinem Besitzer zurück, um die fehlende Berechtigung zu holen. Decagon sagt außerdem, die Erteilung "creates a record of what the customer authorized", sodass das Unternehmen es später belegen kann. Für jede Support-Leitung, die schon einmal eine strittige Änderung aufdröseln musste, ist dieser Prüfpfad das eigentliche Feature.
Er beantwortet auch die Sorge, die Verbraucher von ihrer Seite haben. Auf Reddit fragte ein Muse-Nutzer, wie das funktionieren soll, wenn Versicherer und Telekommunikationsanbieter immer zuerst persönliche Daten verlangen:
"...for that to all I have to hand those info (social, address, DOB, etc.) directly into Muse memory as plain text without a secure credential layer, or the customer service might just hand off knowing it's an AI calling?"
Scopes, die der Kunde erteilt, sind genau die "secure credential layer", nach der dieser Nutzer fragt.
Lösung: verhindern, dass zwei Agenten sich im Kreis drehen
"Two agents can loop forever if neither is built to stop." Decagons Antwort: Der Agent des Unternehmens hält bei den Regeln seine Position und bleibt dabei hilfreich, und die Eskalation läuft in beide Richtungen. Der Unternehmensagent braucht vielleicht einen Menschen, der persönliche Agent vielleicht seinen Besitzer. Wenn Sie schon Regeln zur KI-Eskalation abgestimmt haben, ist das derselbe Muskel mit einem zweiten Ausgang. Es verändert auch die Messung: Eindämmungsquote und Eskalationsqualität umfassen jetzt auch das Zurückgeben einer Anfrage an den Agenten eines anderen.
Was PACT zu A2A hinzufügt
PACT steht für Personal Agent Consent & Trust. Laut Decagon "builds on the Agent2Agent protocol", das regelt, wie Agenten einander finden und Nachrichten austauschen, und ergänzt "delegated authorization built on OAuth 2.0". In einfachen Worten: A2A bringt die beiden Agenten ins Gespräch, und PACT lässt den persönlichen Agenten belegen, wessen Kunde er ist und was er darf. Das ist eine andere Aufgabe als bei MCP für den Kundensupport, das eine KI mit Werkzeugen verbindet statt mit einem anderen Agenten.
Diese Aufteilung leuchtet ein, wenn man die A2A-Spezifikation liest. Agenten machen sich mit einer Agent Card unter /.well-known/agent-card.json bekannt, aber die A2A-Spezifikation überlässt die Autorisierung der jeweiligen Implementierung. Für Anfragen von Verbrauchern an Unternehmen muss etwas diese Lücke füllen, und PACT ist Decagons Angebot dafür. A2A selbst hat echten Rückhalt: Am 27. August 2026 wurde es ein Growth-Stage-Projekt der Agentic AI Foundation, mit über 150 Organisationen dahinter.
Zwei Dinge sollten Sie auseinanderhalten, bevor Sie nach Dokumentation suchen:
- Der Name PACT ist doppelt vergeben. Cloudflare hat im Juni 2026 mit Mozilla, Google, Microsoft und Shopify ein anderes PACT angekündigt, Private Access Control Tokens. Dabei geht es um den Nachweis, dass ein Mensch im Web handelt, nicht um Einwilligung im Support.
- Die Spezifikation ist schwer zu finden. Decagons Dialogues-Rückblick sagt "the specification is available today", aber Stand 6. Oktober verlinkt keiner der beiden Launch-Beiträge darauf, und ich konnte keine öffentliche Kopie finden. Ich kann Ihnen also weder Feldnamen noch Endpunkte nennen, noch wie Erteilungsprotokolle gespeichert werden. Decagon sagt, es arbeite "working with personal agent providers" an der Ausgestaltung.
Decagon ist auf diesem Feld nicht allein. Am 30. September hat Mastercard einen Score angekündigt, der angibt, wie wahrscheinlich eine Zahlung von einem KI-Agenten ausgelöst wurde, im Test in den USA. Das ist Erkennung auf der Zahlungsebene. Decagon ist der Erste, den ich sehe, der dieselbe Idee auf das Support-Gespräch selbst richtet. Konkurrenten wie Sierra haben Stand heute nichts Vergleichbares angekündigt, was im Vergleich Decagon vs Sierra einen echten Unterschied macht.
Was noch nicht bekannt ist
Decagon ist beim Design klar und bei den Details, nach denen ein Käufer fragen würde, schweigsam. Der ehrliche Stand vom 6. Oktober 2026:
| Frage | Was Decagon veröffentlicht hat |
|---|---|
| Preis | Nichts. Decagons Seite /pricing liefert 404, und jeder Weg läuft über eine Demo |
| Verfügbarkeit | Kein GA-, Beta- oder Tarif-Label. Der Call-to-Action lautet "Talk to our team" |
| Kanäle für die Erkennung | Live-Chat und Sprache |
| Der Agentenkanal steht neben E-Mail, aber die Erkennung wird nur für Chat und Sprache beschrieben | |
| Spezifikation | Als verfügbar beschrieben, nicht öffentlich verlinkt |
| Angemeldete Agentenanbieter | Keine als PACT-Anwender genannt. Instinct, Muse und dots werden als Beispiele für Agenten genannt, die den Support schon kontaktieren |
| Genauigkeit der Erkennung | Keine Zahlen. Decagon sagt, die Erkennung "will keep improving as personal agents evolve" |
Nichts davon ist für eine Funktion eines Enterprise-Anbieters am Tag des Starts ungewöhnlich, und die Decagon-Preise waren schon immer vertriebsgesteuert. Es bedeutet aber, dass das Gateway eine Richtung ist, kein Produkt, das man heute bemessen kann, und es fließt direkt in die größere Frage ein, ob sich Decagon lohnt. Gerade der Kanal für sich selbst meldende Agenten zahlt sich erst aus, wenn die Agentenhersteller das Protokoll übernehmen, und keiner hat öffentlich gesagt, dass er das tun wird.
Was die Leute sagen
Die öffentliche Reaktion auf das Gateway selbst ist bisher dünn, was fünf Tage nach dem Start verständlich ist. Die größere Debatte, in die es hineinläuft, ist dagegen laut. Auf Hacker News wurde der Launch-Thread zu OpenAI dots zu einer Auseinandersetzung genau darüber:
"All this outsourcing of human interaction to agents is going to get locked down. Customer service relies on people not overabusing it, and that trust is getting abused by agents."
Und die Antwort, die erklärt, warum Verbraucher trotzdem Agenten schicken werden:
"The solution for both sides is for the companies to implement support bots that have more power to address my problem than the humans they replaced were ever given. I have a feeling it's not going to work out that way, though."
Blockieren ist der andere Reflex, und er hat seinen Preis. Ryan Sarver sagte, nachdem Amazon Muse von seiner Handelsseite ausgesperrt hatte: "Nobody asked the person whose agent stopped working" (Ryan Sarver, X).
Zusammengenommen sind diese Kommentare der ganze Entwurfsauftrag für das Gateway. Unternehmen müssen Missbrauch stoppen, Kunden wollen, dass ihr Agent tatsächlich etwas erledigt, und Scopes mit Berechtigungen sind die einzige Variante, bei der beide Seiten etwas bekommen. Wenn der Agent des Unternehmens sicher zu mehr Ja sagen kann, hat der Agent des Kunden weniger Grund zu bohren.
So bereiten Sie Ihr Support-Team vor, mit oder ohne Decagon
Die meisten Support-Teams, die das hier lesen, nutzen Decagon nicht und werden es im Budget 2026 auch nicht tun. Die gute Nachricht: Der schwierige Teil des Gateways ist eine Berechtigungsübung, die Sie auf jedem Stack machen können. Agenten wie Instinct und Meta Muse erreichen Ihre Warteschlange über dieselben E-Mail-, Chat- und Telefonleitungen, die auch Menschen nutzen, ob Sie etwas gekauft haben oder nicht. Wenn Sie Support über WhatsApp oder Messenger betreiben, zeigt Meta Muse für den Kundensupport, was Metas eigene Business-Tools leisten.
Wählen Sie unten eine Anfrageart und sehen Sie, wie ich sie absichern würde.
Hier die Kurzfassung als Checkliste:
- Inventarisieren Sie Ihre Aktionen. Listen Sie jede Aktion in Ihrem KI-Kundenservice-Workflow auf und ordnen Sie sie Lesen, umkehrbarem Schreiben, Geldbewegung oder Kontokontrolle zu. Die meisten Teams haben das nie aufgeschrieben.
- Sichern Sie nach Stufe ab, nicht nach Kanal. Eine Erstattung ist eine Erstattung, ob sie von einem Menschen, einem Bot oder einem Anruf kommt. Legen Sie Freigaben zuerst auf die Stufe der Geldbewegung. Die Leitfäden zu erweiterten KI-Aktionen in Zendesk und KI-Aktionen in Gorgias zeigen, was sich nativ konfigurieren lässt.
- Schreiben Sie Regeln, die Wiederholung überstehen. Lesen Sie jede Ausnahmeregel und fragen Sie: Würde das beim fünften Mal halten? Wenn die ehrliche Antwort "kommt darauf an, wer fragt" lautet, ziehen Sie sie enger.
- Geben Sie der Eskalation zwei Ausgänge. Ihre KI sollte sauber an einen Menschen übergeben und klar sagen, was sie vom Kunden braucht, wenn einem Agenten die Berechtigung fehlt. Für die menschliche Seite siehe Best Practices für die Übergabe an Menschen.
- Testen Sie vor dem Go-live mit vergangenen Tickets. Spielen Sie echte Erstattungs- und Kündigungstickets nach und prüfen Sie, wo Ihre KI nachgibt. Das ist billiger, als es von einem Agenten zu erfahren, der nicht lockerlässt.
Der vierte Punkt hat für mich eine Narbe. Ich habe einmal bei einem Digitalmedien-Kunden beobachtet, wie ein autonomes Entwurfs-Setup seinen eigenen Eskalationspfad zerbrach: Die Eskalations-E-Mail wurde automatisch geschlossen, sodass sie nie ein Mensch sah. Nichts wurde eskaliert, und niemand wusste es. Zwei Agenten, die miteinander sprechen, finden solche Lücken schneller als je ein Kunde, weshalb jeder eesel-Rollout inzwischen zuerst an historischen Tickets simuliert wird.
Wo eesel hineinpasst
Zuerst ehrlich zu den Grenzen. eesel erkennt keine persönlichen Agenten und implementiert weder Agent2Agent noch PACT. Wenn Sie heute einen Enterprise-Kanal zwischen Agenten mit vom Kunden erteilten Scopes brauchen, ist Decagon der Anbieter, der ihn baut, und der Vergleich der Decagon-Alternativen zeigt, wer sonst nah dran ist.
eesel liefert die Berechtigungsebene darunter, auf dem Helpdesk, den Sie bereits betreiben. Das KI-Helpdesk-Teammitglied stößt wie eine neue Kollegin zu Zendesk, Freshdesk oder Gorgias, neben oder anstelle von nativem Zendesk AI. Jede Aktion, die es ausführen kann, vom Hinzufügen eines Tags bis zur Erstattung, ist auf Auto, Freigabe nötig oder Deaktiviert gestellt und nach Lesen und Schreiben gruppiert, laut den Aktions-Docs von eesel.
Das ist dieselbe Trennung zwischen Lesen und Schreiben, die Decagons Scopes durchsetzen, nur auf Ihre eigene KI gerichtet statt auf die des Kunden. Wer also am anderen Ende eines Tickets sitzt, ein Mensch oder dessen Agent: Sie können eesel die Bestellung allein nachschlagen lassen und es trotzdem auf einen Menschen warten lassen, bevor Geld bewegt wird. Sie können das in einfachen Worten festlegen, etwa "Schlag Dinge selbst nach, aber frag mich vor jeder Erstattung", und zurückgehaltene Aktionen im Dashboard, in Slack oder über die eesel-CLI mit eesel approvals freigeben.
eesel ausprobieren
Wenn persönliche Agenten bald in Ihrer Warteschlange Erstattungen verlangen, ist die erste Aufgabe zu entscheiden, wozu Ihre eigene KI Ja sagen darf. Das KI-Helpdesk-Teammitglied von eesel verbindet sich mit Zendesk, Freshdesk oder Gorgias, lernt aus Ihren vergangenen Tickets und dem Help Center und hält Erstattungen und Kündigungen hinter einer Freigabe, bis Sie gesehen haben, dass es die Linie hält. Sie können es vorher in einer Simulation an Ihren vergangenen Tickets laufen lassen, bevor es einen Kunden berührt.
Der kostenlose Tarif enthält 100 Credits und alle Integrationen, und bezahlte Tarife beginnen bei $299 im Monat für 500 Credits auf der eesel-Preisseite. Testen Sie eesel an Ihrer eigenen Warteschlange.