Auswahl eines Partners für die Entwicklung von KI-Agenten: Fragen jenseits der Demo.

Eine Demo kann bis zum Zusammentreffen mit einem echten Unternehmen hervorragend aussehen. In einem typischen Fall findet ein Agent Informationen, entwirft eine Antwort und aktualisiert ein Datensatz in weniger als einer Minute – es scheint, als wäre alles bereit für die Einführung. Dann tauchen jedoch praktische Probleme auf: Was passiert, wenn der Datensatz unvollständig ist? Kann der Agent Daten sehen, die dem Mitarbeiter nicht zugänglich sind? Wird er eine Aktion nach einem API-Timerout erneut ausführen? Wer untersucht den Fall, wenn die Änderung falsch war?

Diese Fragen beeinflussen, wie ein Anbieter für Agentenentwicklung bewertet werden sollte. Die wichtigere Frage ist nicht, welche Firma die glattesten Demos hat, sondern welche Mannschaft alles rund um diese Demos versteht. Die besten Anbieter bieten weniger beeindruckende Demonstrationen an und stellen bessere Fragen zu Workflows, Berechtigungen, Integrationen, Fehlern und Verantwortlichkeiten.

Was hat sich bis 2026 geändert

Vor Kurzem drehten sich Demos um das Planen einer Aufgabe, das Aufrufen eines Tools oder das Fortsetzen eines längeren Gesprächs. Diese Fähigkeiten sind zwar wichtig, unterscheiden aber ernsthafte Teams nicht mehr von einfachen Implementierern. Käufer erwarten heute von Agenten, dass sie in CRMs, Dokumentenspeichern, Datenbanken, Ticketing-Tools, internen Anwendungen sowie Genehmigungsprozessen arbeiten können.

Das ist ein schwierigeres Problem. Der Agent muss die Aufgabe verstehen, die richtigen Informationen abrufen, das richtige Tool wählen, Berechtigungen respektieren, eine Aufzeichnung seiner Handlungen führen und wissen, wann er aufhören soll. Stärkere Anbieter sprechen weniger über autonome Intelligenz und mehr über Betriebsbedingungen und stellen Fragen wie:

• Wer startet den Workflow?
• Welche Systeme sind beteiligt?
• Was kann der Agent ändern?
• Wo muss ein Mitarbeiter etwas genehmigen?
• Wie wird eine fehlgeschlagene Aufgabe wiederhergestellt?

Wer besitzt den Agenten nach dem Launch?

Derartige Fragen sind weniger spannend als eine Live-Demo, doch sie stehen viel näher an der Arbeit, die darüber entscheidet, ob ein Agent in der Produktion überlebt.

Beginnen Sie mit dem Workflow

Bessere Anbieter gehen vom Auftrag aus und nicht vom Modell. Die Anfrage nach einem Verkaufsagenten ist zu vage, um darauf aufzubauen, während ein spezifischer Ablauf leicht nachvollziehbar ist: Neue Kontakte prüfen, das Konto abrufen, einen Nachfassungsentwurf erstellen, Genehmigung einholen, das CRM aktualisieren. Er weist einen Auslöser, geordnete Schritte sowie ein für alle sichtbares Ergebnis auf.

Bevor mit der Entwicklung begonnen wird, sollte das Team Folgendes klargestellt haben.

• Den Auslöser, der den Workflow startet.
• Die Informationen, die der Workflow benötigt.
• Die Systeme, mit denen er verbunden ist.
• Die Stellen, an denen Entscheidungen getroffen werden.
• Die zulässigen Aktionen.
• Die erforderlichen Genehmigungen.
• Die Bedingungen, die als Misserfolg gelten.
• Die Kriterien für die Erfüllung.

In dieser Phase wird auch angezeigt, ob überhaupt ein Agent benötigt wird. Einige Aufgaben eignen sich besser für feste Automatisierungen, während andere eine Abfrage sowie menschliche Überprüfung erfordern. Ein Anbieter, der die einfachere Option empfiehlt, obwohl ein offenes Agentenverhalten nur wenig Wert schafft, gibt damit ein nützliches Signal für Ehrlichkeit.

