KI-Agenten-Orchestrierung für Support-Leitungen erklärt

KI-Agenten-Orchestrierung ist die Koordination mehrerer spezialisierter KI-Agenten und der Menschen dahinter, damit eine Kundenanfrage im richtigen Moment und mit dem richtigen Kontext beim richtigen Agenten ankommt. Ein Orchestrator, entweder ein führender Agent oder der Code um die Agenten herum, entscheidet, wer als Nächstes handelt, was weitergegeben wird und wann die Arbeit erledigt ist.

Kurz gesagt

Die Orchestrierung entscheidet, welcher Agent welchen Schritt einer Konversation übernimmt, welchen Kontext er erhält und wann ein Mensch übernimmt.
Die meisten Support-Setups kombinieren einige Muster: einen Router oder Supervisor vorn, feste Schrittfolgen für regulierte Aktionen und Übergaben zwischen Agenten und an Menschen.
Multi-Agent-Konversationen brechen an den Nahtstellen: verlorener Kontext bei einer Übergabe, Schleifen zwischen Agenten, der falsche Agent handelt, und Konversationen werden geschlossen, bevor die Aufgabe erledigt ist.
Dashboards pro Agent verbergen diese Fehler, denn jeder Agent kann gut aussehen, während die Journey des Kunden scheitert.
Prüfen Sie die Journey, nicht den einzelnen Turn: Fügen Sie jedes Agenten- und Menschen-Segment zu einem Datensatz zusammen, bewerten Sie die Nahtstellen und ordnen Sie jeden Fehler dem Segment zu, das ihn verursacht hat.

Was ist KI-Agenten-Orchestrierung?

KI-Agenten-Orchestrierung ist die Ebene, die mehrere KI-Agenten innerhalb eines Systems koordiniert. IBM beschreibt sie als Koordination spezialisierter Agenten auf gemeinsame Ziele hin, mit einem Orchestrator, der ein zentraler Agent oder ein Framework sein kann. Im Kundenservice macht sie aus einem Triage-Bot, einem Abrechnungsagenten, einem Retourenagenten und Ihrem menschlichen Team ein zusammenhängendes Erlebnis.

Ein KI-Agent (auf Englisch) ist ein Modell mit Anweisungen und Tools, das auf ein Ziel hinarbeitet. Die Orchestrierung ist die Verkehrssteuerung zwischen mehreren von ihnen und beantwortet bei jedem Turn vier Fragen:

Wer handelt als Nächstes? Ein Triage-Agent, ein Spezialist, ein Mensch oder niemand (die Konversation ist beendet).
Was bekommt er? Das vollständige Transkript, eine Zusammenfassung oder nur die Felder, die er braucht.
Was darf er tun? Daten lesen, eine Bestellung ändern, eine Erstattung auslösen oder nur antworten.
Wann ist Schluss? Das Ziel ist erreicht, ein Turn-Limit ist erreicht, oder ein Mensch muss freigeben.

Anthropic nennt Systeme, in denen „LLMs und Tools über vordefinierte Codepfade orchestriert werden“, Workflows, und Systeme, in denen Modelle „ihre eigenen Abläufe und die Nutzung von Tools dynamisch steuern“, Agenten. Die meiste Orchestrierung im Support mischt beides: feste Pfade für Erstattungen und Identitätsprüfungen, Urteilsvermögen des Agenten für offene Fragen. Unsere Erklärung, was agentische KI ist (auf Englisch), behandelt die übergeordnete Kategorie.

Wer ist ein KI-Orchestrator? Technisch die Komponente (ein führender Agent oder ein Framework), die Arbeit verteilt. Organisatorisch die Person oder das Team, das verantwortet, wie Agenten und Menschen sich die Arbeit teilen: Routing-Regeln, Auslöser für Eskalationen und der Qualitätsmaßstab für die ganze Journey.

Was sind die wichtigsten Muster der KI-Agenten-Orchestrierung?

