Deep Dive: Agentic AI Patterns – Planner/Executor, ReAct, Toolformer‑Style

KI-Agenten scheitern selten am Modell allein. Häufiger scheitern sie an einer banalen Architekturfrage: Wer plant, wer handelt, und wer reagiert auf Rückmeldungen, wenn die Umgebung nicht mitspielt? Genau an diesem Punkt entscheiden Patterns darüber, ob ein Agent stabil arbeitet, unnötig Budget verbrennt oder mit viel Selbstvertrauen in die falsche Richtung läuft.

Für Entwickler ist das keine akademische Sortierhilfe. Planner/Executor, ReAct und Toolformer-ähnliche Werkzeugnutzung stehen für drei verschiedene Betriebsmodelle. Die praktische Frage dahinter lautet immer gleich: Braucht die Aufgabe einen belastbaren Plan, eine Schleife mit Feedback oder nur einen präzisen Tool-Aufruf im richtigen Moment?

Pattern 1: Planner/Executor – erst zerlegen, dann ausführen

Beim Planner/Executor-Pattern wird die kognitive Arbeit aufgeteilt. Ein Planner zerlegt die Aufgabe in Schritte, ein Executor arbeitet sie anschließend mit Tools, Skripten oder APIs ab.

┌─────────────┐      ┌─────────────┐
│   Planner   │─────▶│   Executor  │
│  (LLM)      │      │  (Tools)    │
└─────────────┘      └─────────────┘
       │                      │
  „Zerlege die Aufgabe“   „Führe die Schritte aus“

Der Vorteil liegt in der Trennung der Rollen. Planung und Ausführung vermischen sich nicht, wodurch Abläufe leichter prüfbar, protokollierbar und wiederholbar werden. Das ist vor allem dann nützlich, wenn ein Team nachvollziehen muss, warum ein Agent bestimmte Schritte gewählt hat.

Die Kehrseite ist Starrheit. Sobald sich Eingaben, Datenlage oder Randbedingungen während der Ausführung ändern, kann ein sauberer Plan schnell veralten. Dann arbeitet der Executor zwar ordentlich, aber am aktuellen Problem vorbei.

Praxisbeispiel

In agentischen Frameworks lässt sich dieses Muster so modellieren, dass zunächst ein strukturierter Plan entsteht und dieser danach abgearbeitet wird. Das folgende Beispiel ist illustrativ und kein direkt lauffähiges Snippet:

agent:
  name: "research_assistant"
  planner:
    model: "gpt-4o-mini"
    output_format: "json_steps"
    max_steps: 10
  executor:
    tools:
      - web_search
      - pdf_analyze
      - summarize

Planner/Executor passt gut zu Aufgaben, deren Ablauf früh erkennbar ist: Recherchepipelines, Berichte, Freigabeprozesse oder mehrstufige Transformationen. Der operative Gewinn ist weniger Kreativität als Vorhersagbarkeit.

Pattern 2: ReAct – handeln, beobachten, nachsteuern

ReAct steht für Reasoning und Acting. Laut IBM und Google Cloud gehört dieses Muster zu den etablierten Architekturen für Agentensysteme. Der Agent arbeitet nicht nach einem einmal festgelegten Plan, sondern in Schleifen: Er bewertet die Lage, führt eine Aktion aus, beobachtet das Ergebnis und entscheidet daraus den nächsten Schritt.

┌─────────────────────────────────────┐
│ 1. Denken: Was ist das Ziel?        │
│ 2. Handeln: Tool-Aufruf             │
│ 3. Beobachten: Ergebnis             │
│ 4. Wiederholen bis zum Ziel         │
└─────────────────────────────────────┘

ReAct ist stark, sobald der nächste sinnvolle Schritt erst unterwegs sichtbar wird. Das gilt für Browser-Automation, Fehlersuche, UI-Inspektion oder Recherchen, bei denen ein Treffer erst neue Fragen erzeugt.

Der große Vorteil ist Anpassungsfähigkeit. Wenn ein Tool-Aufruf fehlschlägt oder ein Ergebnis nicht trägt, kann der Agent umsteuern, statt einen inzwischen schlechten Plan stumpf weiter auszuführen. In unruhigen Umgebungen ist das oft robuster als ein formal sauberer, aber zu früh festgelegter Ablauf.

Der Preis ist Laufzeit. Jeder zusätzliche Denk-, Aktions- und Beobachtungsschritt kostet Tokens, Zeit und Kontextfenster. Ohne harte Grenzen wird aus einem flexiblen Agenten schnell ein teurer Agent, der vor allem mit sich selbst beschäftigt ist.

Praxisbeispiel

In Frameworks mit Tool-Unterstützung lässt sich ReAct als sichtbare Schleife modellieren: Der Agent formuliert vor jedem Tool-Aufruf seine Absicht, führt die Aktion aus und bewertet danach die Rückmeldung.

loop:
  - reason: "Bestimme den nächsten sinnvollen Schritt."
  - act: "Rufe ein passendes Tool auf."
  - observe: "Bewerte das Ergebnis des Tool-Aufrufs."
  - decide: "Fortfahren, korrigieren oder abschließen."