Integrationen sind wichtiger als das Chat-Fenster

Demos legen den Fokus auf die Benutzeroberfläche, weil sie leicht zu zeigen ist, doch die Integrationsschicht erfordert den eigentlichen Aufwand. Ein Agent kann beispielsweise ein Kundenkonto einsehen, eine Police abrufen, ein Ticket aktualisieren, den Lagerbestand überprüfen, einen Bericht erstellen oder eine genehmigte Nachricht senden – jeder Schritt setzt voraus, dass ein bestimmtes Geschäftssystem wie erwartet funktioniert.

Reale Systeme sind unkooperativ. Anmeldeinformationen verfallen, APIs verlangsamen sich, Datensätze verschwinden, zwei Anwendungen liefern unterschiedliche Daten, und eine Anfrage kann erfolgreich sein, ohne dass die Bestätigung jemals beim Agenten ankommt. Zuverlässigere Anbieter planen bereits vor dem Launch darauf vor und berücksichtigen:

• Authentifizierung und Speicherung von Anmeldeinformationen,
• Rechtkontrollen,
• Zeitlimits für Anfragen,
• sichere Wiederholungsversuche,
• Verhinderung doppelter Aktionen,
• teilweises Abschließen einer Aufgabe,
• Protokollierung von Aktivitäten,
• manuelle Wiederherstellung.

Eine gut durchdachte Kommunikation kann eine unzuverlässige Integration nicht ausgleichen. Sobald ein Agent mit der Änderung von Datensätzen oder Auslösung von Aktionen beginnt, gehört die Qualität dieser Verbindungen zum Produkt selbst.

Rechte zeigen, wie mit Risiken umgegangen wird

Rechte bilden eine der deutlichsten Trennlinien zwischen Teams, die sich auf Prototypen konzentrieren, und solchen, die auf die Produktion ausgerichtet sind. Ein Prototyp läuft oft unter einem Entwicklerkonto mit umfassendem Zugriff. Das beschleunigt die Erstellung der ersten Version, wirft aber eine entscheidende Frage auf: Welche Aktionen darf der Agent ausführen?

Ein Support-Agent muss möglicherweise eine Bestellung einsehen und eine Antwort entwerfen. Er benötigt vermutlich nicht alle finanziellen Unterlagen oder die Möglichkeit, große Rückerstattungen auszustellen. Ein kompetenter Anbieter sollte Folgendes definieren:

• wer den Agenten starten darf,
• welche Informationen er abrufen darf,
• welche Tools er verwenden darf,
• welche Datensätze er ändern darf,
• welche Aktionen eine Genehmigung erfordern,
• unter welchen Bedingungen der Arbeitsablauf gestoppt werden muss.

Diese Beschränkungen gehören zum Betriebsablauf. Ein in einer anderen Datei gespeichertes Richtliniedokument kann einen Agenten nicht daran hindern, eine Aktion auszuführen, die ihm technisch erlaubt ist.

Verlässliche Informationen

Viele Geschäftsagenten stützen sich auf interne Dokumente wie Handbücher, Verträge, frühere Tickets, Verfahren, Richtlinien und Kundenakten. Doch die Verwendung dieser Dokumente macht die Antworten noch nicht zuverlässig. Fragen nach der Zugehörigkeit, Aktualität und Konfliktregeln bleiben weiterhin offen: Welche Version eines Dokuments gilt, wer kümmert sich darum, und was tut der Agent, wenn zwei Quellen miteinander im Widerspruch stehen.

Durch die Abfrage einer umfangreichen internen Sammlung kann ein Agent relevante Passagen heranziehen, bevor er antwortet oder den nächsten Schritt wählt. Die Qualität ist dabei entscheidend, denn selbst eine selbstbewusst formulierte Antwort kann auf dem falschen Dokument beruhen. Prüfer profitieren außerdem davon, zu sehen, was der Agent gelesen hat: Wenn er etwas Entscheidendes vorschlägt, sollte die Überprüfende Person das Material hinter dem Vorschlag einsehen können.

