Sprachagenten entwickeln, die Bestand haben: Erkenntnisse aus dem Forward Deployed Engineering

Für die meisten Unternehmen wurde der Erfolg von Einzellösungen im Support lange daran gemessen, wie viele Anfragen sie abwenden. Das bedeutet, das Anrufvolumen zu senken und Interaktionen mit menschlichen Agents zu minimieren. Doch abgewendete Anfragen sind nicht gleich gelöste Anliegen. In dieser Lücke bricht das Kundenerlebnis zusammen. Um sie zu schließen, benötigen Agents nicht nur Zugriff auf Daten, sondern auch auf die Systeme, mit denen sie handeln können. So können Agents Rückerstattungen bearbeiten, Kunden durch den Checkout führen und bei Bedarf mit vollständigem Kontext an einen menschlichen Agent übergeben. Dadurch können Unternehmen Kundeninteraktionen skalieren, die Belastung ihrer Supportteams deutlich reduzieren und das Erlebnis für beide Seiten des Gesprächs verbessern. Bei einer kürzlichen Implementierung bei Revolut, einem Fintech-Unternehmen mit 70 Millionen Kunden weltweit, führte dies zu einer achtfach kürzeren Lösungszeit und einer Erfolgsquote von 99,7 % bei Anrufen.

Unternehmen müssen Veränderungen dieser Größenordnung iterativ angehen, eng an der Kernmission des Unternehmens ausrichten und durch starke Unterstützung der Führungsebene vorantreiben. Auf technischer Ebene birgt das Schlussfolgern in einer unstrukturierten Umgebung inhärente Risiken, die sorgfältig gesteuert werden müssen. Einem Agent die Möglichkeit zu geben, im Customer Relationship Management (CRM) zu handeln, eine Bestellung im Kassensystem zu ändern oder einen Fall zu eskalieren, bedeutet: Das Governance-Modell ist genauso wichtig wie das Modell selbst. Es geht dann nicht mehr darum, ob Agents echte Arbeit erledigen können, sondern welche Mechanismen erforderlich sind, um sie sicher und wiederholt einzusetzen.

In diesem Beitrag teilen wir auf Basis unserer Erfahrungen, was erfolgreiche Agents ausmacht – von der ersten Implementierung bis zur Skalierung über den gesamten Kundenbetrieb eines Unternehmens.

Agents bereitstellen vs. Software bereitstellen

Bevor wir tiefer in die Entwicklung von Agents einsteigen, lohnt sich der Vergleich zwischen der Bereitstellung von Sprachagenten und traditioneller Software, die Unternehmen seit Jahrzehnten einsetzen. Aus dieser Perspektive bestehen Agents aus zwei klar getrennten Komponenten: traditioneller Software und dem Kern-Orchestrator.

Software

Kern-Orchestrator

Die Komponenten traditioneller Software zielen vor allem darauf ab, die Bereitstellung und Leistung des Agents zu verbessern. Bei ElevenAgents gehören dazu Funktionen wie Versionierung, A/B-Tests, Telefonie und die Konfiguration der ersten Nachricht sowie weitere Funktionen. Nach der Bereitstellung weisen diese Komponenten kaum oder gar keine Drift auf. Ihr Verhalten ist daher sehr gut vorhersehbar. Mit soliden Engineering-Praktiken können Unternehmen diese Funktionen schnell nutzen und ihre Performance in Produktion durch einen strengen Satz an Metriken, Traces und Logs genau verstehen. Latenzverbesserungen in dieser Schicht folgen bekannten Mustern: Caching, Connection Pooling, Skalierung der Infrastruktur und Protokolloptimierung sind verlässliche Hebel mit deterministischen Ergebnissen.

Komponenten des Kern-Orchestrators sind naturgemäß schwerer vorhersehbar, bestimmen aber die Laufzeitleistung des Agents – sowohl bei der Antwortqualität als auch bei der wahrgenommenen Latenz. Anders als traditionelle Software arbeiten diese Komponenten mit natürlicher Sprache und Audio. Der Eingaberaum ist praktisch unbegrenzt, und kleine Änderungen in Formulierung, Kontext, Hintergrundgeräuschen oder Nutzerverhalten können mit der Zeit deutlich andere Ergebnisse erzeugen. Herkömmliche Tests reichen deshalb allein nicht aus: Ein Agent kann in Hunderten Testfällen fehlerfrei arbeiten und dennoch in Produktion auf schwer vorhersehbare Weise scheitern.

