Flow Builder, Action Flows, Advanced oder Custom Agent: was wofür
Wer heute in Zendesk automatisieren will, steht vor vier Werkzeugen, die sich überlappen und gegenseitig aufrufen: der klassische Flow Builder, die Action Flows, AI Agents Advanced und die neuen Custom Agents. Die Doku erklärt jedes einzelne, aber nicht, welches wann trägt. Diese Karte kommt aus dem Betrieb von sieben produktiven Agents, nicht aus dem Prospekt.
Die vier Werkzeuge in je einem Absatz
Flow Builder ist der dialogbasierte Klassiker. Der Einstieg ist stichwortbasiert: Freitext wird über Ähnlichkeit einem Intent zugeordnet. Danach laufen vordefinierte Pfade, Schritt für Schritt, vollständig deterministisch. Er kann mitten im Gespräch API-Calls machen und Antworten anzeigen, aber Daten nicht umformen. Wer mehr als Durchreichen braucht, stösst an die Grenze, die der Bauplan Flow Builder an der Produktgrenze beschreibt. Abschreiben sollte man ihn deswegen nicht; dazu gleich mehr.
Action Flows sind die Workflow-Ebene dahinter: deterministische Abläufe mit allem, was man dafür braucht. Schleifen und While-Loops, Bedingungen (verschachteln lassen sie sich noch nicht), Custom Code (läuft nur synchron), API-Calls und Standard-Konnektoren in Systeme wie Outlook. Die Konnektoren haben Ecken. Pro Flow lässt sich zum Beispiel kein unterschiedliches Outlook-Konto verbinden; beim Testen entscheidet sich, ob eine separate API-Verbindung über Custom Actions nötig ist. Und die Zuständigkeit endet nicht mehr am Deterministischen: Ein Custom Agent lässt sich als Schritt einbinden und übernimmt die Stelle im Ablauf, an der interpretiert werden muss.
AI Agents Advanced (das frühere Ultimate) ist im Gespräch das mächtigste der vier Werkzeuge: Es führt deterministische Dialoge und generative, durchsucht Wissen KI-basiert (RAG), kann Custom Agents einbinden und bringt mit dem Action Builder samt JSONata die Datentransformation gleich mit, für die der Flow Builder einen Umweg brauchte. Dazu die mit Abstand beste Auditierbarkeit der ganzen Palette: Jede Variable der Session und jeder API-Call sind einsehbar, jede Entscheidung eines LLM wird begründet. Sein Revier sind Konversationen. Backend- und Backoffice-Prozesse ohne Gespräch dahinter gehören den Action Flows und Custom Agents.
Custom Agents schliesslich sind keine Chatbots, sondern spezialisierte Arbeiter auf der Resolution Platform: Sie bekommen Instruktionen in natürlicher Sprache, Aktionen und Wissensquellen, erwarten definierten Input und liefern definierten Output, aber den Weg dazwischen entscheiden sie selbst. Alleine loslaufen können sie nicht. Aufgerufen werden sie aus Action Flows oder Prozeduren, und über Action Flows lassen sich mehrere davon aneinanderhängen. Das macht sie zum fehlenden Glied auf dem Weg zur Autonomous Workforce. Jung sind sie trotzdem: Das Logging reicht nicht an Advanced heran, Ticket-ID ist Pflicht-Input, Änderungen an Ein-/Ausgaben ziehen Anpassungen im aufrufenden Flow nach sich.
Noch ein Wort zum Flow Builder
Unterschätzen sollte man ihn nicht. Für eng gefasste, klar wiederkehrende Anliegen ist er nach wie vor stark, man muss ihn nur gezielt einsetzen statt für alles. Wer ein paar solcher Use-Cases sauber trifft, holt damit durchaus 50 % Automated Resolutions. Der Schlüssel dazu ist zu verstehen, wie er Freitext trifft.
Nämlich nicht stichwortgenau, sondern semantisch. Die Beispielsätze eines Intents werden in Vektoren übersetzt (Embeddings), die eingehende Nachricht ebenso, und verglichen wird die Nähe im Bedeutungsraum, üblicherweise über die Kosinus-Ähnlichkeit, vereinfacht der Winkel zwischen zwei Vektoren: je kleiner, desto näher die Bedeutung. Gemessen wird also Sinn-Nähe, nicht Wortgleichheit. Das ist die Stärke, «Konto gesperrt» trifft auch, wenn niemand exakt so schreibt, und dieselbe Mechanik ist die Falle.
Ein verräterisches Detail steht in Zendesks eigenen Empfehlungen: Man solle Füllwörter wie «ich» oder «du» aus den Trainingsphrasen weglassen. Das ergibt nur Sinn, wenn im Hintergrund Vektoren gemittelt und verglichen werden: Solche Allerweltswörter stehen in fast jeder Phrase über alle Intents, ziehen jeden Satzvektor zur gemeinsamen Mitte und drücken die Unterschiede zwischen den Intents zusammen. Wegwerfen schärft. Für ein Modell, das den Satz «versteht», müsste man das gar nicht erst empfehlen.
Wie weit die Zuordnung reicht, findet man am schnellsten mit bewusst absurden Eingaben heraus: Blackbox-Stresstest statt realistischem Input. Zwei aus meinem Betrieb. Ein Use-Case, den ich mit «Biologie» angelernt hatte, sprang bei «Desoxyribonukleinsäure» an; im Bedeutungsraum liegt DNA direkt neben Biologie, das ist fast noch logisch. Härter: Ich tippte nur «Bär», und «Spielsperre» triggerte, kein «nicht verstanden», ein echter Treffer. Kein Mensch meldet sich so beim Support, schon klar; aber das ist der Sinn des Stresstests. Ob «Bär» im Embedding neben «Sperre» liegt (denkbar über «Wandersperre wegen Bär» aus Zeitungstexten) oder ob schlicht die Schwelle zu tief sass und ein kontextloses Wort beim nächstbesten Intent landete, lasse ich offen; von aussen lässt sich das nicht beweisen. Interessant ist nicht die Ursache, sondern dass das System überhaupt so weit danebengreift.
Daraus wird Handwerk: Beispielsätze pro Intent breit und trennscharf halten, Füllwörter raus, nach dem Start die Fehltrigger auswerten statt nur die Treffer. Dieses Vorgehen hat bei mir die Quote richtig erkannter Intents von 25 % auf 75 % gehoben, das Dreifache. Ich musste nie beweisen, welche Metrik im Kern rechnet; es genügte, das Verhalten am absurden Fall abzulesen und danach zu bauen. Das Betriebsergebnis zählt, nicht das Architektur-Diagramm.
Ein Vorbehalt bleibt, der die Frage für viele ohnehin erledigt: In neuen Zendesk-Instanzen gibt es den alten Flow Builder gar nicht mehr. Wer heute startet, beginnt direkt eine Ebene höher; dieser Abschnitt gilt dann nur noch für bestehende Setups.
Die Faustregel
Solange die Aufgabe deterministisch ist, nimm Action Flows. Erst wenn sie nicht-deterministisch wird, nimm einen Custom Agent.
Deterministisch heisst: Der Ablauf lässt sich vollständig als Wenn-dann aufschreiben, Daten holen, umformen, prüfen, weiterreichen. Das ist der Alltag, und dafür sind Action Flows gebaut. Nicht-deterministisch heisst: Irgendwo im Ablauf muss etwas interpretiert werden, Freitext verstehen, Absicht erkennen, aus unstrukturierten Angaben eine Entscheidung ableiten. Dort spielt agentisches Schliessen seine Berechtigung aus, und keinen Schritt früher: Ein Agent, der eine Wenn-dann-Aufgabe erledigt, ist nur eine teurere und weniger vorhersehbare Version eines Flows. Und weil der Custom Agent als Schritt in den Flow passt, ist das keine Entweder-oder-Frage: Der Rahmen bleibt deterministisch, nur die eine interpretierende Stelle wird agentisch.
Und Advanced? Immer dann, wenn die Konversation das Zentrum ist: Dort ist es das mächtigste Werkzeug, von deterministischen Dialogen über KI-Suche bis zum eingebundenen Custom Agent. Für Prozesse ohne Gespräch dahinter gilt die Faustregel oben.
Die Entscheidungsmatrix
| Kriterium | Flow Builder | Action Flows | AI Agents Advanced | Custom Agents |
|---|---|---|---|---|
| Ablauf | deterministisch, stichwortbasierter Dialog | deterministisch, Workflow | deterministisch und generativ, Dialog | agentisch, Aufgabe |
| Datentransformation | nein | ja (Code nur synchron) | ja (Action Builder, JSONata) | ja (im Rahmen der Instruktionen) |
| Freitext interpretieren | nur Intent-Zuordnung (ähnlichkeitsbasiert) | ja, via Custom-Agent-Schritt | ja (inkl. KI-Suche/RAG) | ja |
| Nachvollziehbarkeit | mittel | mittel | sehr hoch (Session-Variablen, API-Calls, begründete LLM-Entscheide) | mittel |
Ein Fall für den Custom Agent: aus dem Betrieb
Ein Beispiel aus einem regulierten Umfeld, wo die Faustregel kippt: Bestimmte Konten werden alle 24 Stunden kontrolliert. Selten, aber eben nicht nie, hinterlegt die Compliance im System eine Freitext-Notiz der Art «wenn dieses Konto bis Datum X geöffnet wird, bitte Compliance kontaktieren». Zu selten, um täglich manuell nachzuschauen; zu unstrukturiert für eine Wenn-dann-Regel.
Also übernimmt ein Custom Agent: Er bekommt die Kontodaten und analysiert die Notiz. Stammt sie von der Compliance? Geht es um eine Kontoöffnung, eine Schliessung? Welche Aktionen wurden am Konto vorgenommen? Daraus leitet er ab, ob eine Meldung nötig ist. Wenn ja, erstellt er das Zendesk-Ticket an die Compliance. Der deterministische Rahmen (täglicher Ablauf, definierte Daten rein, Ticket oder kein Ticket raus) bleibt ein Flow; nur die eine Stelle, an der interpretiert werden muss, ist agentisch.
public/werkstatt/bauplaene/agent-typen-entscheid/custom-agent-builder.png
Weiterdenken: dasselbe Muster, neue Fälle
Wer das Muster einmal sieht (deterministischer Rahmen, interpretierender Kern), findet schnell weitere Kandidaten:
Ticket-Reviews. Ein Webhook schickt abgeschlossene Tickets an einen Action Flow, der Custom Agent wertet sie auf Qualität und Auffälligkeiten aus, und das Ergebnis landet als Custom Object oder direkt am Ticket. Die Bewertung ist Interpretationsarbeit, alles drumherum bleibt Flow.
AI-Kontrolle im 24-Stunden-Takt. Das liegt bei mir gerade auf der Werkbank: Alle 24 Stunden werden sämtliche AI-Tickets samt Conversation-Logs gezogen und an einen Action Flow übergeben; ein Custom Agent bewertet die Gespräche und schickt dem Bot-Manager Verbesserungsvorschläge. Damit wird die Qualitätssicherung der Automatisierung selbst automatisiert: der Agent, der dem Agenten auf die Finger schaut.
Was noch aussteht
Flow Builder, ZIS und Advanced laufen bei mir seit Jahren produktiv; diese Einschätzungen sind Betriebserfahrung. Custom Agents sind dagegen bei allen noch jung, auch bei mir: Der Compliance-Fall läuft, die Ideen aus dem letzten Abschnitt sind Werkbank-Stadium, und ein Langzeit-Urteil über Wartung und Grenzen steht noch aus. Sobald es eines gibt, kommt es als eigener Bauplan dazu.