Grundlagen: Agent oder Workflow — und wann keins von beidem

Wer den Kontrollfluss besitzt

Zwei Systeme können dasselbe Modell benutzen, dieselben Werkzeuge anbinden und dieselbe Aufgabe lösen — und trotzdem grundverschieden sein. Der Unterschied hängt an einer einzigen Stelle: Wer entscheidet, was als Nächstes passiert.

Workflow — Ein System, in dem Modelle und Werkzeuge über vorab festgelegte Code-Pfade orchestriert werden. Die Abfolge der Schritte steht im Code; das Modell füllt die Schritte aus.

Agent — Ein System, in dem das Modell seinen eigenen Ablauf und seinen Werkzeuggebrauch dynamisch steuert und die Kontrolle darüber behält, wie es eine Aufgabe erledigt.

Diese Trennung ist keine Geschmacksfrage, und sie lässt sich mechanisch prüfen. Zeige auf die Codestelle, die entscheidet, welcher Schritt als Nächstes läuft. Ist es ein if oder ein match in deinem Programm, hast du einen Workflow. Ist es das Modell, das einen weiteren tool_use-Block zurückgibt und damit eine weitere Runde erzwingt, hast du einen Agenten.

Der Test funktioniert auch dann, wenn die Beteiligten sich uneinig sind. Ein Team, das drei feste Modellaufrufe hintereinander ausführt — zusammenfassen, übersetzen, formatieren —, hat drei LLM-Aufrufe und keinen Agenten. Ein Team, das genau einen Prompt in einer while-Schleife hat, die erst endet, wenn das Modell aufhört, Werkzeuge anzufordern, hat einen Agenten.

Der erweiterte Modellaufruf ist der Baustein, nicht schon der Agent

Der kleinste sinnvolle Baustein ist nicht der Agent, sondern der erweiterte Modellaufruf: ein Modell, dem Retrieval, Werkzeuge und Gedächtnis zur Verfügung stehen. Wer diesen Baustein nicht sauber im Griff hat, baut die Unklarheit in jede Schleife hinein, die darauf aufsetzt.

Der hervorgehobene Schritt ist der, der in Architekturdiskussionen am häufigsten verschwindet. Das Modell führt nichts aus. Es gibt einen strukturierten Wunsch mit Namen und Argumenten zurück. Ausgeführt wird im eigenen Prozess, mit den eigenen Zugangsdaten, unter den eigenen Rechten.

Wer das verwischt, sucht Berechtigungsfehler beim Modellanbieter statt in der eigenen Ausführungsschicht — und schreibt Sicherheitsregeln in den Prompt, wo sie nichts erzwingen können. Die Ausführungsschicht ist der Ort, an dem ein Agent überhaupt kontrollierbar ist; alles davor ist Textverarbeitung.

Diese Schleife hat einen Namen und eine Herkunft. ReAct (Yao et al., ICLR 2023) beschreibt, Reasoning-Spuren und aufgabenspezifische Aktionen verschränkt zu erzeugen, statt eines von beidem allein: Das Nachdenken hilft bei Planung und Ausnahmebehandlung, die Aktionen holen Information aus externen Quellen. Der Nutzen ist messbar belegt — auf ALFWorld und WebShop übertraf ReAct lernbasierte Verfahren um 34 beziehungsweise 10 Prozentpunkte absolute Erfolgsrate.

Wichtig ist der zweite Teil dieses Befunds: Der Gewinn kam gegenüber Verfahren, die nur dachten oder nur handelten. Reines Nachdenken ohne Außenkontakt neigt zu Halluzination und Fehlerfortpflanzung; reines Handeln ohne Zwischenreflexion verliert das Ziel. Die Verschränkung ist der Wirkmechanismus — nicht die Autonomie an sich.

Fünf Muster, die keinen Agenten brauchen

Bevor man sich für einen Agenten entscheidet, lohnt der Blick auf die Muster, die mit festem Kontrollfluss auskommen. Anthropic benennt in „Building Effective Agents“ fünf davon, jeweils mit der Bedingung, unter der sie passen.

Prompt Chaining

Die Aufgabe lässt sich sauber in feste Teilschritte zerlegen; jeder Schritt verarbeitet die Ausgabe des vorherigen.

Routing

Es gibt klar unterscheidbare Kategorien, die getrennt besser behandelt werden als gemeinsam.

Parallelisierung

Teilaufgaben sind fachlich unabhängig (Sectioning) — oder mehrere Perspektiven auf dieselbe Frage sind erwünscht (Voting).

Orchestrator-Workers

Die nötigen Teilaufgaben sind vorab nicht vorhersagbar; ein zentrales Modell zerlegt zur Laufzeit.

Evaluator-Optimizer

Es gibt klare Bewertungskriterien, und Iteration verbessert das Ergebnis messbar.

Vier dieser fünf Muster haben ihren Kontrollfluss im Code und sind damit reproduzierbar, testbar und in ihren Kosten vorab abschätzbar. Nur Orchestrator-Workers verschiebt die Zerlegung in die Laufzeit — und ist deshalb die Stelle, an der ein Workflow in ein agentisches System übergeht.