Auch die Latenz in dieser Schicht ist weniger deterministisch. Sie wird von Modell-Inferenzzeiten, eingebrachten Audioartefakten, Ketten von Tool-Aufrufen und der Variabilität generativer Systeme beeinflusst. Diese Komponenten gut zu steuern, erfordert eine andere Disziplin: Evaluierungsframeworks, Produktionsmonitoring und die Bereitschaft, kontinuierlich anhand echter Gesprächsdaten statt nur anhand von Annahmen vor der Bereitstellung zu iterieren.

Diese Unterscheidung prägt den Einführungsansatz: Beginnen Sie mit Anwendungsfällen, die für das Unternehmen relevant, aber risikoarm sind. Skalieren Sie dann gezielt, wenn das Vertrauen in das System wächst.

Release-Zyklus

Wegbereiter auswählen

Für Teams, die beginnen, Sprachagenten einzuführen, ist die Auswahl der richtigen Wegbereiter eine der folgenreichsten frühen Entscheidungen. Sie hat zudem weniger mit Technologie zu tun, als die meisten erwarten. Teams, die früh Erfolge erzielen und dem endlosen POC-Abgrund entgehen, haben meist eines gemeinsam: Sie können die folgenden Fragen klar beantworten.

• Wie schafft dieser Anwendungsfall messbaren Geschäftswert? Der richtige Anwendungsfall für den Start ist nicht der technisch interessanteste, sondern derjenige, der am ehesten ein Ergebnis beeinflusst, das dem Unternehmen bereits wichtig ist. Das lässt sich an Umsatzwirkung, Kostensenkung, Kundenzufriedenheit und weiteren Metriken messen, die Führungskräfte bereits verfolgen und für die sie verantwortlich sind. Ohne diese direkte Verbindung zum Geschäftswert lassen sich die Iterationszyklen zur Optimierung des Agents nur schwer rechtfertigen. Der Schwung verliert sich dann wahrscheinlich, bevor die Technologie sich beweisen kann.
• Ist Nutzern sofort klar, welchen Umfang und Zweck der Agent hat? Unklarer Umfang ist eine der häufigsten Ursachen für Drift zwischen Entwicklung und Produktion. Nutzer, die nicht verstehen, was ein Agent kann und was nicht, werden seine Grenzen auf Arten testen, die die Evaluierungssuite nie vorhergesehen hat. Ein klar abgegrenzter Agent setzt mit der ersten Nachricht Erwartungen und behandelt Anfragen außerhalb seines Bereichs souverän.
• Wie sehen gute und schlechte Interaktionen aus, und lassen sie sich in konkrete Evaluierungskriterien überführen? Eine gute Interaktion liegt nicht nur dann vor, wenn der Agent die Aufgabe erledigt. Der Nutzer muss sich auch gehört fühlen, die Eskalation muss zum richtigen Zeitpunkt erfolgen und das Ergebnis der Geschäftsabsicht entsprechen. Evaluierungskriterien lassen sich in zwei Kategorien einteilen: quantitative Plattformmetriken wie Aufgabenerfüllungs- und Eskalationsrate sowie transkriptbasierte Kriterien, die eine Analyse des Gesprächs selbst erfordern. Werden die transkriptbasierten Kriterien früh definiert, erhält das Team ein konkretes Entwicklungsziel. Sie setzen außerdem eine natürliche Schwelle für den Go-live. Wenn Ihr Agent seine Evaluierungskriterien dauerhaft erfüllt und die Plattformmetriken stabil sind, können Sie ihn mit Vertrauen in Produktion bringen. Ohne definierte Kriterien ist der Go-live eine Ermessensentscheidung.
• Welche Kompromisse bestehen zwischen Leistung und Kontrolle, und was ist in dieser Phase wichtiger? Je mehr Autonomie ein Agent erhält, desto natürlicher und flexibler werden Interaktionen. Gleichzeitig steigt aber das Risiko, außerhalb validierter Grenzen zu agieren. Engere Kontrolle durch eingeschränktes Prompting und strengere Eskalationslogik senkt dieses Risiko, kann den Agent aber starr wirken lassen. Keines der beiden Extreme ist richtig. Unternehmen, die zu früh alles absichern, erhalten letztlich ein glorifiziertes IVR. Wer zu schnell vorgeht, bevor Vertrauen aufgebaut ist, erzeugt Supportaufwand, der den Nutzen übersteigt. Wo dieser Regler in jeder Reifephase stehen sollte, bestimmt die Modellkonfiguration, die Eskalationslogik und den Anteil des Agent-Wissens im Prompt gegenüber abgerufenen oder strukturierten Quellen.

