Warum wir ein workflow-gesteuertes Agentensystem für die Automatisierung im Recruiting entwickelt haben

Hinter vielen sogenannten „KI-Agenten" verbirgt sich mittlerweile ein recht standardisiertes Implementierungsmuster: Das Modell erhält Kontext, entscheidet, ob es ein Tool aufrufen soll, beobachtet das Ergebnis und wiederholt diesen Vorgang, bis die Aufgabe als abgeschlossen gilt. Das Agents SDK von OpenAI beschreibt dies explizit als Agent-Loop; Anthropic unterscheidet diese modellgesteuerten Systeme von Workflows, bei denen Ausführungspfade im Code vordefiniert sind.

Diese Unterscheidung ist für Produktivsysteme wichtig, denn „agentisch" und „autonom" sind keine Synonyme. Ein System kann LLM-basiertes Routing, Reasoning, Dekomposition und Synthese einsetzen und dennoch Kontrollfluss, Zustandsübergänge und Seiteneffekte außerhalb der modellgesteuerten Ausführung halten.

Das ist die Architektur, die wir für die Recruiting-Automatisierung gewählt haben.

Anstatt einen vollständig autonomen Agenten zu entwickeln, haben wir uns für ein workflow-gesteuertes Agentensystem entschieden: eine mehrstufige Architektur, in der spezialisierte LLM-Aufrufe begrenzte kognitive Aufgaben übernehmen, während Orchestrierung, Sequenzierung und Mutation des Systemzustands code-gesteuert bleiben. Dieses Design ähnelt eher dem, was das Berkeley AI Research als Compound-AI-System bezeichnet, als einem einzelnen autonomen Agenten.

Architekturübersicht

Unser Laufzeitsystem ist in drei Stufen gegliedert:

1. Parallele Klassifikation
2. Domänenausführung
3. Antwortsynthese

Jede Stufe nutzt LLMs auf unterschiedliche Weise und hat einen klar definierten, engen Vertrag.

1) Parallele Klassifikationsschicht

Die erste Schicht führt gleichzeitige Inferenz über mehrere spezialisierte Klassifikatoren durch: Sicherheit, Jailbreak-Erkennung, Sprachidentifikation, Abrufberechtigung, Intent-Routing und Workflow-Klassifikation.

Diese Schicht lässt sich am besten als Kombination aus Routing und Parallelisierung in Anthropics Workflow-Taxonomie verstehen. Das Modell hilft bei der Klassifikation der Anfrage, konstruiert jedoch keine beliebigen nachgelagerten Pläne dynamisch. Die verfügbaren Ausführungspfade sind vordefiniert, typisiert und durch Code durchgesetzt.

Zwei technische Eigenschaften sind dabei entscheidend:

Latenz-Isolation. Da diese Klassifikatoren gleichzeitig laufen, liegt die Gesamtlatenz näher an der des langsamsten Klassifikators als an der Summe aller Laufzeiten.

Fehler-Isolation. Jeder Klassifikator hat eine enge Prompt-Oberfläche und eine einzige Verantwortlichkeit, was Fehler leichter erkennbar, evaluierbar und nachtrainierbar macht als ein monolithischer Orchestrierungs-Prompt.

2) Domänenausführungsschicht

Nach der Klassifikation wählt ein code-seitiger Dispatcher die relevanten Domain-Handler aus.

Diese Schicht spiegelt unsere klarste Designentscheidung wider: die Ausführung begrenzt statt modellgesteuert zu halten. Das Modell entscheidet nicht Schritt für Schritt, welches Tool als nächstes in einem offenen Loop aufgerufen werden soll. Stattdessen folgt die Ausführung einem eingeschränkten Graphen:

• Lesende Operationen können parallel ausgeführt werden
• Zustandsverändernde Operationen werden sequenziell ausgeführt
• Seiteneffekte werden über code-gesteuerte Handler durchgeführt
• Ausgaben werden in typisierte Datenstrukturen geschrieben, anstatt an ein unkontrolliertes Reasoning-Transkript angehängt zu werden

Das macht die Ausführungssemantik expliziter und leichter inspizierbar. Das System verlässt sich nicht darauf, dass das Modell versteckten Zustand erhält, zulässige Übergänge inferiert oder entscheidet, ob bestimmte Prüfungen erforderlich sind.

