Mehrstufiger KI-Agent: Planung, Ausführung, Verifizierung

Im Lager eines Produktionsunternehmens durchlief eine Bestellung fehlender Komponenten vier Systeme und drei Personen. Jede von ihnen führte ein Schema aus: Status prüfen, Schwellenwert bewerten, in ERP eintragen, E-Mail senden. Ein wiederholbares Schema, keine kreativen Entscheidungen. Ein mehrstufiger KI-Agent übernahm diesen Prozess innerhalb von sechs Pilotwochen. Nicht, weil er „intelligenter“ war als das Team, sondern weil es präzises Design der Schleife erforderte – kein fertiges SaaS-Produkt.

Genau das ist der Kern mehrstufiger Agenten: keine Magie, sondern Architektur.

Ein mehrstufiger Agent unterscheidet sich von einem Chatbot durch drei strukturelle Eigenschaften, nicht durch den Grad der „Intelligenz“:

Planung. Der Agent beantwortet keine Frage – er generiert einen Plan aus Schritten, der zum Ziel führt. Der Plan kann statisch (immer dieselben Schritte für einen bestimmten Aufgabentyp) oder dynamisch (das Modell entscheidet selbst über die nächsten Schritte basierend auf vorherigen Ergebnissen) sein. Dynamische Planung ist flexibler, aber schwerer zu auditieren.

Handlungsfähigkeit durch Tools. Der Agent greift auf Tools (Tool-Use) zu: liest aus der Datenbank, schreibt einen Datensatz, sendet eine HTTP-Anfrage, ruft eine Funktion auf. Jedes Tool ist ein definierter Interface mit begrenztem Umfang. Ein Agent, der nur Lesezugriff auf das CRM und Schreibzugriff auf die E-Mail-Warteschlange hat, kann nicht versehentlich Kundendaten überschreiben.

Verifizierungsschleife. Nach jedem Schritt überprüft der Agent das Ergebnis: ob die API Erfolg zurückgegeben hat, ob der Datensatz den erwarteten Zustand hat, ob der nächste Schritt überhaupt notwendig ist. Fehlt diese Schleife, ist der Agent einer, der „schießt“ und annimmt, getroffen zu haben. In einer Produktionsumgebung führt das zu stillen Fehlern.

Die meisten ausgereiften mehrstufigen Agenten implementieren eine Variante der ReAct-Schleife (Reason + Act): Das Modell generiert eine Begründung für den nächsten Schritt, führt ihn über ein Tool aus, beobachtet das Ergebnis und entscheidet über den nächsten Schritt. Die Schleife läuft, bis die Endbedingung erfüllt ist oder die maximale Schrittzahl erreicht wird.

Ziel → Plan → [Schritt → Verifizierung → Entscheidung]* → Endergebnis
                       ↕
              Human-Gate (für irreversible Schritte)

Praktische Konsequenzen dieser Architektur:

• Schrittlimit ist Pflicht. Ein Agent ohne Limit kann bei unerwartetem Tool-Ergebnis in eine Endlosschleife geraten. Setze ein hartes Limit (z. B. 20 Schritte für typische B2B-Prozesse) und behandle Überschreitungen als Eskalation zum Menschen.
• Zwischenzustand muss gespeichert werden. Bei langen Aufgaben (mehrere Minuten) landet der Zustand nach jedem Schritt in einem Speicher (Redis, Datenbank), nicht nur im Sitzungsspeicher. Ein Ausfall mitten im Prozess sollte die bisherige Arbeit nicht löschen.
• Jeder Schritt ist identifizierbar. Das Log enthält: Tool, Eingabeargumente, Ergebnis, Timestamp. Das ist die Grundlage für die Konformität mit dem AI Act und die Auditierbarkeit bei DPIA.

Tools sind ein standardisiertes Interface zwischen Modell und externen Systemen. Jedes Tool hat: einen Namen, eine Beschreibung (das Modell liest sie bei der Planung), ein Eingabeschema und ein erwartetes Ausgabeschema. Ein gut gestaltetes Tool ist atomar: Es macht eine Sache, gibt ein klares Erfolgs- oder Fehlerergebnis zurück.

Prinzip der minimalen Berechtigungen: Der Agent erhält nur die Tools, die er für die jeweilige Aufgabe benötigt. Ein Agent zur Auftragsabwicklung braucht keinen Zugriff auf das Tool zum Versenden von Angeboten. Isolation ist sowohl eine Frage der Sicherheit als auch der Planungsqualität — ein Modell mit kleinerem Toolset trifft bessere Entscheidungen.

