SignalDas Anliegen verstehen
Architektur von KI-Agenten
Warum ein Tool-Aufruf noch keine Automatisierung ist
Eine Integration wird erst nützlich, wenn der Agent weiß, wann er sie aufruft, was er ändern darf, wie er das Ergebnis bestätigt und wer für einen Fehler zuständig ist.
BETRIEBSLEITFADENPRÜFBARER ABLAUF
Leitfaden für den Betrieb
AblaufDie passende Regel anwenden
ErgebnisDen nächsten Schritt zurückschreiben
„Der Agent kann unser CRM aufrufen“ klingt nach einem Meilenstein. Das ist es nicht. Eine Tool-Anbindung sagt dem System, dass es eine API gibt. Sie legt weder die geschäftliche Entscheidung fest noch die Grenze der Berechtigung, die nötigen Argumente, die Formulierung der Bestätigung oder den Weg zur Behebung, wenn die API zu spät oder falsch antwortet. In der Voice-KI kann eine beeindruckende Demo diese Lücke verdecken, weil der Idealablauf endet, bevor die betrieblichen Folgen beginnen.
Die Plattform von DRING und die Agent Factory, in der wir Agenten bauen, testen und verbessern, setzen bei der größeren Frage an: Was soll passieren, nachdem der Anrufer gesprochen hat? Ein Tool-Aufruf ist ein Schritt in einem kontrollierten Workflow. Das Ergebnis muss sichtbar, prüfbar und nützlich für das Team sein, das für die Arbeit zuständig ist.
Mit dem geschäftlichen Ergebnis beginnen
Beginnen Sie nicht mit einer Liste von Integrationen. Beginnen Sie mit einem Ergebnis, das Kunde und Team wiedererkennen: Retoure beantragt, Termin gebucht, Angebotsanfrage angelegt, Sendungsausnahme zugewiesen, Zahlungsstatus erklärt oder menschliche Prüfung eröffnet. Legen Sie dann fest, welche Fakten nötig sind, welche Richtlinie die Aktion erlaubt, wer zuständig ist und welcher Nachweis die Erledigung belegt.
So vermeiden Sie einen häufigen Fehler: ein Allzweck-Tool, das viele Felder ohne klaren Grund schreiben kann. Eine eng gefasste Aktion wie „freigegebenen Rückruf einplanen“ lässt sich leichter absichern und testen als eine breite Operation „Kunde aktualisieren“. Name, Beschreibung und Argumente sollten die vorgesehene Aufgabe für das Modell und für die prüfende Person offensichtlich machen.
Daten-Tools von Aktions-Tools trennen
Daten-Tools lesen. Aktions-Tools ändern einen Zustand. Eine CRM-Abfrage, eine Abfrage des Bestellstatus oder der Abruf von Wissen können rein lesend sein. Eine Erstattung auslösen, einen Termin absagen, eine Zahlungsart ändern oder einen Vorgang zuweisen hat dagegen Folgen. Trennen Sie beides in Architektur, Berechtigungen und Bewertungsbogen.
Der Leitfaden A practical guide to building agents von OpenAI beschreibt diese Unterscheidung, weil sie Mehrdeutigkeit verringert. Der Agent kann eine Statusfrage oft automatisch beantworten, während eine zustandsändernde Aktion eine Bestätigung oder einen Menschen verlangt. Der Anrufer muss das Tool-Modell nicht verstehen, das Unternehmen aber schon.
Vorbedingungen und Prüfung der Argumente festlegen
Jede Aktion braucht Vorbedingungen. Um ein Treffen zu buchen, braucht der Agent womöglich einen geprüften Kontakt, eine vereinbarte Zeitzone, einen gewählten Termin und die Einwilligung zur Terminierung. Um eine Lieferausnahme anzulegen, braucht er vielleicht die Sendungsreferenz und eine unterstützte Kategorie. Um einen sicheren Link zu senden, braucht er womöglich den richtigen Kanal und den passenden Stand der Identitätsprüfung.
Prüfen Sie Werte, bevor das Tool aufgerufen wird. Datumsangaben, Rufnummern, Währungen, Orte und Kennungen sollten normalisiert und bestätigt werden, wenn Fehler ins Gewicht fallen. Fehlt ein Pflichtfeld, stellt der Agent eine gezielte Frage. Ist der Anrufer unsicher, bleibt die Unsicherheit im Datensatz, statt dass ein Wert erfunden wird.
Die Aktion im richtigen Moment bestätigen
Die Bestätigung sollte zur Umkehrbarkeit und zur Erwartung des Kunden passen. Eine risikoarme Nachricht braucht vielleicht nur einen knappen Hinweis. Eine Buchung oder Absage sollte je nach Richtlinie vor oder nach der Aktion klar bestätigt werden. Eine Zahlung oder Kontoänderung verlangt womöglich einen sicheren, authentifizierten Schritt. Fragen Sie nicht so oft nach einer Bestätigung, dass der Agent unbrauchbar wird. Verstecken Sie eine folgenreiche Aktion aber auch nicht in einem langen Satz.
Arbeiten Sie mit einem zweiteiligen Sprachmuster: was passieren wird und was passiert ist. Erst: „Ich kann Ihnen den Rückruf am Dienstag um 15 Uhr eintragen. Soll ich das machen?“ Danach: „Ihr Rückruf mit unserem Serviceteam ist für Dienstag um 15 Uhr eingetragen.“ So kann der Kunde die Aktion noch korrigieren und bekommt ein klares Ergebnis.
Tool-Fehler als Normalzustand einplanen
APIs laufen in Timeouts, Kalender ändern sich, Datensätze widersprechen sich, und Anbieter liefern unvollständige Ergebnisse. Ein robuster Agent behauptet keinen Abschluss, wenn das Tool ihn nicht bestätigt. Er erklärt die Einschränkung, bewahrt die Anfrage auf und leitet eine Aufgabe an eine zuständige Person. Ein neuer Versuch muss sicher und idempotent sein. Sonst erzeugt ein wiederholter Tool-Aufruf doppelte Buchungen, Erstattungen oder Nachrichten.
Speichern Sie Tool-Name, die Argumente, die gespeichert werden dürfen, Ergebnis, Zeitstempel, Fehlerart und nächsten Schritt. Die Formulierung für den Kunden sollte einfach sein, der interne Datensatz so genau, dass Betrieb und Entwicklung den Fehler untersuchen können.
Die zuständige Person im Ablauf halten
Automatisierung hebt Zuständigkeit nicht auf. Jemand muss für eine Ausnahme, eine gescheiterte Aktion, einen unsicheren Datensatz und einen Kunden zuständig sein, der einen Menschen verlangt. Das Modell für die Übergabe an Menschen sollte das beabsichtigte Ergebnis, die erfassten Fakten, die versuchte Aktion, deren Ergebnis und die Erwartung des Kunden übergeben.
Machen Sie die Zuständigkeit im CRM sichtbar. „Tool fehlgeschlagen“ ist keine Zuständigkeit. „Abrechnungsteam prüft den Erstattungsstatus bis 16 Uhr“ ist eine. Ein Workflow ohne Zuständigkeit ist nur eine unbeantwortete Frage auf einem anderen Bildschirm.
Erledigung messen statt Aufrufe
Die Zahl der Tool-Aufrufe sieht gut aus, sagt aber wenig. Verfolgen Sie erfolgreiche Ergebnisse, Quote korrekter Aktionen, Quote doppelter Aktionen, menschliche Nacharbeit, Alter offener Ausnahmen, Wiederholungskontakte und Bestätigung durch den Kunden. Prüfen Sie Vorgänge, bei denen das Tool Erfolg meldete und der Kunde sich trotzdem wieder an den Support wandte. Das kann eine Lücke in Richtlinie, Daten oder Kommunikation zeigen.
Vergleichen Sie Ergebnisse mit den Analysen und der monatlichen Branchenanalyse nach Workflow, Tool-Version, Sprache und Agent. Eine hohe Fehlerquote in einer Sprache kann an der Extraktion von Argumenten oder an der Terminologie liegen. Eine hohe Quote an Wiederholungskontakten nach einer bestimmten Aktion kann bedeuten, dass die Aktion den internen Zustand bereinigt hat, aber nicht die eigentliche Frage des Kunden.
Die gesamte Aktionskette testen
Erstellen Sie für jedes Tool Tests für fehlende Argumente, mehrdeutige Werte, Korrekturen durch den Anrufer, doppelte Anfragen, Timeouts, unvollständige Antworten, verweigerte Berechtigungen, veraltete Daten und den Wunsch nach einem Menschen. Ergänzen Sie Hintergrundgeräusche, Unterbrechungen und Sprachwechsel. Bewerten Sie Gespräch und Systemzustand gemeinsam. Eine flüssige Antwort mit dem falschen CRM-Update ist ein Fehler.
Die Agent Factory kann 1.000 bis 10.000 simulierte Gespräche durchführen und Release-Kandidaten mit derselben Suite aus Tools und Richtlinien vergleichen. Rückmeldungen aus echten Anrufen sollten neue Testfälle erzeugen. Änderungen im Produktivbetrieb bleiben gestuft und für das Team des Kunden sichtbar.
Checkliste für das Design von Tool-Aufrufen
- Mit einem messbaren Ergebnis für Kunde und Unternehmen beginnen.
- Rein lesende Daten-Tools von zustandsändernden Aktionen trennen.
- Vorbedingungen, Berechtigungen, Pflichtfelder und Prüfung festlegen.
- Folgenreiche Aktionen in klarer Sprache bestätigen.
- Wege für Timeout, Konflikt, neuen Versuch und unvollständiges Ergebnis ausdrücklich festlegen.
- Jeder Ausnahme eine zuständige Person zuweisen.
- Erledigte Ergebnisse, doppelte Aktionen und Nacharbeit messen.
Tool-Aufrufe sind die Verkabelung, nicht das Produkt. Das Produkt ist ein verlässlicher Workflow, der die Anfrage versteht, den erlaubten Schritt ausführt, wahrheitsgemäß sagt, was passiert ist, und dem nächsten Team einen brauchbaren Datensatz hinterlässt. Gilt dieser Maßstab, lassen sich Integrationen leichter auswählen, und Agenten verdienen leichter Vertrauen.
Weiterführende Quellen
Aus einer Integration einen echten Workflow machen
Bringen Sie eine Aktion mit, die Ihr Team automatisieren möchte. Wir skizzieren Berechtigungen, Bestätigungen und Fehlerwege dafür.