Mehrere Agenten sind nicht immer besser

Mehre-Agenten-Systeme klingen beeindruckend, sind aber oft überflüssig. Ein Agent reicht aus, wenn ein Workflow nur wenige Werkzeuge verwendet und einer überschaubaren Abfolge folgt. Mehr Agenten führen zu zusätzlicher Kommunikation, mehr Zuständen und höherem Risiko, dass etwas schiefgeht.

Mehrere Agenten sind sinnvoll, wenn die Aufgaben tatsächlich getrennte Rollen haben, zum Beispiel:

• ein Agent sammelt Informationen,
• ein anderer überprüft die Richtlinienanforderungen,
• ein dritter bereitet die vorgeschlagene Aktion vor,
• eine Person genehmigt den letzten Schritt.

Die wichtige Frage ist nicht, ob ein Anbieter ein Mehr-Agenten-System bauen kann, sondern ob die zusätzliche Struktur das Ergebnis verbessert. Ein zuverlässiger Anbieter kann erklären, warum jeder Agent existiert, was er erhält, wie die Arbeit zwischen den Agenten weitergeleitet wird und was passiert, wenn sie sich nicht einigen.

Fehlerbehandlung

Demos verlaufen meist reibungslos, während die Produktivumgebung selten so funktioniert – daher sollte ein Anbieter in der Lage sein, mit unübersichtlichen Eingaben umzugehen. Ein nützlicher Testplan stellt dem Agenten schwierige Situationen vor und überprüft das Ergebnis:

• eine Anfrage mit fehlenden Details,
• eine Abfrage, die nichts zurückgibt,
• Politiken, die miteinander im Widerspruch stehen,
• eine nachgelagerte Anwendung, die nicht mehr reagiert,
• ein Benutzer, der nach etwas fragt, das nicht erlaubt ist,
• eine Toolaufruf, der an das falsche Ziel gerichtet ist,
• eine doppelte Einreichung derselben Anfrage,
• eine Aufgabe, die nicht sicher abgeschlossen werden kann.

Es ist nicht das Ziel, jeden Fall zu lösen. Oft ist das richtige Vorgehen, abzubrechen, eine klärende Frage zu stellen, eine begrenzte Anzahl von Malen erneut zu versuchen oder den Fall an einen Menschen weiterzuleiten. Zuverlässigkeit bedeutet auch, zu erkennen, wann es ein Fehler wäre, weiterzumachen.

Deployment ist mehr als Hosting

Hosting ist der kleinste Bestandteil einer Bereitstellungsplattform. Sobald Mitarbeiter auf einen Agenten angewiesen sind, müssen die Betreuer sein Verhalten überwachen und Ausfälle erklären. Dafür sind Protokolle von Tool-Aufrufen, heruntergeladenem Material, Workflow-Schritten, Genehmigungsergebnissen, Fehlern, Wiederholungsversuchen, Latenzzeiten, Kosten sowie Übertragungen an Personen erforderlich.

Ohne ein solches Protokoll sieht ein Team nur, dass die Endausgabe falsch war, und kann nicht feststellen, ob das Modell, die Daten, der Connector oder die Anweisungen schuld waren. Versionierung und Rollback schließen diesen Kreislauf. Da Modelle, Anfragen, Datenquellen und Geschäftsregeln ständig ändern, muss es möglich sein, herauszufinden, welche Konfiguration ein bestimmtes Ergebnis erzeugt hat, und nach einem fehlerhaften Update auf eine funktionierende Konfiguration zurückzukehren.

Menschliche Überprüfung, die der Schwere des Problems entspricht