Sind diese Fragen beantwortet, kann ein Unternehmen von der Strategie zur Umsetzung übergehen und den Entwicklungsumfang festlegen.

Die erste Entwicklung fundieren

Beim Übergang zur Umsetzung können Teams auf Methoden zurückgreifen, die fast so alt sind wie Software selbst. Test Driven Development (TDD) bietet das Gerüst, um Agents während der gesamten Entwicklung an Kernmetriken auszurichten.

Konkret sollten Entwicklungsteams und Business-Stakeholder gemeinsam zwei grundlegende Artefakte definieren und erstellen: Erfolgsevaluierungskriterien, die festlegen, wie ein gutes Ergebnis sowohl auf Ebene einzelner Anrufe als auch aggregiert aussieht, sowie Agent-Tests, die gezielt prüfen, ob der Agent die erwarteten Verhaltensweisen zeigt. Erstere werden am besten anhand realer menschlicher Anrufe definiert, sobald diese vorliegen. Letztere entstehen schrittweise: Sie beginnen mit einer ersten Gruppe erwarteter Verhaltensweisen und werden erweitert, sobald neue hinzukommen und Edge Cases entdeckt werden.

Mit einer ersten Testsuite beginnt die Agent-Entwicklung beim System-Prompt. Hier werden Regeln, Tonalität und Vorgehensweise des Agents festgelegt: was er tun soll, was nicht und wie er sich an den Grenzen seiner Rolle verhalten soll. Ein gut formulierter System-Prompt hängt genauso von seiner Struktur wie von seinem Inhalt ab. Anweisungen in klar benannte Abschnitte zu gliedern, zusammengehörige Hinweise zu bündeln und bedingte Formulierungen zu vermeiden, verbessert die Konsistenz des Agent-Verhaltens deutlich. In dieser Phase greifen wir oft auf den Prompting-Leitfaden zurück.

Neben dem System-Prompt werden die Kernkomponenten des Agents konfiguriert: das LLM, das Text-to-Speech-Modell (TTS) und die Stimme. Die Auswahl des LLM ist vor allem ein Kompromiss zwischen Latenz und Leistung: Auf Geschwindigkeit optimierte Modelle opfern typischerweise einen Teil ihrer Schlussfolgerungsfähigkeit – und umgekehrt. Bei TTS hängt die richtige Wahl davon ab, was der Anwendungsfall am stärksten erfordert: ausdrucksstarke Wiedergabe, geringe Latenz oder mehrsprachige Unterstützung. Die Stimme ist jedoch ebenso eine Marken- wie eine technische Entscheidung. Sie prägt, wie ein Unternehmen auf jeden Anrufer wirkt. Damit gehört sie zu den wenigen Konfigurationsentscheidungen, die ebenso bei Marken- und Marketingteams wie bei den Engineers liegen, die den Agent entwickeln. Die Stimmauswahl kann daher parallel zum restlichen Entwicklungsprozess erfolgen, statt am Anfang oder Ende zum Engpass zu werden. ElevenAgents bietet Zugriff auf mehr als 10.000 Stimmen. Wenn keine davon passt, können Teams eine eigene Stimme klonen oder erstellen.

