Agentische Workflows, die nicht kaputtgehen: Tool-Calling, Human-in-the-Loop und die Nähte zwischen Systemen

Geschäftsprozessautomatisierung und ein KI-Agent werden als dasselbe verkauft, sind es aber nicht. Automatisierung ist eine feste Pipeline: Schritt zwei folgt immer auf Schritt eins, auf dieselbe Weise. Ein Agent ist eine Schleife, in der das Modell entscheidet, welcher Schritt als Nächstes kommt, basierend darauf, was ein Tool-Aufruf gerade zurückgegeben hat. Beides hat seinen Platz - das meiste, was ein Unternehmen wirklich braucht, ist Automatisierung mit ein oder zwei agentischen Entscheidungspunkten, kein Agent, der jede Entscheidung trifft.

Die Architektur darunter entscheidet in beiden Fällen, ob es den Kontakt mit echten Daten übersteht: wie Sie dem Modell Kontext zuführen, wie Sie eine Antwort in einer Form zurückbekommen, der Ihr Code vertrauen kann, wie das Modell in andere Systeme hineingreift, und wo ein Mensch immer noch ja sagen muss. Diese Verkabelung, nicht die Modellwahl, ist das, womit ich die meiste Projektzeit verbringe.

1. Context Engineering: dem Modell den richtigen Ausschnitt geben, nicht alles

Context Engineering ist die unglamouröse Arbeit, zu entscheiden, was das Modell bei einem gegebenen Aufruf sieht - welche Datensätze, welche vorherigen Runden, welche Anweisungen - und, genauso wichtig, was es nicht sieht. Jedes Mal die gesamte Kundenhistorie oder ein komplettes Dokument in den Prompt zu kippen, ist keine Gründlichkeit; es ist Rauschen, das die eigentliche Frage weiter aus der Aufmerksamkeit des Modells drängt und leise die Kosten jedes Aufrufs aufbläht.

Das Muster, das trägt, ähnelt eher einem Suchproblem als einem Gedächtnisproblem: die zwei oder drei für diesen konkreten Schritt relevanten Datensätze abrufen, zusammenfassen, was vorher war, statt es wörtlich zu wiederholen, und dem Agenten erlauben, nur bei Bedarf nach mehr zu fragen. Ein Workflow, der zuverlässig die richtigen fünf Zeilen aus zehntausend zieht, schlägt einen, der alle zehntausend hineinstopft und hofft.

2. Strukturierte Ausgaben und Tool-/Function-Calling sind die eigentliche Schnittstelle

Ein Modell, das in Freitext antwortet und mit einem Regex geparst wird, ist die Stelle, an der diese Builds in der Produktion still versagen. Strukturierte Ausgaben - ein JSON Schema, innerhalb dessen das Modell antworten muss - und Tool-/Function-Calling - das Modell fordert eine bestimmte Funktion mit typisierten Argumenten an, statt eine Aktion in Prosa zu beschreiben - lassen Ihren Code einer Antwort genug vertrauen, um zu handeln, ohne dass ein Mensch jede Ausgabe erneut liest.

Ich validiere das Schema beim Verlassen des Modells und noch einmal, bevor es ein echtes System erreicht, denn ein Modell kann syntaktisch gültiges JSON produzieren, das für die geschäftliche Regel trotzdem falsch ist - eine negative Menge, ein Datum in der Vergangenheit, eine Währung, die das Konto nicht unterstützt. Das Schema fängt Formfehler; eine zweite, langweilige Validierungsschicht fängt die, die gültiges JSON sind und trotzdem falsch.

3. Embeddings und eine Vektordatenbank - nur wenn Suche wirklich die Aufgabe ist

Embeddings und eine Vektordatenbank verdienen sich ihren Platz, wenn die Aufgabe wirklich Retrieval ist: die drei Support-Tickets finden, die diesem neuen am nächsten sind, die Klausel in einem Vertrag finden, die dieser Frage am nächsten ist. Sie sind das falsche Werkzeug für eine feste, kleine Menge von Datensätzen, die eine normale Datenbankabfrage bereits beantwortet - ich habe eine Vektordatenbank an einen Workflow mit elf möglichen Kategorien geschraubt gesehen, wo eine Lookup-Tabelle schneller, billiger und leichter zu debuggen gewesen wäre.

Wenn es das richtige Werkzeug ist, braucht nicht das Embedding-Modell die eigentliche Sorgfalt - sondern was wie gechunkt wird und wie frisch der Index bleibt, nachdem sich das Quelldokument ändert. Eine Vektorsuche über veraltete Chunks liefert eine selbstsichere, falsche Antwort, und nichts in der Ausgabe des Agenten sagt Ihnen, dass es passiert ist.

4. Human-in-the-Loop und API-Orchestrierung: wo es wirklich kaputtgeht

Der Fehler, den ich am häufigsten sehe, ist nicht schlechtes Modell-Reasoning - es ist die Naht zwischen zwei Systemen: ein API-Aufruf, der ein Timeout hat, und der Agent wiederholt ihn zweimal und sendet eine doppelte Bestellung; ein Webhook, der feuert, bevor der vorherige Schritt fertig geschrieben hat; ein Tool-Aufruf, der auf der Anbieterseite gelingt, aber die Antwort, die der Agent erhält, meldet einen Fehlschlag. Aufrufe über CRM, Abrechnung und E-Mail hinweg zu orchestrieren bedeutet, zu entscheiden, was bei einem Timeout oder einem Teilausfall passiert, bevor es in der Produktion passiert, nicht danach.

Alles, was Geld sendet, einen Datensatz löscht oder einem Kunden eine E-Mail schickt, bekommt einen menschlichen Bestätigungsschritt, bevor es feuert - nicht weil das Modell generell unzuverlässig ist, sondern weil die Kosten einer falschen automatischen Aktion asymmetrisch zu den Kosten eines zusätzlichen Klicks sind. Lieber lässt eine Person zwanzig richtige Aktionen am Tag freigeben, als dass der Agent automatisch eine falsche Rechnung verschickt.

Fazit: der Agent ist die einfachen 10%

Ein Modell auszuwählen und den ersten Prompt zu schreiben, ist wirklich der einfache Teil eines agentischen Workflows. Der Kontext, der eingespeist wird, das Schema, das validiert wird, die Vektorsuche, die nur läuft, wenn sie soll, die Retry-Logik über drei APIs hinweg, und der eine Schritt, den weiterhin ein Mensch freigibt - das sind die anderen 90%, und sie entscheiden, ob die Automatisierung an einem Dienstag in sechs Monaten mit Daten, die niemand getestet hat, noch funktioniert. Schreiben Sie über das Formular, welchen Prozess Sie automatisiert haben möchten, und ich sage Ihnen, welche 10% der Agent sind und welche 90% tatsächlich gebaut werden müssen.