Der Pfad entscheidet, nicht das Thema

Die verbreitete Fehlannahme lautet, die Schwierigkeit der Aufgabe entscheide über das Werkzeug: schwierig gleich Agent. Entscheidend ist aber nicht die Schwierigkeit, sondern die Vorhersagbarkeit des Pfades. Eine fachlich anspruchsvolle Aufgabe mit immer gleichen Schritten ist ein Workflow. Eine fachlich triviale Aufgabe, deren Schritte von Zwischenergebnissen abhängen, ist ein Kandidat für einen Agenten.

• Kannst du die Schritte vorab aufschreiben? Wenn ja, schreibe sie auf — statt sie ein Modell jedes Mal neu erfinden zu lassen.
• Hängt der nächste Schritt vom Ergebnis des vorherigen ab — nicht nur im Inhalt, sondern in der Art? Erst dann trägt eine Schleife.
• Ist die Zahl der Schritte nach oben offen? Dann brauchst du eine Abbruchbedingung, bevor du anfängst, nicht nachdem die erste Rechnung kommt.

Anthropics Empfehlung ist an dieser Stelle ungewöhnlich direkt: Komplexität nur hinzufügen, wenn sie das Ergebnis nachweisbar verbessert. Erst mit einfachen Prompts anfangen, sie mit belastbarer Evaluation optimieren — und mehrstufige agentische Systeme erst dann, wenn die einfachere Lösung nachweislich nicht reicht.

Autonomie ist eine Achse, kein Schalter

„Agent“ und „kein Agent“ ist eine grobe Unterscheidung. Innerhalb agentischer Systeme ist der Autonomie-Grad die eigentliche Entscheidung — und er lässt sich abstufen, und zwar pro Aktionsklasse, nicht pro System.

Vorschlag

Das System schlägt Schritte vor, ein Mensch führt sie aus. Kein Wirkungsrisiko, aber auch kein Durchsatzgewinn.

Freigabe je Aktion

Der Agent handelt, jede Aktion wird einzeln bestätigt. Sicher — bis die Zahl der Bestätigungen echtes Prüfen unmöglich macht.

Freigabe je Klasse

Reversible Aktionen laufen autonom, wenige riskante Klassen brauchen Freigabe. Der übliche tragfähige Betriebspunkt.

Nachträgliche Prüfung

Alles läuft autonom, geprüft wird im Protokoll. Nur tragfähig, wenn jede Wirkung kompensierbar ist.

Excessive Autonomy — In der OWASP-Klassifikation eine der drei Wurzeln von Excessive Agency: Dem System fehlt eine unabhängige Prüfung und Freigabe für Aktionen mit hoher Wirkung.

Der übliche Fehler ist nicht zu viel und nicht zu wenig Autonomie, sondern eine einheitliche Autonomie über alle Aktionsklassen hinweg. Wer einen Tag-Aufruf und eine Produktionslöschung gleich behandelt, wählt für mindestens eine der beiden zwangsläufig den falschen Grad.

Die Aktionsklassen schneidet man nicht nach fachlicher Wichtigkeit, sondern nach zwei Betriebsgrößen: Rückholbarkeit und Wirkungsradius. Ein Deployment-Rollback ist fachlich wichtig, aber rückholbar und auf einen Dienst begrenzt. Ein Massen-Mailversand an Kunden ist fachlich nebensächlich und trotzdem unrückholbar mit externem Radius. Die zweite Aktion braucht die Freigabe, nicht die erste.

Kosten wachsen mit der Zahl der Runden, nicht mit ihrer Summe

Die Kostenschätzung, die praktisch jedes Team zuerst aufstellt, lautet: durchschnittliche Eingabelänge mal Zahl der Aufgaben mal Preis. Sie liegt bei Agenten regelmäßig um einen Faktor daneben — strukturell, nicht wegen schlechten Promptings.

Der Grund steht in der Dokumentation zum Kontextfenster: Die Historie akkumuliert fortschreitend, frühere Runden bleiben vollständig erhalten. Jede Runde schickt die ganze bisherige Nachrichtenliste erneut als Eingabe — samt Systemprompt, Werkzeugdefinitionen und aller Werkzeugergebnisse. Bei acht Runden wird der Systemprompt achtmal bezahlt.

Nichtdeterminismus ist ein struktureller Fakt, kein Bug

Ein Agent ist kein Programm mit unklarer Spezifikation, sondern ein Programm mit stochastischem Kontrollfluss. Dieselbe Eingabe kann zu einem anderen Pfad führen: eine andere Werkzeugreihenfolge, eine Runde mehr, eine übersprungene Prüfung. Das ist keine Fehlkonfiguration, die man wegdreht, sondern die Eigenschaft, für die man den Agenten überhaupt eingesetzt hat.

Die praktische Folge trifft zuerst die Tests. Ein Test, der behauptet, „für Eingabe X nimmt der Agent exakt die Schritte A, B, C“, ist nicht streng, sondern instabil. Er schlägt bei harmlosen Pfadvarianten fehl und bleibt bei echten Regressionen stumm, solange die Endausgabe zufällig stimmt.

