Workflow-Muster für Agenten – welches wann, und wann keins

Das Angebot ist größer als der Bedarf

Wer heute ein Agenten-System plant, findet Kataloge mit einem Dutzend Architekturen. Die Praxis zeigt in die andere Richtung: Die erfolgreichsten Implementierungen nutzen wenige einfache Muster, die sich kombinieren lassen. Anthropic bestätigt das nach der Arbeit mit Dutzenden Teams. Die meisten Projekte scheitern nicht an zu wenig Komplexität, sondern an zu viel. Jede zusätzliche Schicht kostet Latenz, Geld und Debugbarkeit.

Daraus folgt die Grundregel dieser Lesson: Starte mit der einfachsten Lösung, die funktioniert. Füge Komplexität nur hinzu, wenn sie messbar bessere Ergebnisse liefert. Für viele Aufgaben reicht ein einzelner, gut gebauter Modellaufruf mit Retrieval. Ein Muster ist kein Qualitätsmerkmal. Es ist die Antwort auf ein benanntes Problem. Wer das Problem nicht benennen kann, braucht das Muster nicht.

Wer bestimmt den nächsten Schritt

An dieser einen Frage trennen sich Workflows und Agenten:

Das ist keine Reifeskala. Workflows sind nicht die Vorstufe von Agenten, sondern eine eigene, oft bessere Wahl. Die Schleife selbst, der Agentic Loop, ist Thema von Vom Prompt zum Loop. Diese Lesson behandelt die Ebene darunter: die Muster, aus denen beide Seiten gebaut werden.

Die Landkarte: fünf Muster

Die Reihenfolge ist keine Rangliste. Sie sortiert nach Kontrolle: Von oben nach unten wächst der Anteil, den das Modell am Ablauf hat. Bei Chaining und Routing steht jeder Pfad im Code. Bei Orchestrator-Workers entscheidet das Modell über die Zerlegung, und genau dort beginnt der Übergang zum Agenten. Die folgenden Steps gehen die Muster in dieser Reihenfolge durch. Am Ende stehen ein Prüfschema für die Entscheidung und ein reales System als Kombinationsbeispiel.

Prompt Chaining zerlegt eine Aufgabe in feste Stufen. Jeder Aufruf verarbeitet den Output des vorherigen, und der Ablauf steht komplett im Code. Der Tausch dahinter: etwas mehr Latenz, dafür weniger Fehler. Mehrere fokussierte Aufrufe schlagen einen einzelnen, der alles auf einmal soll. Ein Aufruf, der zugleich zusammenfassen, prüfen und umformulieren soll, macht alle drei Dinge mittelmäßig.

Typische Ketten aus dem Coding-Alltag: Diff zusammenfassen, dann Release-Note formulieren. Text erzeugen, dann gegen Kriterien prüfen, dann übersetzen. Anforderung strukturieren, dann Code generieren.

Das Gate: die Kontrollstelle zwischen den Stufen

Ein Gate ist eine Kontrollstelle zwischen zwei Stufen: ein Stück normaler Code, der den Zwischenstand prüft, bevor die nächste Stufe startet. Wie ein Signal zwischen zwei Streckenabschnitten: Erst wenn es Fahrt zeigt, geht es weiter. Im Code-Beispiel oben ist das Gate die Regex-Zeile. Das Änderungsprotokoll muss eine Ticket-Nummer enthalten, sonst bricht die Kette ab, und Stufe 2 läuft gar nicht erst. Solche Prüfungen können ein Regex sein, ein Schema-Check oder ein Abgleich gegen eine Liste. Entscheidend ist, dass Code urteilt und kein weiterer Modellaufruf: Die Prüfung kostet praktisch nichts, ist immer gleich streng und lässt sich nicht überreden. So werden Fehler dort gefangen, wo sie entstehen, statt in die teuerste Stufe weiterzuwandern.

Routing stellt der Verarbeitung eine Klassifikation voran. Ein kleiner Aufruf ordnet die Eingabe einer Kategorie zu. Jede Kategorie hat ihren eigenen Pfad: eigener Prompt, eigene Tools, eigenes Modell. Der Grund ist Trennung der Anliegen. Ein einzelner Prompt, der Bug-Reports, Feature-Wünsche und Rechnungsfragen gleichzeitig behandeln soll, wird bei jeder Optimierung für einen Falltyp in den anderen schlechter.

Die wichtigste Zeile ist der Konfidenz-Ausgang. Ein Router ohne Unklar-Pfad zwingt jede Eingabe in die nächstbeste Kategorie. Der falsch geroutete Fall bekommt dann den falschen Prompt, die falschen Tools und die falschen Grenzen. Damit ist die Fehlklassifikation teurer als im Ein-Prompt-System, denn der Spezialpfad wurde für andere Fälle gebaut. In Sicherheit in der Generierung trägt genau dieses Muster die Architektur: Ein Guard klassifiziert die Risikoklasse, und die Prüftiefe folgt der Klasse, nicht dem System.