Der kritische Punkt ist nicht die Syntax, sondern die Betriebsdisziplin: klare Abbruchbedingungen, begrenzte Iterationen und nachvollziehbare Zwischenschritte. Fehlen diese Leitplanken, kippt ReAct schnell von adaptiv zu unkontrolliert.

Pattern 3: Toolformer-Ansatz – Werkzeuge direkt im Sprachfluss

Der Toolformer-Ansatz geht laut Meta-Forschung in eine andere Richtung. Hier steht nicht zwingend eine sichtbare Reasoning-Schleife im Zentrum. Stattdessen wird Werkzeugnutzung enger in die Textgenerierung eingebettet: Das Modell erkennt, wann ein externer Aufruf sinnvoll ist, und erzeugt dafür eine definierte Syntax.

Ein System kann dem Modell etwa per Training oder Prompting beibringen, Sequenzen wie [CALC] 2+2 [/CALC] auszugeben. Die Laufzeitumgebung erkennt den Marker, führt das Werkzeug aus und schreibt das Ergebnis zurück in den Kontext.

Der Vorteil ist Effizienz. Wenn Aufrufe klein, häufig und formal gut definiert sind, muss nicht jede Aktion von einer ausführlichen Denkschleife begleitet werden. Das spart Tokens und hält einfache Hilfswerkzeuge schnell.

Die Schwäche liegt in der Fehlertoleranz. Toolformer-ähnliche Muster funktionieren vor allem dort gut, wo Syntax, Parameter und erwartetes Verhalten eng beschrieben sind. Schon kleine Abweichungen können zu Parsing-Fehlern oder missverständlichen Aufrufen führen.

Praxisbeispiel

In der Praxis lässt sich dieser Ansatz über präzise Tool-Definitionen oder Skills nachbauen. Entscheidend ist, dass das System ein enges Protokoll vorgibt.

tools:
  - name: "calculator"
    description: "Berechnet mathematische Ausdrücke. Syntax: calc(expression)."
    pattern: "calc\\((.*?)\\)"

Wenn das Modell calc(2+2) erzeugt, kann die Laufzeit den Aufruf abfangen, ausführen und das Ergebnis zurückgeben. Für kleine, klar begrenzte Hilfswerkzeuge ist das oft die schlankste Lösung.

Welches Pattern passt zu welcher Aufgabe?

Muster	Geeignet für	Weniger geeignet für
Planner/Executor	Aufgaben mit klaren, vorhersehbaren Schritten, etwa ETL-Prozesse oder Report-Erstellung.	Dynamische Umgebungen, in denen sich Bedingungen während der Ausführung ändern.
ReAct	Exploration, Fehlersuche und Umgebungen mit Feedback-Loop, etwa Browser-Automation.	Hochfrequente, repetitive Aufgaben mit knappem Latenz- oder Kostenbudget.
Toolformer-Ansatz	Domänen mit festen Tool-Sets und vorhersehbaren Aufrufen, etwa einfache Berechnungen oder Datenabfragen.	Aufgaben, die flexible Tool-Auswahl oder kreative Abweichungen erfordern.

Die eigentliche Auswahlfrage

In der Praxis geht es selten darum, welches Pattern eleganter aussieht. Entscheidend ist, welches Fehlverhalten man sich leisten kann.

1. Ist der Ablauf vorab gut planbar? Dann spricht viel für Planner/Executor.
2. Muss der Agent auf Rückmeldungen reagieren? Dann ist ReAct meist robuster.
3. Sind Tool-Aufrufe klein, häufig und syntaktisch stabil? Dann lohnt sich ein Toolformer-ähnlicher Ansatz.

Dazu kommt eine vierte, oft wichtigere Frage: Was kostet falsche Autonomie? Spätestens an diesem Punkt werden Validierung, Protokollierung und Abbruchbedingungen wichtiger als die Pattern-Namen selbst. Gerade ReAct-Schleifen brauchen harte Leitplanken, damit der Agent nicht länger iteriert, als sein Ergebnis wert ist.

Fazit: Patterns sind Betriebsentscheidungen

Diese Muster schließen sich nicht aus. In produktiven Systemen entstehen oft Hybride: Ein Planner setzt den groben Ablauf, ein Executor arbeitet kritische Stellen in einer ReAct-Schleife ab, und kleine Standardaktionen laufen über eng definierte Werkzeugaufrufe.

Der Leserwert liegt deshalb nicht in der Taxonomie, sondern in der Architekturentscheidung. Wer früh sauber trennt, wann geplant, wann reagiert und wann nur ein Werkzeug präzise aufgerufen werden soll, baut Agenten, die nachvollziehbarer, günstiger und wartbarer bleiben. Für viele Teams ist ein begrenzter ReAct-Ablauf der pragmatische Einstieg. Sobald Auditierbarkeit, Zuverlässigkeit oder Skalierung wichtiger werden, lohnt sich der Schritt zu einer klareren Planner/Executor-Struktur.