Agentic Workflows: ein Wort für zwei gegensätzliche Designs, und der Unterschied ist, wem die Schleife gehört

GitHubs Dokumentation zum Produkt Agentic Workflows enthält einen Satz, der mehr über das Design verrät als jede Definition auf derselben Website:

Decisions cannot override retry limits, budgets, deadlines, or
nonrecoverable failures.

Die Definitionen auf derselben Website zeigen in die andere Richtung. GitHub beschreibt Agentic Workflows so:

Agentic workflows are AI-powered automation that can understand context,
make decisions, and take meaningful actions

und stellt sie Automatisierung gegenüber, die auf festen Wenn-dann-Regeln beruht. Das ist die landläufige Bedeutung: Die KI entscheidet. Anthropics „Building effective agents“ verwendet das Wort Workflow für fast das Gegenteil, nämlich die Anordnung, in der das Modell den Plan nicht bestimmt. Derselbe Begriff deckt also zwei gegensätzliche Designs ab. GitHubs Produkt ist, genau gelesen, das, was Anthropic einen Agenten nennen würde, mit den Grenzen, die Anthropic nur empfiehlt, standardmäßig eingeschaltet. Und das Modell kann mit ihnen nicht verhandeln.

Das Label trägt die Information nicht. Was ein Team über einen Job wissen muss, den jemand agentisch nennt, ist enger und mechanischer: Wer entscheidet den nächsten Schritt, wer entscheidet, dass die Arbeit vorbei ist, und prüft irgendetwas außer dem Modell, ob die Arbeit stimmt? Die letzten beiden sind verschiedene Fragen, und die meiste Verwirrung entsteht, wenn man sie als eine behandelt.

Was Anthropic mit Workflows und Agenten meint

Anthropics Essay vom Dezember 2024 stellt beides unter einen Oberbegriff, agentische Systeme, und zieht die Linie innerhalb davon:

Workflows are systems where LLMs and tools are orchestrated through
predefined code paths. Agents, on the other hand, are systems where
LLMs dynamically direct their own processes and tool usage, maintaining
control over how they accomplish tasks.

Schnell gelesen ist das eine Trennung zwischen „das Modell folgt einem Skript“ und „das Modell hat das Sagen“. Die Muster, die unter Workflows einsortiert sind, passen nicht zu dieser Lesart. Prompt Chaining, Routing und Parallelisierung sind, was man erwartet: feste Pfade, das Modell füllt jeden Schritt aus. Aber auch Orchestrator-Workers ist ein Workflow, und dort zerlegt ein zentrales Modell die Aufgabe spontan, verteilt die Teile an Worker-Modelle und fasst zusammen, was zurückkommt. Das Modell entscheidet, was die Teilaufgaben sind. Evaluator-Optimizer ist ebenfalls ein Workflow, und er ist eine Schleife: Ein Aufruf erzeugt, ein anderer bewertet, Runde um Runde.

Dass das Modell Entscheidungen trifft, trennt die beiden Stapel also nicht. Bei Orchestrator-Workers wählt das Modell die Teilaufgaben, aber die Rollen drumherum sind im Code festgelegt: zerlegen, delegieren, zusammenfassen. Bei Evaluator-Optimizer kann das Urteil des Evaluators eine weitere Runde verlangen, aber die Schleife hast du geschrieben, und du kannst ihr eine Rundengrenze geben. Was ein Muster auf den Agenten-Stapel bringt: Das Modell steuert den Ablauf selbst, statt Lücken in einer Struktur zu füllen, die jemand anderes gebaut hat. Wer sagen darf, dass die Arbeit fertig ist, ist eine eigene Frage, und sie geht quer durch beide Stapel.

GitHub Agentic Workflows: ein Agent nach Anthropic, mit Grenzen ab Werk

Nach Anthropics Definition ist GitHub Agentic Workflows (gh-aw) ein Agent. Du schreibst Anweisungen in natürlicher Sprache als Markdown mit YAML-Frontmatter; gh aw compile macht daraus eine normale GitHub-Actions-Lock-Datei; zur Laufzeit liest eine Engine (die Doku nennt GitHub Copilot, Claude Code, OpenAI Codex, Google Gemini und Pi) die Anweisungen und arbeitet die Aufgabe mit Tools ab. Innerhalb des Runs entscheidet der Agent, was er liest und was er als Nächstes tut.