Eine Handvoll Muster deckt fast jedes Support-Setup ab: ein Router, der jede Anfrage an einen Spezialisten schickt, ein Supervisor, der die Kontrolle behält und Spezialisten wie Tools aufruft, eine feste Schrittfolge, parallele Agenten an derselben Eingabe, eine Hierarchie von Supervisoren, Übergaben zwischen Agenten und an Menschen sowie eine Maker-Checker-Schleife. Echte Einsätze kombinieren sie.

Anbieter benennen diese Muster unterschiedlich. Das Azure Architecture Center von Microsoft führt sequenzielle, parallele, Gruppenchat-, Handoff- und Magentic-Orchestrierung auf und merkt an, dass Handoff auch Routing, Triage, Transfer, Dispatch oder Delegation heißt. Das OpenAI Agents SDK unterscheidet „Agents as Tools“, bei denen ein Manager die Kontrolle behält, von „Handoffs“, bei denen der Spezialist übernimmt. IBM ergänzt zentrale, dezentrale, hierarchische und föderierte Modelle. Die Begriffe unterscheiden sich; die Fragen für den Support nicht. Die Tabelle unten beschreibt jedes Muster in Support-Begriffen.

Die wichtigste Unterscheidung für eine Support-Leitung ist, wem der Kunde nach dem Wechsel gehört. In einem Supervisor-Setup bleibt der führende Agent für die finale Antwort verantwortlich. Bei einer Übergabe übernimmt der empfangende Agent die volle Verantwortung, wie Microsofts Dokumentation zur Handoff-Orchestrierung ausführt. Das entscheidet, wen Sie verantwortlich machen, wenn die QA eine schlechte Antwort findet.

Die Tabelle der Orchestrierungsmuster: Fehler und Prüfungen für den Support

Jedes Orchestrierungsmuster scheitert auf seine eigene Weise und braucht deshalb seine eigene Prüfung. Die Tabelle ordnet jedem Muster ein Support-Beispiel, den zu erwartenden Fehler und den Prüfpunkt im Review zu. Kopieren Sie sie in Ihren QA-Plan und behalten Sie die Zeilen, die dazu passen, wie Ihre Agenten heute verschaltet sind.

Muster	So funktioniert es	Beispiel im Support	Typischer Fehler	Was Sie prüfen
Router (Triage)	Ein Triage-Agent klassifiziert die Anfrage und übergibt sie an einen Spezialisten	„Wo ist meine Erstattung?“ geht an den Abrechnungsagenten	Falsches Routing: Der Bestellagent beantwortet eine Abrechnungsfrage mit Überzeugung	War das erste Routing richtig? Ist der Spezialist in seinem Zuständigkeitsbereich geblieben?
Supervisor (Manager)	Ein führender Agent behält die Konversation und ruft Spezialisten als Tools auf	Der führende Agent fragt den Richtlinienagenten, ob eine verspätete Rückgabe erlaubt ist	Der führende Agent ignoriert oder verändert die Antwort eines Spezialisten; der Kunde bekommt eine Mischung aus beiden	Stimmt die finale Antwort mit dem überein, was der Spezialist zurückgegeben hat?
Sequenziell (Pipeline)	Feste Schritte, jeder nutzt die Ausgabe des vorherigen	Identität prüfen, Berechtigung prüfen, Erstattung auslösen, Zusammenfassung senden	Ein früher Fehler zieht sich durch jeden Schritt (eine falsche Bestellnummer führt zur falschen Erstattung)	Wurde die Ausgabe jedes Schritts geprüft, bevor der nächste sie nutzte?
Parallel (concurrent)	Mehrere Agenten arbeiten gleichzeitig an derselben Nachricht	Antwortentwurf und Richtlinienprüfung laufen nebeneinander	Widersprüchliche Ergebnisse werden schlecht zusammengeführt; der Kunde sieht zwei Antworten	Wenn die Agenten uneinig waren, welcher hat sich durchgesetzt, und war das die richtige Regel?
Hierarchisch	Supervisoren steuern Teams von Agenten pro Bereich	Ein Logistik-Supervisor verteilt zwischen Sendungsverfolgungs- und Retourenagent	Eine Anfrage fällt zwischen zwei Supervisoren, und niemand ist zuständig	Gibt es auf jeder Ebene eine verantwortliche Instanz für jede Journey?
Übergabe von Agent zu Agent	Jeder Agent entscheidet, wann er die Konversation weitergibt	Der Bestellagent gibt einen Fall mit beschädigtem Artikel an den Retourenagenten weiter	Schleifen (A zu B zu A), verlorener Kontext, der Kunde wird zweimal nach denselben Angaben gefragt	Wie viele Übergaben? Ist ein Agent zweimal aufgetaucht? Musste der Kunde Angaben wiederholen?
Übergabe an einen Menschen	Ein Agent eskaliert mit einer Zusammenfassung an eine Person	Der Retourenagent eskaliert eine strittige Abbuchung an einen Menschen	Eskalation zu spät oder ohne Zusammenfassung, sodass der Mensch bei null anfängt	Richtiger Auslöser, richtiger Zeitpunkt, und hatte der Mensch den Kontext, den er brauchte?
Maker-Checker	Ein Agent entwirft, ein anderer gibt frei oder schickt zurück	Ein Entwurfsagent schreibt ein Kulanzangebot; ein Prüfagent gleicht es mit der Richtlinie ab	Der Prüfer lässt einen falschen Entwurf durch, oder die Schleife läuft bis zu einem Limit und schickt dann doch die letzte Version	Was macht der Prüfer, wenn er die Obergrenze an Durchläufen erreicht?