Für Recruiting-Workflows ist das besonders relevant, weil das Laufzeitsystem nicht nur Fragen beantwortet. Es nimmt auch an einem zustandsbehafteten Geschäftsprozess teil: Erfassen erforderlicher Informationen, Validieren von Abschlusskriterien, Anwenden von Stufenlogik und Auslösen nachgelagerter Aktionen.

3) Antwortsyntheseschicht

Die letzte Stufe nimmt strukturierte Ausgaben aus vorherigen Stufen entgegen und erzeugt eine benutzerseitige Antwort.

Diese Stufe ist bewusst von der Ausführung getrennt. Ihre Rolle ist sprachlicher, nicht operativer Natur: Workflow-Zustand in eine klare konversationelle Antwort übersetzen, Ton und Formulierung anpassen, mehrsprachige Qualität wahren und nächste Schritte erläutern.

Sie tut nicht Folgendes:

• Neue Ausführungspfade wählen
• Workflow-Zustand verändern
• Übergangsregeln neu interpretieren
• Erforderliche Prozessschritte umgehen

Diese Trennung von Zuständigkeiten ist einer der Hauptvorteile der Architektur. Sie erlaubt es dem System, von der Sprachgewandtheit des LLMs zu profitieren, ohne dem Antwortmodell Autorität über den Kontrollfluss zu geben.

Warum wir keinen vollständig autonomen Agent-Loop verwendet haben

Der Hauptgrund ist, dass für die Recruiting-Workflows, die uns wichtig sind, unkontrollierte modellgesteuerte Ausführung die falschen Kompromisse mit sich bringt.

1) Prozesskorrektheit ist wichtiger als konversationelle Initiative

Bei einem allgemeinen Assistenten kann Initiative ein Feature sein. Im Recruiting kann sie zum Defekt werden.

Ein Screening-Flow enthält häufig Pflichtfragen, spezifische Bewertungsschritte, vorgeschriebene Hinweise und deterministische Übergangsbedingungen. Ein vollständig autonomer Agent kann schlussfolgern, dass eine Frage redundant ist, weil der Kandidat bereits etwas Ähnliches erwähnt hat. Das mag konversationell effizient sein, kann aber Standardisierungsanforderungen oder nachgelagerte Bewertungsannahmen verletzen.

Ein workflow-gesteuertes System ist darauf ausgelegt, diese Fehlerklasse zu reduzieren: Das Modell kann anpassen, wie ein Schritt kommuniziert wird, aber nicht ob er existiert.

2) Zustandsbehaftete Ausführung lässt sich in Code besser nachvollziehen als in Prompt-Zustand

Zustandsintensive Prozesse verschlechtern sich schnell, wenn zu viel Ausführungslogik an den konversationellen Kontext delegiert wird. In einem lang laufenden Agent-Loop muss das System latenten Zustand kontinuierlich über Gesprächsrunden und Tool-Ergebnisse hinweg erhalten und neu interpretieren.

Eine typisierte Workflow-Architektur externalisiert den Zustand hingegen:

• Fortschritt ist explizit
• Übergangsbedingungen sind explizit
• Seiteneffekte sind explizit
• Fehlerbehebung ist explizit

Das macht das System einfacher zu testen, einfacher zu prüfen und einfacher zu modifizieren.

3) Zuverlässigkeit bricht bei realistischen Enterprise-Aufgaben noch stark ein

Aktuelle Benchmark-Ergebnisse legen nahe, dass realistische mehrstufige Enterprise-Ausführung für Frontier-Systeme nach wie vor schwierig ist. Im EnterpriseOps-Gym, einem Benchmark vom März 2026 mit 1.150 von Experten kuratierten Aufgaben aus acht Enterprise-Domänen, erreichte das beste gemeldete Modell eine Erfolgsquote von 37,4 %. Dieses Ergebnis verdeutlicht die Lücke zwischen beeindruckenden lokalen Agentenverhaltensweisen und zuverlässiger End-to-End-Aufgabenerfüllung in produktionsähnlichen Umgebungen.

Die Lehre daraus ist nicht, dass agentische Techniken nutzlos sind. Sondern dass langfristige modellgesteuerte Ausführung viele Fehlerquellen auf einmal einführt: Dekomposition, Aktionswahl, Parameterauswahl, Ergebnisinterpretation, Policy-Einhaltung und Zustandskonsistenz.

Unsere Architektur verkleinert diese Fehlerfläche, indem sie unterschiedlichen Komponenten unterschiedliche Verantwortlichkeiten zuweist und die sensibelsten Teile der Ausführung außerhalb autonomer Kontrolle hält.