GitHub hat den Teil ergänzt, den Anthropics Essay als Ratschlag stehen lässt. Das Essay erwähnt, dass Agenten üblicherweise Abbruchbedingungen bekommen, etwa eine Höchstzahl an Iterationen, um die Kontrolle zu behalten. In gh-aw sind das Standardwerte im Frontmatter: timeout-minutes für den agentischen Schritt steht auf 20, max-turns begrenzt Modellantworten und Tool-Aufrufe pro Run auf 500, sofern du nichts anderes setzt, und ein AI-Credits-Budget ist standardmäßig aktiv. Der Agent-Job bekommt standardmäßig nur Leserechte auf das Repository, und der empfohlene Schreibweg sind deklarierte Safe Outputs (Issue anlegen, Kommentar schreiben, Pull Request öffnen), die vor dem Anwenden validiert werden. Direkte Schreibrechte gibt es auch, aber nur als eigene Vertrauensgrenze, die du ausdrücklich einschalten musst. Das ist der Kontext für den Satz ganz oben: Dem Modell gehört der Weg, dem Harness gehört, wie lang der Weg sein darf, was er berühren darf und welche Form eine Änderung haben muss, um die Sandbox zu verlassen.

Jede dieser Grenzen beendet einen Run oder schränkt ein, was er tun kann. Keine davon sagt, ob der Run seinen Job erledigt hat. Ein Timeout ist ein Ausgang, kein Urteil.

Agentic Workflows enden auf drei Arten, und nur eine davon ist eine Prüfung

Eine Schleife, die normal endet, endet auf eine von drei Arten. Ein Codepfad läuft aus: Die Pipeline hat fünf Stufen, und die fünfte ist fertig. Eine externe Prüfung besteht: Die Tests sind grün, das Schema validiert, der Datensatz stimmt mit seiner Quelle überein. Oder das Modell sagt, es sei fertig. (Erzwungene Enden, ein Timeout, ein aufgebrauchtes Budget, ein Abbruch, sind eine vierte Art und gehören als unvollständig ins Log, nie als Erfolg.)

Nur die zweite ist ein Beleg für die Arbeit. Die erste sagt dir, dass das Programm geendet hat, und das ist wieder ein Exit-Code. Ich habe schon früher argumentiert, dass ein Exit eine Zusammenfassung ist, die der Prozess über sich selbst geschrieben hat, kein Urteil. Die dritte sagt dir, was das Modell von seiner eigenen Ausgabe hält. In einem Multi-Agenten-Setup ist das der bekannte Fall, dass ein Agent Erfolg für Arbeit meldet, die nie gelaufen ist, einer der Koordinationsfehler, die man beim Entwurf einplanen sollte. Ein Workflow-Run in Claude Managed Agents zeigt dasselbe in der Doku von Anthropic: Ein Run kann als completed enden, während Arbeit in seinen Threads fehlgeschlagen ist.

Es gibt hier also zwei getrennte Regler. Wem die Schleife gehört, entscheidet, wie groß ein Fehler werden kann. Was das Ende prüft, entscheidet, ob du davon erfährst. Anthropics eigener Bericht über sein Multi-Agenten-Recherchesystem vom Juni 2025 zeigt, wie der erste Regler danebengeht: Frühe Agenten starteten 50 Subagenten für einfache Anfragen und machten weiter, obwohl sie schon genug Ergebnisse hatten. Das ist Übersteuern, und dagegen helfen Grenzen und Skalierungsregeln; Anthropic hat es mit Aufwandsregeln in den Prompts behoben. Es ist ein anderer Fehler als ein Run, der pünktlich mit der falschen Antwort stoppt, und gegen diesen hilft nichts am ersten Regler.

Anthropics Schrittzahl-Test für Agenten und der Test im eigenen Anhang

Anthropics Kriterium, wann man zu einem Agenten greift, lautet:

Agents can be used for open-ended problems where it's difficult or
impossible to predict the required number of steps, and where you
can't hardcode a fixed path.

Stimmt, ist aber nicht das Entscheidende. Viele Aufgaben haben eine unvorhersehbare Zahl von Schritten und sollten dem Modell trotzdem nicht das Ende überlassen: alles, wo „fertig“ ein Urteil ist, das danach niemand nachprüft.

Der bessere Test steht im selben Essay, im Anhang darüber, wo Agenten in der Praxis funktionieren. Coding-Agenten sind effektiv, heißt es dort, weil:

Code solutions are verifiable through automated tests; Agents can
iterate on solutions using test results as feedback; The problem space
is well-defined and structured; and Output quality can be measured
objectively.