Von hier aus können Agents optional um eine Wissensdatenbank, Tools und Kanalkonfigurationen erweitert werden. Jede Ergänzung erschließt neue Funktionen, schafft aber auch neue Testflächen. Ob Telefonieintegration, Zugriff auf externe Datenbanken oder die Möglichkeit, im Namen eines Kunden zu handeln: Diese Entscheidungen sollten vor einer Erweiterung des Umfangs anhand der Evaluierungskriterien belastbar geprüft werden. Werden Tools hinzugefügt, geben System-Prompt und Tool-Beschreibung klare Hinweise, wann und wie sie jeweils aufgerufen werden. So nutzt der Agent sie konsistent und im richtigen Kontext.

Mit diesen Grundlagen ist der Agent bereit für den Test.

Auf dem Weg zur Produktionsreife

Sobald die in der Fundamentphase definierten Tests und Evaluierungskriterien gegen einen entwickelten Agent laufen, wird die Entwicklung zu einem engen Zyklus: weitere Tests hinzufügen, Fehler identifizieren, System-Prompt oder Konfiguration aktualisieren und erneut ausführen. Die meisten Fehler in dieser Phase sind keine Modellfehler, sondern Prompt-Fehler. Eine Anweisung, die isoliert klar erscheint, erweist sich als mehrdeutig, wenn der Agent ihr mitten im Gespräch begegnet. Es treten Edge Cases auf, die die ursprüngliche Testsuite nicht vorhergesehen hat. Jeder davon wird zu einem neuen Next-Turn-Test, der direkt aus dem Gespräch erstellt werden kann. Die Frage, wann die Iteration beendet werden kann, hat eine konkrete Antwort: wenn der Agent seine Evaluierungskriterien über mehrere Durchläufe hinweg erfüllt und Plattformmetriken wie Aufgabenerfüllungs- und Eskalationsrate innerhalb akzeptabler Bereiche stabil sind. Deshalb ist es so wichtig, diese Kriterien vor der Entwicklung festzulegen. Ohne sie wird Produktionsreife zur Ermessensentscheidung, und die Ziellinie verschiebt sich ständig.

In der Praxis stellen die meisten Teams fest, dass eine kleine Gruppe wiederkehrender Fehlermuster den Großteil der Probleme verursacht. Am häufigsten sind Prompt-Mehrdeutigkeiten, bei denen der Agent widersprüchliche oder unzureichend spezifizierte Anweisungen erhält und auf unvorhersehbares Verhalten zurückfällt; Tool-Fehlgebrauch, bei dem der Agent ein Tool im falschen Kontext aufruft oder es nicht aufruft, obwohl er sollte; und Eskalationsdrift, bei der der Agent entweder zu aggressiv eskaliert oder Gespräche hält, die er hätte übergeben sollen. Für jedes dieser Probleme gibt es eine Lösung auf Prompt-Ebene. Meist genügen eine präzisere Anweisung, ein explizites Beispiel oder eine Anpassung der Eskalationsschwelle. Das Risiko besteht darin, sie vor dem Go-live nicht zu erkennen.

Teams machen häufig den Fehler, eine bestandene Testsuite als Garantie statt als Signal zu behandeln. Eine Suite, die nur den Idealfall abdeckt, besteht leicht und sagt wenig aus. Erst die Abdeckung von Ablehnungen, Richtungswechseln mitten im Gespräch, mehrdeutigen Eingaben und toolintensiven Interaktionen verleiht den Ergebnissen Gewicht. Ebenso übersehen Teams, die Simulationstests überspringen und sich ausschließlich auf Tests auf Turn-Ebene stützen, eine Klasse von Fehlern, die erst in vollständigen Gesprächen entstehen. Dazu gehören Kontextdrift, bei der der Agent frühere Turns aus dem Blick verliert, oder sich verstärkende Fehler, bei denen ein kleiner Fehltritt zu Beginn des Anrufs zu einem schlechten Ergebnis führt. Sobald wiederkehrende Fehlermuster gelöst sind und der Agent den langen Schwanz an Edge Cases souverän statt perfekt bewältigt, sinkt der zusätzliche Nutzen weiterer Iterationen in der Staging-Umgebung. Dann liefern echte Gespräche das wertvollere Signal.