Excessive Agency: drei Wurzeln, eine Wirkung

Für den Schaden, den ein handelndes System anrichten kann, gibt es einen benannten Eintrag im OWASP-Katalog für LLM-Anwendungen: LLM06 Excessive Agency. Die Definition ist bewusst unabhängig von der Ursache formuliert.

Excessive Agency — Die Schwachstelle, die schädigende Aktionen ermöglicht — als Reaktion auf unerwartete, mehrdeutige oder manipulierte Modellausgaben, unabhängig davon, was die Fehlfunktion verursacht.

• Excessive Functionality — dem Agenten stehen Fähigkeiten offen, die er für seinen Zweck nicht braucht.
• Excessive Permissions — die angebundenen Erweiterungen haben mehr Rechte, als die Aufgabe verlangt.
• Excessive Autonomy — es fehlt die unabhängige Prüfung und Freigabe für Aktionen mit hoher Wirkung.

Der wichtigste Satz aus den empfohlenen Gegenmaßnahmen ist der, der die Verantwortung verschiebt: Autorisierung gehört in die nachgelagerten Systeme, statt sie das Modell entscheiden zu lassen. Das ist mehr als eine Sicherheitsregel, es ist eine Architekturaussage. Ein Agent, dessen Grenzen nur im Prompt stehen, hat keine Grenzen, sondern eine Bitte.

Wann ein Agent das falsche Werkzeug ist

Die Fälle, in denen ein Agent die schlechtere Wahl ist, sind konkret benennbar. Sie tauchen in Reviews selten auf, weil sie nach Rückschritt klingen.

• Hohes Volumen, feste Aufgabe. 50.000 Klassifikationen am Tag in sechs Kategorien brauchen einen Aufruf, keine Schleife. Eine Schleife multipliziert Kosten und Latenz mit der Rundenzahl — für null zusätzliche Entscheidung.
• Harte Latenzzusage. Ein Agent hat eine Laufzeitverteilung mit langem Schwanz, weil die Rundenzahl variiert. Wo ein 95.-Perzentil zugesagt ist, sagt man über eine Verteilung zu, die man nicht steuert.
• Vorab bekannter Pfad. Wenn die Schritte im Ticket stehen, gehören sie in den Code. Ein Modell, das sie jedes Mal neu herleitet, ist eine Fehlerquelle mit Rechnung.
• Irreversible Wirkung ohne Kompensationsweg. Wenn eine Aktion nicht rückholbar ist und es keinen Kompensationsschritt gibt, ist Autonomie keine Design-Entscheidung, sondern ein offenes Risiko.
• Keine Evaluationsmöglichkeit. Wenn niemand sagen kann, wann ein Lauf gelungen ist, kann niemand eine Änderung freigeben. Dann ist die fehlende Evaluation das Projekt, nicht der Agent.

Ein sechster Fall verdient eine eigene Erwähnung, weil er nicht in Checklisten steht: der bereits gebaute Agent. Sobald die Schleife läuft, ist „wir haben schon einen Agenten“ ein Argument, das jede neue Aufgabe hineinzieht — auch die feste Klassifikation, die als einzelner Aufruf zehnmal billiger wäre. Der Zuschnitt gehört pro Aufgabe entschieden, nicht pro Team.

Der Preis der richtigen Wahl

Beide Entscheidungen haben einen Nachteil, und es hilft, ihn vorher zu benennen — sonst wird er später als Überraschung verkauft.

Umgekehrt gilt dasselbe: Wer sich für den Agenten entscheidet, kauft Anpassungsfähigkeit und zahlt mit Nichtdeterminismus, variabler Latenz, schwerer Reproduzierbarkeit im Fehlerfall und einer Kostenkurve, die an der Rundenzahl hängt. Beides ist vertretbar. Unvertretbar ist nur, den Preis nicht zu kennen.

Was der Check prüft

Die Übungen dieses Moduls prüfen keine Definitionen, sondern die Entscheidungen, die vor dem Bauen fallen.

• Ein System als Workflow oder Agent einordnen — am Kontrollfluss, nicht an der Selbstbeschreibung des Teams.
• Für eine gegebene Aufgabe das passende Muster wählen und begründen, warum die Alternative teurer ist.
• Einen Autonomie-Grad pro Aktionsklasse festlegen statt pro System.
• Kosten und Latenz einer Schleife am richtigen Treiber angreifen: fester Vorspann oder wachsender Verlauf.
• Einen Agenten prüfen, ohne einen exakten Pfad zu behaupten.
• Benennen, wann ein Agent das falsche Werkzeug ist — und wann eine getroffene Entscheidung neu zu prüfen ist.

Wer diese sechs Entscheidungen begründen kann, hat das teuerste Missverständnis dieses Feldes hinter sich: dass Autonomie ein Ziel wäre. Sie ist ein Tauschgeschäft, und die Aufgabe eines Ingenieurs ist es, den Kurs zu kennen.