Das ist keine Aussage über die Schrittzahl. Es ist die Aussage, dass etwas anderes als das Modell das Ende bestätigen kann, und der Anhang sagt dasselbe über beide Bereiche, die er behandelt: Die Bereiche, in denen Agenten nützlich sind, haben klare Erfolgskriterien. Selbst dort fügt Anthropic hinzu, dass menschliches Review weiter zählt, nämlich dafür, ob eine Lösung zu den weitergehenden Anforderungen passt, denn Tests decken nur ab, was sie testen. Innerhalb dieser Grenze kann ein Coding-Agent drei Turns oder vierzig laufen, und es ist trotzdem vertretbar, ihm die Schleife zu geben, mit einer Bedingung, die der Anhang nicht ausspricht: Die Tests liegen außerhalb seiner Schreibrechte. Ein Agent, der den Test bearbeiten kann, an dem er gemessen wird, prüft wieder sich selbst, und eine Prüfung greift nur auf den Pfaden, die sie abdeckt. Das ist dieselbe Grenze, die jedes Harness-Gate hat. Genau das leisten die Leserechte und Safe Outputs von gh-aw. Der Agent kann eine Änderung vorschlagen; er kann nicht heimlich ändern, was ihn bewertet.

Und ein zweites Modell als Richter, der Evaluator in Evaluator-Optimizer? Er zählt nur in dem Maß als Prüfung von außen, in dem er anders scheitert als der Worker: ein anderes Modell, ein anderer Kontext, Kriterien, die man ihm gegeben hat, statt solcher, die er sich selbst erschlossen hat. Eine Kopie des Workers, die den Worker bewertet, teilt seine blinden Flecken und fügt Zuversicht hinzu, keine Information.

Agentic Workflows in Produktion: Die Schleife bleibt im Code, es sei denn, das Ende ist prüfbar

Daraus ergibt sich mein Standard für jeden Job, den jemand agentisch nennt. Es ist eine Präferenz dafür, wann es vertretbar ist, die Schleife abzugeben, nicht dafür, wann es nötig ist; eine prüfbare Aufgabe mit bekanntem Weg kann trotzdem ein einfaches Skript sein.

Wenn etwas außerhalb des Modells und außerhalb seiner Schreibrechte prüfen kann, dass die Arbeit erledigt ist (ein Test, ein Validator, ein Abgleich mit einer verlässlichen Quelle, ein Mensch an einem Gate, der die Ausgabe tatsächlich liest), kann dem Modell die Schleife gehören. Knüpf den Ausgang an diese Prüfung, nicht an die Behauptung des Modells, und leg den Rahmen im Code fest, so wie gh-aw es tut: Deadline, Turn-Grenze, Budget, ein schmaler Schreibweg. Die Grenze deckelt die Kosten. Die Prüfung sorgt dafür, dass ein normaler Ausgang etwas bedeutet.

Wenn nichts außerhalb des Modells das Ende prüfen kann, bleibt die Schleife im Code. Schreib die Zustände und Übergänge als Programm, das du testen kannst, mit Retries und einer Grenze, und ruf das Modell an den Entscheidungspunkten darin auf: dieses Ticket klassifizieren, diese Felder extrahieren, diese Antwort entwerfen, beurteilen, ob diese zwei Datensätze dieselben sind. Die Schleife im Code verifiziert das Ergebnis nicht; eine entworfene Antwort bleibt ungeprüft. Was du gewinnst, ist eine Obergrenze. In einer Schleife im Code kann sich das Modell innerhalb eines Schritts irren. Es kann keinen Schritt überspringen, keine zehn hinzufügen und den Job nicht für beendet erklären, also bleibt ein Fehler so groß wie ein Aufruf, und die Stelle, an der er passiert ist, hat im Log einen Namen.

Der Fall, der das verwischt: Das Modell schreibt den Plan, und Code führt ihn aus. Dynamic Workflows in Claude Managed Agents funktionieren so: Der Agent schreibt das Fan-out als Programm, das der Server ausführt. Das sieht aus wie eine Schleife im Code, aber der Codepfad, der „ausläuft“, ist einer, den das Modell geschrieben hat, und so wird aus der ersten Art von Ausgang stillschweigend die dritte. Der einzige Rahmen, den du dort selbst setzt, ist das Session-Budget, und das wird beim Anlegen der Session festgelegt, bevor der Plan existiert.

Nichts davon setzt voraus, dass das Wort „agentisch“ geklärt ist. Wenn jemand nach Agentic Workflows fragt, besteht die nützliche Antwort aus zwei Fragen zu einem konkreten Job: Wenn das nachts läuft und das Modell sagt, es sei fertig, was prüft das? Und was hält es an, wenn nichts prüft?