Warum das im Recruiting besonders relevant ist

Recruiting-Automatisierung unterscheidet sich von allgemeiner Assistenz in einem wesentlichen Punkt: Der konversationelle Teilnehmer ist nicht der einzige Stakeholder.

Recruiter, Arbeitgeber oder Prozessverantwortliche definieren:

• Erforderliche Schritte
• Bewertungskriterien
• Übergangsregeln
• Compliance-Grenzen
• Akzeptables Automatisierungsverhalten

Der Kandidat interagiert mit dem System, definiert aber nicht dessen Betriebssemantik.

Das macht Recruiting zu einem Beispiel für prozessgesteuerte Automatisierung, nicht für reine nutzergetriebene Assistenz.

In diesem Umfeld kann breite Modellautonomie eine Diskrepanz zwischen konversationeller Optimierung und Prozesskorrektheit erzeugen. Ein Modell kann auf Kürze, Empathie oder lokale Kohärenz optimieren und dabei Anforderungen verletzen, die dem eigentlichen Systemeigentümer wichtig sind.

Ein workflow-gesteuertes Agentensystem löst das durch die Trennung von:

• Was passieren muss — in Workflow-Logik kodiert
• Wie es kommuniziert wird — von LLMs übernommen

Sicherheit und Compliance lassen sich strukturell leichter durchsetzen

Ein weiterer Grund für die Bevorzugung von Workflow-Kontrolle ist, dass Sicherheitsprüfungen verpflichtende Pipeline-Schritte statt optionaler Modellentscheidungen sein können.

Moderation, Jailbreak-Erkennung, Policy-Klassifikation und Scope-Validierung laufen, weil das Laufzeitsystem sie ausführt — nicht weil das Modell es wählt. Das kann Prompt-Injection weniger wirksam machen, da das Modell nicht Eigentümer der Entscheidung ist, ob Schutzprüfungen ausgeführt werden.

Dies ist besonders im Recruiting relevant. Unter dem EU AI Act sind KI-Systeme, die für die Einstellung oder Auswahl natürlicher Personen eingesetzt werden, in Anhang III ausdrücklich als hochriskant eingestuft; die wesentlichen Verpflichtungen für diese Systeme gelten ab dem 2. August 2026. In einem Hochrisiko-Kontext werden Systemeigenschaften wie Rückverfolgbarkeit, menschliche Aufsicht und technische Dokumentation zu architektonischen Anliegen, nicht nur zu politischen Aspirationen.

Eine workflow-basierte Architektur hilft dabei, weil sie explizite Zwischenartefakte erzeugt:

• Klassifikator-Ausgaben
• Ausgewählter Ausführungspfad
• Erhobene strukturierte Daten
• Ausgelöste Regeln
• Resultierender Zustandsübergang

Das kommt einem prüfbaren Systemprotokoll näher als einer freien Vermischung von Reasoning und Tool-Traces.

Kompromisse

Diese Architektur ist bewusst weniger flexibel als ein vollständig autonomer Agent.

Sie kann keine beliebigen neuen Fähigkeiten außerhalb des definierten Ausführungsgraphen improvisieren. Wenn eine Fähigkeit nicht im Workflow repräsentiert ist, wird das System sie nicht erfinden. Das ist eine Einschränkung, aber in einem regulierten, zustandsbehafteten, geschäftsprozessorientierten Bereich ist sie oft die richtige.

Der Vorteil sind stärkere Garantien bezüglich:

• Prozesskorrektheit
• Zustandskonsistenz
• Sicherheitsdurchsetzung
• Prüfbarkeit
• Betrieblicher Vorhersagbarkeit

Für die Recruiting-Automatisierung haben wir diese Eigenschaften als wertvoller empfunden als unkontrollierte Modellautonomie.

Fazit

Wir haben agentische Techniken nicht abgelehnt. Wir setzen sie intensiv ein — für Routing, Klassifikation, Synthese und begrenzte Entscheidungsfindung. Was wir abgelehnt haben, ist vollständig autonome Kontrolle über die Ausführung.

Das Ergebnis ist eine Architektur, in der LLMs Intelligenz innerhalb enger Schnittstellen einbringen, während Code die Autorität über Workflow-Struktur, Zustandsmutation und Seiteneffekte behält. Für die Recruiting-Automatisierung war das für uns eine bessere technische Lösung als ein einzelner autonomer Agent-Loop.

‍