Übergaben von Agent zu Agent tragen das höchste Risiko für Schleifen und verlorenen Kontext, und bei Übergaben an Menschen bemerken Kunden Fehler zuerst. Unser Leitfaden zur Übergabe zwischen KI-Agent und Mitarbeitenden geht auf diese Zeile genauer ein.

Wo brechen Multi-Agent-Konversationen im Support?

Multi-Agent-Konversationen im Support brechen an den Nahtstellen zwischen Agenten, nicht in ihnen. Die vier wichtigsten Fehler sind verlorener Kontext bei einer Übergabe, Schleifen zwischen Agenten, der falsche Agent, der auf eine Anfrage reagiert, und eine Konversation, die geschlossen wird, bevor das Problem gelöst ist. Jeder davon kann auftreten, während jeder einzelne Agent korrekt aussieht.

Verlorener Kontext. Übergaben geben weniger weiter, als die meisten Teams annehmen. In der Handoff-Orchestrierung des Microsoft Agent Framework werden Nachrichten von Nutzern und Agenten zwischen Agenten synchronisiert, Inhalte von Tool-Aufrufen aber nicht weitergegeben. Der nächste Agent sieht, was gesagt wurde, nicht unbedingt, was der vorherige Agent nachgeschlagen oder getan hat. Wenn der Abrechnungsagent die Bestellung nicht sieht, die der Bestellagent abgerufen hat, fragt er den Kunden erneut oder arbeitet mit einer Annahme.

Schleifen. Zwei Agenten können eine Anfrage hin und her schieben, oder ein Agent wiederholt denselben Schritt. Microsofts Architekturleitfaden nennt „endlose Übergabeschleifen“ als Fallstrick des Handoff-Musters und empfiehlt Obergrenzen für Durchläufe. Im autonomen Modus lässt sein Handoff-Framework jeden Agenten standardmäßig bis zu 50 Turns laufen, bevor er eine Eingabe des Nutzers braucht, weit mehr, als ein Kunde hinnehmen wird.

Der falsche Agent handelt. Eine falsch geroutete Anfrage erreicht einen Agenten, der außerhalb seines Bereichs mit Überzeugung antwortet. Die Antwort klingt flüssig, also bemerkt es niemand, solange sie nicht jemand gegen die richtige Richtlinie prüft.

Zu früh geschlossen. Agenten können aufhören, bevor die Aufgabe erledigt ist, oder gar nicht erkennen, wann sie erledigt ist.