Die Erforderlichkeit einer Genehmigung für jede Aktion eines Agents hat nur geringen Wert und kann ein nützliches System in eine langsamere Kopie des alten Prozesses verwandeln. Die vollständige Abschaffung der menschlichen Überprüfung führt zum gegenteiligen Problem. Der vernünftige Ansatz besteht darin, die Genehmigung dort einzuführen, wo Konsequenzen entstehen. Ein Agent kann eine Anfrage klassifizieren, Informationen organisieren oder eigenständig einen Entwurf verfassen, während Zahlungen, Vertragsänderungen, Kontosperrungen oder rechtlich bedeutsame Nachrichten außerhalb des Unternehmens möglicherweise weiterhin die Zustimmung eines autorisierten Mitarbeiters erfordern.

Auch Überprüfer benötigen Kontext. Ein „Genehmigen“-Button ist nutzlos, wenn die Person die Quellinformationen, die vorgeschlagene Aktion, das betroffene Dokument sowie den Grund dafür nicht sehen kann, warum der Fall bei ihr ankommt. Bei sensiblen Arbeitsabläufen sollten Verwaltungspraktiken Berechtigungen, Genehmigungen, Überwachung, Verantwortlichkeiten und die Handhabung von Vorfällen mit dem täglichen Betrieb verknüpfen.

Verantwortlichkeiten nach dem Start

Ein weiterer Unterschied zeigt sich, wenn es um die Implementierung geht. Einige Anbieter betrachten den Start als Ziel, während stärkere Teams auch die Wochen und Monate danach besprechen. Die Umgebung eines Agenten ändert sich ständig: Anleitungen werden überarbeitet, APIs ausgetauscht, das Personal findet unerwartete Wege, den Workflow zu nutzen, und es tauchen Anfragearten auf, die in der ursprünglichen Testphase nie berücksichtigt wurden.

Mehrere Aufgaben benötigen einen Verantwortlichen: die Überwachung der Leistung, die Untersuchung fehlgeschlagener Aufgaben, das Aktualisieren des Wissens, die Freigabe von Änderungen am Workflow, die Erfassung der Ausgaben, die Reaktion auf Vorfälle sowie die Entscheidung, wann der Agent abgeschaltet werden soll. Ein Lieferant kann weiterhin technischen Support anbieten, doch eine benannte Person innerhalb des Unternehmens muss die Verantwortung tragen. Andernfalls häufen sich kleine Fehler, bis das Personal dem System nicht mehr vertraut.

Fragen, die vor der Auswahl gestellt werden sollten

Die Präsentation sollte weniger wichtig sein als die Antworten auf einige präzise gestellte Fragen.

• Wie plant der Anbieter die Abbildung des bestehenden Workflows – und warum ist ein Agent erforderlich?
• Welche Systeme werden beeinflusst, und wie werden die Benutzerrechte an diese weitergegeben?
• Was verhindert, dass dieselbe Aktion zweimal ausgeführt wird – und was passiert, wenn ein Tool ausfällt?
• Wo muss ein Mensch zustimmen?
• Wie wird die Wissensdatenbank auf dem neuesten Stand gehalten?
• Wie wird die Leistung in Echtzeit gemessen – und wer kümmert sich um den Support, sobald das System läuft?
• Kann jede Änderung nachverfolgt und rückgängig gemacht werden?

Ein guter Anbieter antwortet in einfachen Worten und verknüpft jede technische Entscheidung mit dem vorgeschlagenen Workflow.

Der Kernpunkt

Gute Teams streben nicht nach dem Anschein vollständiger Unabhängigkeit. Sie entwickeln ein System, das innerhalb definer Grenzen nützliche Arbeit erledigt – mit einem klaren Arbeitsablauf, zuverlässigen Integrationen, kontrolliertem Zugriff, vertrauenswürdigen Kenntnissen, realistischen Fehlertests, menschlicher Überprüfung, Überwachung sowie Verantwortung nach dem Launch. Eine beeindruckende Demo ist eine gute Möglichkeit, ein Gespräch zu beginnen, aber keine solide Grundlage für die endgültige Entscheidung.