Der Standard MCP (Model Context Protocol) standardisiert die Registrierung von Tools und deren Schemata, was die Wiederverwendung derselben Toolsets zwischen verschiedenen Agenten ermöglicht.

Guardrails sind Bedingungen, die vor der Ausführung jedes Schritts überprüft werden. Ihre Aufgabe ist es, Situationen zu erkennen, in denen der Agent etwas außerhalb seines Bereichs, potenziell Schädliches oder Irreversibles tun will.

Vier Guardrail-Ebenen für einen mehrstufigen Agenten:

1. Planvalidierung — Passt jeder Schritt im generierten Plan in den erlaubten Tool-Bereich? Ein Schritt, der auf ein Tool außerhalb der Allow-Liste verweist, wird vor der Ausführung blockiert.
2. Argumentvalidierung — Sind die an das Tool übergebenen Argumente im zulässigen Bereich? Ein Agent, der versucht, eine E-Mail an einen Empfänger außerhalb der Unternehmensdomäne zu senden, erhält einen Fehler und fährt nicht fort.
3. Human-Gate für irreversible Aktionen — Löschen eines Datensatzes, Senden einer externen Nachricht, Bestätigung einer Zahlung. Der Agent stoppt und wartet auf die explizite Genehmigung eines Operators. Die Genehmigung wird mit Timestamp und Benutzer-ID protokolliert.
4. Injection-Screening — Inhalte aus externen Quellen (Kunden-E-Mails, Dokumente, Formulare) werden vor der Übergabe an das Modell gescannt. Prompt-Injection über Eingabedaten ist ein realer Angriffsvektor für Agenten mit Tool-Zugriff.

Human-Gate ist kein Luxus für „sensible“ Prozesse. Es ist eine architektonische Anforderung für jeden Agenten mit Zugriff auf Tools zum Schreiben oder Ausführen von Aktionen. Ein detailliertes Design von Human-Gate beschreibt der Artikel über die Rolle des Menschen in der Agentenschleife.

Ein mehrstufiger Agent muss einen präzise gestalteten Fehlerpfad haben. Drei Szenarien erfordern separate Verfahren:

Tool-Fehler (z. B. API-Timeout, Fehler 500). Der Agent wiederholt den Schritt mit Backoff — maximal 2-3 Versuche, dann Eskalation zur menschlichen Warteschlange mit vollem Zustandslog. Er wiederholt nicht endlos.

Unerwartetes Ergebnis — Das Tool hat etwas zurückgegeben, das der Agent im Kontext des Plans nicht interpretieren kann (z. B. hat das Statusfeld einen Wert außerhalb des erwarteten Bereichs). Der Agent rät nicht — er stoppt und eskaliert mit Kontext: „In Schritt 4 beträgt der Bestellstatus X, der Plan sah Y oder Z vor.“

Überschreitung des Schrittlimits — Der Agent hat innerhalb der erlaubten Schrittzahl keinen Weg zum Ziel gefunden. Eskalation mit vollem Zwischenzustand, damit der Operator eine Entscheidung treffen kann, ohne von vorne beginnen zu müssen.

Gute Eskalation ist kein Systemversagen. Es ist ein gestaltetes Handoff an den Menschen mit Kontext, der die Entscheidungszeit von Minuten auf Sekunden verkürzt.

Ein mehrstufiger Agent verarbeitet Daten, die oft PII enthalten. Jedes Tool, das personenbezogene Daten empfängt oder zurückgibt, durchläuft vor der Übergabe an das Modell einen Maskierungsrouter. Das Modell sieht niemals eine rohe PESEL-Nummer, Kontonummer oder E-Mail-Adresse — es sieht ein Ersatz-Token. Die Daten werden erst bei der Speicherung im Zielsystem nach der Verifizierung durch das Tool demaskiert.

Konsequenzen für das Design:

• Das Schritt-Log enthält keine PII. Es enthält eine Sitzungs-ID (anonymisiert), eine Datensatz-ID (z. B. order_id), das Tool-Ergebnis (Erfolg/Fehler). Der Inhalt des verarbeiteten Dokuments landet nicht im Betriebslog.
• Self-Hosting oder Daten-Residency. Für Agenten, die personenbezogene Daten polnischer Kunden verarbeiten, sollten die Daten ohne entsprechende Rechtsgrundlage nicht den EWR verlassen. Eigene LLM-Infrastruktur eliminiert dieses Problem. Optionen beschreibt der Artikel über lokale LLM-Modelle.
• AI Act und Transparenz. Ein mehrstufiger Agent, der mit Kunden interagiert, muss offenlegen, dass der Kunde mit einem automatisierten System zu tun hat. Das Log dieser Offenlegung wird Teil des Audit-Trails.
• DPIA bei hohem Risiko. Agenten, die Gesundheits-, Finanz- oder Personaldaten verarbeiten (AI Act Anhang III), erfordern vor der Produktionsfreigabe eine Datenschutz-Folgenabschätzung.