Der Go-live bedeutet nicht das Ende der Iteration. Er verlagert das Lernen von synthetischen Tests zu Transkripten aus der Produktion. Die Evaluierungskriterien, die den Go-live bestimmt haben, werden zur Basis für die Messung der Live-Performance. Der Zyklus setzt sich von dort aus fort.

Feedbackschleifen, Evaluierung und der richtige Zeitpunkt, Iterationen zu beenden

Sobald Tests definiert sind und laufen, werden Lücken in der Pipeline schnell sichtbar. Mit Gesprächsanalyse können Teams den exakten Moment bestimmen, an dem eine Interaktion fehlging. Dieses Signal dient dazu, einen neuen Test zu erstellen und festzustellen, was geändert werden muss. Die häufigsten Eingriffe erfolgen auf Prompt-Ebene: Tool-Aufrufbeschreibungen präzisieren, explizitere Anweisungen für Edge Cases ergänzen oder Eskalationsbedingungen klären, die sich in der Praxis als mehrdeutig erwiesen haben. In manchen Fällen liegt das Problem tiefer. Dann muss die zugrunde liegende Modellkonfiguration überprüft werden, wenn Latenz oder Schlussfolgerungsqualität den Anforderungen des Anwendungsfalls nicht genügen.

Die wichtigste Disziplin in dieser Phase ist, Änderungen zu validieren, statt sie einfach anzunehmen. Eine Lösung für einen Fehler kann unbemerkt einen anderen verursachen. ElevenAgents unterstützt Versionierung. So können Teams neue Iterationen mit einem kleinen Anteil der Nutzer testen, bevor sie für die gesamte Nutzerbasis ausgerollt werden. Damit lässt sich bestätigen, dass Verbesserungen die Ergebnisse tatsächlich verbessern, statt das Fehlermuster nur an eine andere Stelle zu verschieben.

Was schiefgehen kann

Der folgenreichste Fehler in dieser Phase ist, verzweigte Rollouts zu überspringen und Änderungen direkt für die gesamte Nutzerbasis bereitzustellen. Ohne gestaffelte Rollouts verlieren Sie die Möglichkeit, die Wirkung jeder einzelnen Änderung zu isolieren. Bei hoher Skalierung wird es dadurch fast unmöglich zu verstehen, was Verbesserungen oder Rückschritte in Ihren Plattformmetriken tatsächlich verursacht. Die gesamte Nutzerbasis als Testumgebung zu behandeln, ist nicht nur riskant. Es nimmt Ihnen auch die Observability, die Sie für fundierte Entscheidungen benötigen.

Neben der Rollout-Strategie sollten zwei weitere Fehlermodi vermieden werden. Der erste ist eine Übergewichtung jüngster Fehler. Wenn ein prominentes Gespräch schiefläuft, entsteht schnell der Impuls, es sofort und umfassend zu beheben. Reaktive Prompt-Änderungen ohne Ausführung der vollständigen Testsuite führen jedoch häufig zu Regressionen bei Verhaltensweisen, die zuvor stabil waren. Jede Änderung, wie klein auch immer, sollte als neue Iteration behandelt und entsprechend getestet werden. Der zweite Fehlermodus ist Evaluierungsdrift. Mit der Zeit können Teams die Anforderungen an einen bestandenen Test unbewusst senken, besonders unter dem Druck, zu releasen. Die beim Scoping definierten Evaluierungskriterien sollten der Anker bleiben. Wenn sie zu streng erscheinen, sollten sie gezielt überprüft und aktualisiert werden, statt Standards informell erodieren zu lassen.

Mit Vertrauen skalieren

Mehr Traffic zuzulassen ist eine Vertrauensentscheidung, keine zeitbasierte. Das Signal zur Ausweitung ist erreicht, wenn der Agent seine Evaluierungskriterien über mehrere Testläufe hinweg erfüllt, Plattformmetriken stabil sind und verzweigte Rollouts keine nennenswerte Regression gegenüber der Kontrollgruppe zeigen.