Die Forschung bestätigt das. Eine Studie von 2025, Why Do Multi-Agent LLM Systems Fail?, annotierte 1.642 Ausführungs-Traces aus sieben Frameworks und fand 14 Fehlerarten. Wiederholte Schritte traten in 15,7 % der Traces auf, nicht erkannter Abschluss der Aufgabe in 12,4 % und Kontextverlust in 2,8 %. Die Autoren stellten auch fest, dass erfolgreiche Durchläufe nicht fehlerfrei sind. Die Traces stammten aus Programmier-, Mathematik- und allgemeinen Aufgaben, nicht aus dem Kundenservice. Verstehen Sie die Anteile deshalb als Warnung, nicht als Benchmark. Die Lehre lässt sich übertragen: Ein „gelöstes“ Ergebnis kann Fehler auf dem Weg verbergen, wie unser Beitrag zu den stillen Fehlern von KI-Agenten zeigt.

Was sollten Sie in einem orchestrierten Supportbetrieb überwachen?

Überwachen Sie die Journey, nicht nur jeden einzelnen Agenten. Scores pro Agent zeigen, ob der Abrechnungsagent Abrechnungsfragen gut beantwortet, nicht aber, dass Kunden zwischen drei Agenten hin und her gesprungen sind, bevor sie ihn erreichten. Verfolgen Sie stattdessen wenige Journey-Signale: Übergaben, Schleifen, wiederholte Kundenangaben, Treffsicherheit des ersten Routings, Eskalationen mit Kontext und die Lücke zwischen Lösung auf Agenten- und auf Journey-Ebene.

Die Startregeln unten sind unsere, kein Branchenstandard: Messen Sie vier Wochen lang Ihren eigenen Ausgangswert und justieren Sie dann nach.

Signal	So messen Sie es	Startregel
Übergaben pro Konversation	Agentenwechsel im Konversationsprotokoll zählen	Jede Konversation mit mehr als 3 Übergaben prüfen
Wiederholter Agent (Schleife)	Derselbe Agent erscheint zweimal in einer Konversation, mit einem anderen Agenten dazwischen	Alle prüfen; jeder steigende Trend ist ein Routing-Fehler
Quote erneuter Nachfragen	Der Kunde nennt dieselbe Kennung (Bestellnummer, E-Mail) zweimal	Untersuchen, wenn über 5 % der Multi-Agent-Konversationen
Treffsicherheit des ersten Routings	Anteil der ersten Routings, die ein Reviewer als richtig markiert	Den Router untersuchen, wenn unter 90 %
Eskalation mit Kontext	Anteil der Übergaben an Menschen, bei denen der Mensch nicht erneut fragen musste	95 % oder mehr anstreben
Lösungslücke	„Gelöst“-Quote pro Agent minus Quote der richtig gelösten Journeys	Eine Lücke über 5 Punkten bedeutet, dass sich Fehler zwischen den Agenten verstecken
Turn- oder Durchlauflimit erreicht	Konversationen, die endeten, weil ein Limit erreicht wurde	Jede prüfen; das sind festgefahrene Schleifen

Microsofts Leitfaden macht denselben Punkt aus Sicht der Entwicklung: Instrumentieren Sie alle Agentenoperationen und Übergaben, und nutzen Sie Bewertungsrubriken oder Model-as-Judge-Evaluierung statt Tests auf exakte Übereinstimmung, weil die Ausgaben von Agenten variieren. Zu Dashboards und Alarmen lesen Sie unseren Leitfaden zum KI-Agenten-Monitoring.

Wie prüfen Sie eine Journey, die über mehrere Agenten und Menschen läuft?

Um eine Multi-Agent-Journey zu prüfen, machen Sie die ganze Konversation zur Prüfeinheit. Fügen Sie jedes Segment von Agenten und Menschen zu einem Datensatz zusammen, bewerten Sie jedes Segment an seiner eigenen Aufgabe, bewerten Sie die Nahtstellen mit Journey-Kriterien und ordnen Sie jeden Fehler dem Segment zu, das ihn verursacht hat. Beheben Sie dann diesen Teil und bewerten Sie erneut.