Die Implementierung eines sicheren mehrstufigen Agenten unter Einhaltung dieser Anforderungen beschreibt der Artikel AI Act und RODO 2026.

Ein typischer Zeitplan für die Implementierung eines mehrstufigen Agenten für einen Prozess in einem B2B-Unternehmen sieht wie folgt aus:

Shadow-Mode ist eine Pflichtphase für jeden neuen mehrstufigen Agenten. Der Agent verarbeitet dieselben Daten wie der Mensch, aber sein Ergebnis wird nicht angewendet — nur verglichen. Abweichungen zeigen Lücken im Tool-Design oder in der Planung, bevor etwas in die Produktion geht.

Das reale Budget für einen Pilot hängt von der Komplexität des Prozesses und der Anzahl der Integrationen ab. Einen Richtwert für die Projektkosten von KI findest du im ROI-Rechner. Eine Schätzung der Inference-Kosten (Tokens und Infrastruktur) liefert der Inference-Rechner.

Beschreibe den Prozess, den du agentenbasiert automatisieren möchtest, und das Modell entwirft eine vorläufige Architektur: Schritte, Tools, Human-Gate-Punkte und Guardrails. (Playground: PII maskiert, keine Speicherung):

n8n ist ein Workflow-Orchestrator — gut geeignet für bekannte, feste Schrittfolgen. Ein mehrstufiger Agent unterscheidet sich dadurch, dass das Modell den Schrittplan basierend auf Ziel und aktuellem Zustand generiert. Bei einem einfachen Prozess mit immer denselben Schritten ist n8n einfacher und günstiger. Bei einem Prozess, der Anpassungen erfordert (verschiedene Pfade je nach Schritt-Ergebnis, Ausnahmebehandlung), ist der mehrstufige Agent das richtige Werkzeug. In der Praxis werden beide oft kombiniert: n8n als externer Orchestrator, der Agent als Entscheidungsmodul für komplexe Teilaufgaben.

Das hängt von der Anzahl der Schritte und der Antwortzeit der Tools ab. Typische B2B-Prozesse (Datenprüfung, Dokumentvorbereitung, CRM-Aktualisierung) sind in 30 Sekunden bis 3 Minuten abgeschlossen. Prozesse, die auf externe Ereignisse warten (Kundenantwort, Zahlungsbestätigung), können Stunden oder Tage dauern — der Agent stoppt dann bis zum Eintreffen des Signals, blockiert aber keine Ressourcen. Der Zwischenzustand wird gespeichert, der Agent wird bei einem Ereignis wiederaufgenommen.

Ja, wenn keine Verifizierungsschleife und kein Monitoring vorhanden sind. Ein Agent kann einen Schritt technisch „korrekt“ ausführen (API gibt 200 zurück), aber mit einem falschen Geschäftsergebnis (z. B. Status auf einen Wert außerhalb des erwarteten Bereichs gesetzt). Schutz bietet die Kombination aus: Schema-Validierung der Tool-Ergebnisse, wöchentlichem Golden-Set-Test und Alarmierung bei Anomalien in den Ausgabedaten. Die Architektur des Monitorings beschreibt der Artikel über Monitoring und KPI von KI-Agenten.

Wenn der Prozess selten ist (unter 20 Wiederholungen pro Monat), auf jeder Stufe eine tiefe Expertenbewertung erfordert oder hochgradig nicht standardisiert ist. Ein mehrstufiger Agent lohnt sich dort, wo die Wiederholbarkeit hoch ist, die Schritte definierbar sind und das Ergebnis eines Schritts programmatisch verifiziert werden kann. Für kreative oder verhandlungsintensive Prozesse ist ein Assistent, der den Menschen unterstützt, besser geeignet als ein autonomer Agent. Eine Bewertung der Prozesseignung liefert der Automatisierungs-Finder.

Wir beginnen mit einer Prozess- und Datenprüfung (Inventar der Tools, PII-Schema, Schrittbeschreibung). Dann folgt der Pilot im Shadow-Mode: Der Agent arbeitet 2-3 Wochen parallel zum Team, Abweichungen werden analysiert. Anschließend die Phase mit Human-Gate: Der Agent ist autonom bei sicheren Schritten, irreversible Aktionen erfordern die Genehmigung eines Operators. Volle Autonomie erst nach Validierung einer Fehlerrate unter dem Akzeptanzschwellenwert. Kontaktaufnahme über Kontakt oder Bereitschaftsbewertung.