Eine häufige Frage in dieser Phase ist, wie viel Traffic für eine belastbare Schlussfolgerung genügt. Batches mit weniger als 100 Anrufen pro Zweig erzeugen zu viel Varianz, um Ergebnisse zuverlässig zu bewerten. Eine Bestehensquote von 60 % bei 25 Anrufen und dieselbe Quote bei 100 Anrufen stehen für sehr unterschiedliche Vertrauensniveaus. Zusätzlich zu einer festgelegten Anzahl sollte der Batch groß genug sein, um das vollständige Spektrum realistischer Eingaben sichtbar zu machen – darunter wahrscheinliche Edge Cases, seltene Intents und Fehlermodi, die nur bei hohem Volumen auftreten und in kleinen Stichproben kaum erscheinen.

Mehr Traffic verstärkt sowohl das, was funktioniert, als auch das, was nicht funktioniert. Eine Ausweitung, bevor die zentralen Fehlermuster behoben sind, schafft Supportaufwand, der sich nur schwer wieder zurücknehmen lässt.

Wiederholen und verbessern

Zu wissen, wann man aufhören sollte, ist genauso wichtig wie zu wissen, was zu korrigieren ist. Iterationen bringen abnehmenden Nutzen. Das richtige Signal für eine Pause ist, wenn der Agent die beim Scoping festgelegten Evaluierungskriterien dauerhaft erfüllt. Ab diesem Punkt bergen weitere Änderungen mehr Risiko als Nutzen.

Wie das „dauerhafte Erfüllen der Kriterien“ aussieht, hängt vom Kontext ab. Teams mit eingeschränktem Datenzugriff oder unvollständigen Integrationen werden möglicherweise feststellen, dass Eskalationsraten um 50 % eine realistische Obergrenze sind, bis diese Einschränkungen behoben sind. Bei gutem Datenzugriff streben die leistungsstärksten Implementierungen typischerweise eine Aufgabenerfüllung von über 80 % und eine Eskalationsrate von unter 20 % an. Wichtiger als jede einzelne Zahl ist Stabilität: gleichbleibende Leistung über mehrere Wochen Produktions-Traffic hinweg, ohne nennenswerte Regression über Testläufe hinweg. Das ist das entscheidende Signal. Wenn der zusätzliche Gewinn der nächsten Iteration kleiner ist als das Regressionsrisiko, ist es Zeit aufzuhören.

Das bedeutet nicht, dass die Arbeit abgeschlossen ist. Wenn neue Anforderungen entstehen, beginnt der Prozess wieder von vorn. Die Scoping-Fragen aus der ersten Entwicklung sind für die zweite weiterhin genauso relevant. Der Unterschied: Teams, die in einen zweiten Zyklus starten, verfügen über eine Testsuite, eine Evaluierungsbasis und operative Erfahrung, die im ersten Zyklus erst von Grund auf aufgebaut werden mussten. Dieser kumulative Vorteil unterscheidet Unternehmen, die langfristigen Nutzen aus Sprach-agenten ziehen, von denen, die im Proof of Concept stecken bleiben.

Fazit

Die Teams, die wir dabei erlebt haben, die Lücke zwischen abgewendeten und gelösten Anliegen zu schließen, definieren vor Beginn der Entwicklung, wie ein gutes Ergebnis aussieht. Sie bleiben während des Iterationszyklus diszipliniert und behandeln jede Implementierung als Grundlage für die nächste. Konversations-Agents sind keine einmalige Bereitstellung – echte Gespräche bringen Edge Cases ans Licht, die keine Testsuite vollständig vorhersehen kann. Die Verbesserungsarbeit endet nicht mit dem Go-live.

ElevenAgents ist auf diese Realität ausgerichtet. Agent-Tests, Gesprächsanalyse und verzweigte Rollouts bilden die Grundlage, die aus einem Proof of Concept ein System macht, das Kundenanliegen im großen Maßstab tatsächlich löst – statt sie nur abzuwenden. Diese Lücke gilt es zu schließen.