Schritt 1: Die Journey zusammenfügen. Eine Konversations-ID begleitet den Kunden durch jeden Agenten und jeden Menschen. Wenn Ihre Agenten an verschiedenen Orten protokollieren, besteht die erste QA-Aufgabe darin, das vollständige Transkript, mit dem Namen des Agenten bei jedem Turn, in den Helpdesk oder eine gemeinsame Prüf-Queue zu bekommen.

Schritt 2: Jedes Segment an seiner Aufgabe bewerten. Abrechnungsgenauigkeit für den Abrechnungsagenten, Routing für den Triage-Agenten, Lösung für den Menschen. Ein gemeinsamer Kern an Kriterien hält menschliche und KI-Segmente vergleichbar; unser Leitfaden zu einer Scorecard für Mensch und KI zeigt, wie Sie ihn aufbauen.

Schritt 3: Journey-Kriterien ergänzen. Das sind die Fragen, die kein einzelnes Segment beantworten kann:

War das erste Routing richtig?
Musste der Kunde eine Angabe wiederholen?
Ist ein Agent zweimal aufgetaucht, oder ist die Konversation in eine Schleife geraten?
Hat jede Übergabe die Daten mitgegeben, die der nächste Agent brauchte?
Wenn ein Mensch übernommen hat: Kam die Eskalation beim richtigen Auslöser, mit einer brauchbaren Zusammenfassung?
War das eigentliche Problem des Kunden am Ende gelöst, unabhängig davon, wer es gelöst hat?

Schritt 4: Den Fehler zuordnen. Jede gescheiterte Journey bekommt genau ein ursächliches Segment: Router, ein Spezialist, der Übergabemechanismus oder der Mensch. Ohne Zuordnung ist ein Journey-Fehler das Problem aller und die Aufgabe von niemandem.

Schritt 5: Beheben und erneut bewerten. Leiten Sie die Erkenntnis an die verantwortliche Person für diesen Teil weiter (Prompt, Routing-Regel, Wissensartikel, Auslöser für Eskalationen) und bewerten Sie denselben Journey-Typ erneut, um zu bestätigen, dass die Korrektur hält. Testen Sie Änderungen, bevor sie live gehen; siehe unseren Leitfaden KI-Agenten testen.

Ein Rechenbeispiel (Illustration, Zahlen erfunden, um die Rechnung zu zeigen)

Ein Supportteam bearbeitet 40.000 Konversationen im Monat mit einem Triage-Agenten, drei Spezialagenten und einem menschlichen Team:

26.000 Konversationen (65 %) gehen vom Triage-Agenten zu einem Spezialisten und enden dort.
10.000 (25 %) laufen über zwei oder mehr KI-Agenten.
4.000 (10 %) enden bei einem Menschen.

Die Dashboards pro Agent sehen gesund aus: Jeder Spezialist erfüllt mehr als 90 % seiner eigenen Kriterien. Dann bewertet die QA-Leitung eine Zufallsstichprobe von 200 Multi-Agent-Journeys anhand der Journey-Kriterien oben. 34 scheitern (17 %): 14 Kunden mussten ihre Bestellnummer wiederholen, 9 Konversationen liefen zurück zum Triage-Agenten, 6 wurden vom falschen Spezialisten beantwortet und 5 wurden geschlossen, bevor die Erstattung bestätigt war.

Hochgerechnet sind 17 % von 10.000 etwa 1.700 gescheiterte Journeys im Monat. Wenn Journeys mit nur einem Agenten zu 5 % scheitern, sind das 1.300 Fehler aus 26.000. Das Viertel der Konversationen, das über mehrere Agenten läuft, erzeugt mehr Fehler als die zwei Drittel, die das nicht tun.

Die Stichprobe zeigt auch die Grenzen von Stichproben. Bei 200 Konversationen und einer Fehlerquote von 17 % liegt die Fehlermarge bei 95 % Konfidenz bei etwa plus oder minus 5,2 Punkten (1,96 × √(0,17 × 0,83 / 200)). Der 95-%-Bereich reicht von etwa 1.200 bis 2.200 gescheiterten Journeys. Und die 14 erneuten Nachfragen zeigen auf eine Korrektur: Das Abfrageergebnis des Bestellagenten erreicht den Abrechnungsagenten bei der Übergabe nicht.