Parallelisierung lässt mehrere Aufrufe gleichzeitig laufen und führt die Ergebnisse in einem Aggregationsschritt zusammen. Dahinter stecken zwei Spielarten mit verschiedenem Zweck. Sectioning zerlegt in unabhängige Teilaufgaben und kauft Zeit: drei Dokumente gleichzeitig zusammenfassen statt nacheinander. Voting bearbeitet dieselbe Aufgabe mehrfach aus verschiedenen Blickwinkeln und kauft Verlässlichkeit: drei Prüfungen desselben Codes, jede mit eigenem Fokus.

Warum drei Aufrufe statt ein Prompt mit drei Aufträgen? Aus demselben Grund wie beim Chaining: Jede Perspektive bekommt die volle Aufmerksamkeit eines eigenen Aufrufs. Ein zweiter verbreiteter Einsatz ist die Guardrail-Prüfung parallel zur Antwortgenerierung. Sie kostet keine zusätzliche Latenz, weil sie neben der Antwort läuft statt nach ihr.

Voting in groß: der Modell-Rat

Wie weit sich Voting treiben lässt, zeigt das LLM-Council-Muster, bekannt geworden durch Andrej Karpathy. Drei Stufen: Erst beantworten mehrere Modelle verschiedener Anbieter dieselbe Frage parallel. Dann bewertet jedes Modell alle Antworten, anonymisiert als Antwort A, B und C, damit keines den eigenen Anbieter bevorzugt. Zuletzt fasst ein benanntes Chairman-Modell aus Antworten und Bewertungen die beste Fassung zusammen. Die ehrliche Rechnung: Vier Modelle bedeuten vierfache Token-Kosten, plus Review-Runde, plus Synthese. Das lohnt für einzelne Fragen, bei denen Qualität über Kosten steht, nicht als Standardpfad.

Orchestrator-Workers dreht die Rollen. Ein zentrales Modell, der Orchestrator, zerlegt die Aufgabe zur Laufzeit in Teilaufträge, delegiert sie an Worker und führt die Ergebnisse zusammen. Der Unterschied zur Parallelisierung liegt in einer einzigen Frage: Wer definiert die Teilaufgaben? Beim Sectioning stehen sie im Code. Hier entscheidet das Modell, wie viele es werden und welche, denn das hängt von der Eingabe ab.

Der Klassiker aus dem Coding-Alltag: eine Änderung, die eine vorher unbekannte Zahl von Dateien betrifft. Oder eine Recherche, deren Quellenmenge erst die Suche ergibt.

Das zweite Argument für dieses Muster ist der Kontext. Worker sind Sub-Agents mit eigenem Kontextfenster. Das Rohmaterial, lange Dateien, Suchtreffer, Zwischenstände, bleibt beim Worker. Der Orchestrator sieht nur Ergebnisse. Genau so arbeiten Coding-Agents, wenn sie für eine breite Suche einen Subagenten losschicken, der hundert Treffer liest und drei Fundstellen zurückmeldet. Der Hauptkontext bleibt sauber, und das hält lange Läufe stabil.

Evaluator-Optimizer trennt Erzeugen und Bewerten. Ein Modell liefert einen Entwurf. Ein zweiter Aufruf bewertet ihn gegen Kriterien und gibt konkrete Beanstandungen zurück. Die fließen in den nächsten Versuch, und die Schleife läuft, bis die Qualität reicht oder das Budget erschöpft ist.

Der menschliche Vergleich für die zweite Bedingung: Würde ein Lektor mit konkreten Anmerkungen den Text wirklich besser machen? Bei einer literarischen Übersetzung ja. Bei einer Betreffzeile eher nicht.

Warum getrennte Rollen und explizite Kriterien

Der Generator steht unter dem Auftrag zu liefern. Dieser Druck färbt jede Selbsteinschätzung. Ein separater Prüfaufruf mit eng gefasstem Auftrag urteilt ohne ihn. Genauso wichtig sind die Kriterien. Die Frage ist das gut? produziert wohlwollendes Nicken. Die Frage sind alle Zahlen aus der Vorlage übernommen, ist der Ton konsistent, fehlt eine Pflichtangabe? produziert Befunde. Und wenn Generator und Evaluator dieselbe Schwäche teilen, bestätigt die Schleife sich selbst. Dagegen helfen Kriterien aus der Domäne statt aus dem Modell, und wo es geht, deterministische Checks als Ergänzung.

Das Budget gehört zum Muster wie die Schleife selbst. Sicherheit in der Generierung rechnet das für den Produktionsfall durch: genau ein Wiederholungslauf mit der konkreten Beanstandung als Zusatzanweisung, danach ein vorab freigegebener Fallback. Die Begründung trägt über den Einzelfall hinaus: Wird eine präzise benannte Beanstandung im zweiten Versuch nicht behoben, liegt das Problem nicht in der Formulierung, sondern in der Faktenlage oder im Prompt. Weitere Runden kosten dann Geld, ohne die Wahrscheinlichkeit nennenswert zu heben.