Sehen Sie es an Ihren eigenen Konversationen. Kaizo bewertet 100 % Ihrer Supportkonversationen, von Menschen und KI-Agenten, anhand Ihrer eigenen Scorecard und verknüpft jeden Score mit den Belegen in der Konversation. Termin buchen.

Welches Framework oder welche Plattform für die KI-Agenten-Orchestrierung sollten Sie wählen?

Das beste Framework für die KI-Agenten-Orchestrierung ist das, das Ihr Agentenanbieter oder Ihr Entwicklungsteam bereits gut unterstützt; Support-Leitungen entscheiden das selten allein. Was Sie festlegen sollten, sind die Anforderungen: sichtbares Routing pro Konversation, weitergegebener Kontext bei Übergaben, Turn-Limits, Eskalation an Menschen mit Zusammenfassung und Transkripte, die dort ankommen, wo Ihr QA-Team arbeitet.

Die Optionen fallen in drei Gruppen:

In Ihre Plattform für KI-Agenten eingebaut. Agentenplattformen für den Kundenservice routen zwischen ihren eigenen Agenten und an Ihr menschliches Team. Am wenigsten Arbeit, am wenigsten Kontrolle.
Frameworks für Entwickler. Microsoft Agent Framework, das OpenAI Agents SDK, LangChain und CrewAI, unter anderen. Volle Kontrolle, und Ihre Entwickler verantworten jede Regel.
Orchestrierungsebenen für Unternehmen. Produkte wie IBM watsonx Orchestrate koordinieren Agenten, Tools und Workflows unternehmensweit über eine zentrale Ebene.

In welcher Gruppe Sie auch sind: Stellen Sie vor dem Go-live fünf Fragen.

Können wir pro Konversation sehen, welcher Agent bei jedem Turn gehandelt hat und warum er übergeben hat?
Was genau wird bei einer Übergabe weitergegeben: das Transkript, eine Zusammenfassung, Tool-Ergebnisse, Kundendaten?
Wie lauten die Limits für Turns und Durchläufe, und was passiert, wenn eines erreicht wird?
Wie übernimmt ein Mensch, und was sieht er zuerst?
Wo landet das vollständige Transkript, und kann unser QA-Team es dort bewerten?

Wenn die Antwort „Das können wir Ihnen nicht zeigen“ lautet, können Sie auch die Journey nicht prüfen.

Wann ist Multi-Agent-Orchestrierung nichts für Sie?

Multi-Agent-Orchestrierung ist nichts für Sie, wenn ein einziger, klar abgegrenzter KI-Agent mit den richtigen Tools und einem klaren Eskalationsweg Ihr Volumen bewältigen kann. Microsofts Leitfaden rät, die geringste Komplexität zu wählen, die Ihre Anforderungen verlässlich erfüllt, und nennt einen einzelnen Agenten mit Tools oft die richtige Standardwahl für Unternehmensanwendungen. Jeder zusätzliche Agent bringt Übergaben, Latenz, Kosten und Fehlerarten mit.

Praktiker in Foren zu Customer Success machen einen ähnlichen Punkt: Die Erfolge kommen meist von einem KI-Agenten, der eine eng umrissene Gruppe von Fragen gut beantwortet, nicht von einem, der alles abdecken will. Wenn Ihr KI-Agent einige Hundert Konversationen im Monat in einem Bereich bearbeitet, verzichten Sie auf Orchestrierung, lesen Sie die Transkripte wöchentlich und stecken Sie die Mühe in die Wissensdatenbank und den Auslöser für Eskalationen.

Das Routing selbst kommt von Ihrer Agentenplattform oder einem der Frameworks oben. Kaizos Rolle beginnt nach der Konversation: Kaizo bewertet gelöste Konversationen aus Zendesk oder Salesforce anhand Ihrer Scorecard.

So starten Sie diese Woche