Ein Multi-Agent-System ist keine eigene Systemklasse, sondern eine Entscheidung darüber, wie mehrere Agenten koordiniert werden. Jeder Sub-Agent für sich ist ein gewöhnlicher Agent. Neu ist nur die Koordination, und die gibt es in vier Stufen aufsteigender Komplexität, nach Philipp Schmid:

Die Stufen bringen dabei kaum neue Bauformen mit. Es sind die Formen aus den fünf Mustern, nur wandert die Steuerung vom Code ins Modell: Fan-Out ist Parallelisierung, bei der der Haupt-Agent zur Laufzeit entscheidet, wann er auffächert und wann er einsammelt. Ein Inline-Tool ist ein gewöhnlicher Tool-Aufruf, hinter dem ein ganzer Agent steckt. Wirklich neu sind erst zwei Dinge weiter oben auf der Treppe: Ab dem Pool bleiben Sub-Agents über den einzelnen Auftrag hinaus bestehen und tragen eigenen Zustand, und bei Teams reden sie direkt miteinander, ohne Zentrale. Genau deshalb steigen Kosten und Risiko die Treppe hinauf: Je mehr Steuerung im Modell liegt, desto weniger lässt sich vorhersagen und testen.

Stufe 1 ist unspektakulär, und genau das ist ihr Wert. Der Sub-Agent ist aus Sicht des Haupt-Agenten ein Funktionsaufruf mit eigenem Kontext dahinter:

1. Starte bei Stufe 1. Das meiste, was sich nach Multi-Agent anfühlt, funktioniert als gut gepromptetes Inline-Tool. Die Stufen 2 bis 4 sind Eskalationen für benannte Grenzen, nicht der Ausgangspunkt.
2. Multi-Agent ist nicht automatisch besser. Token-Kosten vervielfachen sich, Debugging wird härter, und Fehler propagieren zwischen Agenten: Eine schiefe Zwischenausgabe wird zur Arbeitsgrundlage des nächsten.
3. Die Grenze verschiebt sich. Eine Aufgabe, die heute vier koordinierte Agenten braucht, löst mit der nächsten Modellgeneration oft ein einziger besserer Agent. Wer früh auf Stufe 4 baut, pflegt Koordinations-Code, den die Zeit entwertet.

Einzeln ist jedes Muster einfach. Schwierig ist die Auswahl. Darum stellst du die Fragen in fester Reihenfolge, von der einfachsten Architektur zur komplexesten. Jedes Ja gibt dir genau ein Muster. Jedes Nein führt zur nächsten Frage. Was am Ende kein Ja bekommen hat, wird nicht gebaut.

Ein reales System, drei Muster

Dass die Muster Bausteine sind und keine Konkurrenten, zeigt die Prüfpipeline aus Sicherheit in der Generierung. Dort steht ein Versicherungs-Assistent, dessen Architektur sich vollständig auf diese Lesson abbilden lässt:

Bemerkenswert ist, was dieses System nicht ist: Es ist kein Agent. Der Pfad steht vollständig im Code, jede Stufe ist auditierbar, und trotzdem stecken drei Muster darin. Das ist der Normalfall produktiver Systeme, und er bestätigt die Grundregel aus Step 1: Die Muster kamen nacheinander dazu, jedes als Antwort auf ein benanntes Problem.

Die Regeln auf einen Blick

Begriffe aus dieser Lesson

• Agentic Loop — Die Agentic Loop ist der Kernmechanismus eines KI-Agenten: Planen, Handeln, Beobachten, Anpassen. Der Agent iteriert in dieser Schleife, bis die Aufgabe erledigt ist oder ein Limit erreicht wird.
• Multi-Agent-System — Ein Multi-Agent-System besteht aus mehreren spezialisierten KI-Agenten, die zusammenarbeiten. Jeder Agent hat eine eigene Rolle, eigene Tools und eigene Verantwortung. Sinnvoll nur bei echtem Parallelitätsbedarf.
• Orchestrator — Ein Orchestrator koordiniert mehrere Agenten oder Arbeitsschritte in einem komplexen KI-Workflow. Er entscheidet, welcher Agent wann aktiv wird und wie die Ergebnisse zusammengeführt werden.
• Prompt-Chaining — Prompt-Chaining zerlegt eine komplexe Aufgabe in mehrere aufeinander aufbauende Prompts. Der Output von Schritt 1 wird zum Input von Schritt 2. Das verbessert Qualität und Kontrolle bei anspruchsvollen Aufgaben.
• Sub-Agent — Ein Sub-Agent ist ein untergeordneter KI-Agent, der einen Teilauftrag in seinem eigenen Kontext bearbeitet und nur das Ergebnis zurückgibt, damit Rohmaterial den Hauptdurchlauf nicht belastet.