Sie können diese Woche ohne neue Tools beginnen, orchestrierte Journeys zu prüfen: Zeichnen Sie auf, wie Ihre Agenten verschaltet sind, und bewerten Sie dann eine kleine Zahl von Multi-Agent-Journeys anhand der Journey-Kriterien. Das Ziel der ersten Woche ist kein Dashboard, sondern die Nahtstelle zu finden, die am häufigsten versagt.

Zeichnen Sie Ihre Verschaltung auf. Listen Sie jeden KI-Agenten auf, wer an wen übergeben kann und wo Menschen ins Spiel kommen, mit dem Muster aus der Tabelle oben.
Ziehen Sie 30 Multi-Agent-Journeys, plus 10, die bei einem Menschen geendet haben.
Bewerten Sie sie anhand der sechs Journey-Kriterien und notieren Sie für jeden Fehler das ursächliche Segment.
Wählen Sie die schlechteste Nahtstelle. Meist eine Übergabe, die Kontext verliert, oder eine Routing-Regel, die danebenliegt.
Benennen Sie eine verantwortliche Person für jeden Agenten und jede Übergaberegel.

Wenn die manuelle Prüfung das Muster belegt, automatisieren Sie sie. Kaizos Qualitätssicherung für KI-Agenten bewertet Konversationen von KI-Agenten mit derselben Scorecard wie die Ihres Teams, einschließlich Übergabekriterien, etwa ob der Agent beim richtigen Auslöser eskaliert und den Kontext weitergegeben hat, und AutoPilot bewertet jede Konversation, sobald sie gelöst ist. Für das Gesamtbild beginnen Sie mit unserem Leitfaden zum agentischen Kundenservice; für die Regeln, denen diese Agenten folgen, lesen Sie KI-Agenten-Governance.

Häufig gestellte Fragen

Ist ChatGPT ein Agent oder ein LLM?

ChatGPT ist ein Produkt, das auf großen Sprachmodellen (LLMs) basiert. Wenn es eine einzelne Frage beantwortet, verhält es sich wie eine Chat-Oberfläche zu einem LLM. Wenn es Tools nutzt, im Web sucht oder eine mehrstufige Aufgabe selbstständig abarbeitet, verhält es sich wie ein Agent. Der Unterschied liegt darin, was das System tun darf, nicht im Modell.

Was ist der Unterschied zwischen einem Multi-Agent-System und agentischer KI?

Agentische KI beschreibt KI, die mit einer gewissen Autonomie auf ein Ziel hin handelt. Ein Multi-Agent-System ist eine Art, sie zu bauen: mehrere spezialisierte Agenten, koordiniert durch Orchestrierung, statt eines Agenten, der alles tut. Ein einzelner Agent kann agentisch sein; ein Multi-Agent-System fügt die Übergaben hinzu und damit die Nahtstellen, die Sie prüfen müssen.

Ist Kubernetes ein Orchestrierungstool?

Ja, aber für Container, nicht für KI-Agenten. Kubernetes plant und skaliert die Software, auf der Ihre Dienste laufen. KI-Agenten-Orchestrierung entscheidet, welcher Agent welchen Teil einer Konversation übernimmt und welchen Kontext er erhält. Ein Agentensystem kann auf Kubernetes laufen, aber Kubernetes leitet keine Anfragen zwischen Agenten weiter.

Was ist eine Orchestrierungsebene für KI-Agenten?

Die Orchestrierungsebene liegt über den einzelnen Agenten und entscheidet über Routing, Weitergabe von Kontext, Berechtigungen und Abbruchregeln. Sie kann ein führender Agent sein, ein Framework in Ihrem eigenen Code oder ein zentrales Produkt. Für die QA sollte sie außerdem den Nachweis liefern, wer gehandelt hat und warum.

Wie evaluieren Sie ein Multi-Agent-System im Kundenservice?

Evaluieren Sie es auf zwei Ebenen: jeden Agenten an seiner eigenen Aufgabe und die ganze Journey anhand von Kriterien wie richtigem ersten Routing, keinen wiederholten Angaben, keinen Schleifen und einem richtigen Endergebnis. Unser Leitfaden zur KI-Agenten-Evaluierung behandelt die Methoden, von Testsets bis zur Bewertung von Live-Konversationen.