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

KI-Agenten sind mehr als große Sprachmodelle mit API-Zugriff. Ihre Leistungsfähigkeit hängt vor allem davon ab, wie sie Aufgaben zerlegen, Entscheidungen treffen und Werkzeuge einsetzen. Drei Architektur­muster helfen dabei besonders: Planner/Executor, ReAct und Toolformer-ähnliche Werkzeugnutzung.

Dieser Deep Dive ordnet die Patterns ein, zeigt typische Einsatzgebiete und skizziert, wie sie sich in agentischen Frameworks wie OpenClaw oder vergleichbaren Systemen modellieren lassen. Für die praktische Seite passen dazu unser Blick auf OpenClaw als Agentenbetrieb und die Einordnung zu Browserbase als Remote-Browser für OpenClaw.

Pattern 1: Planner/Executor – Planung und Ausführung trennen

Beim Planner/Executor-Pattern wird die kognitive Arbeit aufgeteilt. Der Planner zerlegt eine Aufgabe in Schritte und erstellt einen Ablaufplan. Der Executor führt diese Schritte anschließend aus, etwa durch Tool-Aufrufe, Skripte oder API-Interaktionen.

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

Stärken und Grenzen

Ein wesentlicher Vorteil liegt in der klaren Trennung der Verantwortlichkeiten. Der Planner kann Abhängigkeiten, Reihenfolgen und Zwischenziele berücksichtigen, ohne sich direkt mit jedem Tool-Detail zu befassen. Einmal erzeugte Pläne lassen sich zudem prüfen, protokollieren und für ähnliche Aufgaben wiederverwenden.

Die Grenze liegt in der Starrheit. Wenn sich während der Ausführung Rahmenbedingungen ändern, kann der ursprüngliche Plan schnell veralten. Für sehr einfache Aufgaben erzeugt das Muster außerdem unnötigen Overhead.

Praxisbeispiel

In agentischen Frameworks lässt sich dieses Muster abbilden, indem ein Agent zunächst einen strukturierten Plan erzeugt und ein zweiter Schritt diesen Plan ausführt. Die folgenden Beispiele sind bewusst vereinfachte Pseudokonfigurationen, keine direkt lauffähigen Framework-Snippets. Eine illustrative Konfiguration kann so aussehen:

# Beispiel-Konfiguration für einen Planner/Executor-Agenten
agent:
  name: "research_assistant"
  planner:
    model: "gpt-4o-mini"
    output_format: "json_steps"
    max_steps: 10
  executor:
    tools:
      - web_search
      - pdf_analyze
      - summarize

Pattern 2: ReAct – Denken und Handeln im Wechsel

ReAct steht für Reasoning und Acting. Laut IBM und Google Cloud gehört dieses Muster zu den gängigen Architekturen für Agentensysteme. Der Agent arbeitet in Schleifen: Er analysiert die Situation, führt eine Aktion aus, beobachtet das Ergebnis und entscheidet dann über den nächsten Schritt.

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

ReAct eignet sich besonders für dynamische Umgebungen, etwa Browser-Automation, Fehlersuche oder Rechercheprozesse, bei denen das nächste sinnvolle Vorgehen erst nach einer Beobachtung feststeht.

Stärken und Grenzen

ReAct ist anpassungsfähig. Wenn ein Tool-Aufruf fehlschlägt, kann der Agent das Ergebnis auswerten und eine alternative Route wählen. Dadurch wirkt das Muster robust in Situationen, die nicht vollständig vorab planbar sind.

Der Nachteil ist der Ressourcenverbrauch. Jeder zusätzliche Denk- und Beobachtungsschritt benötigt Kontext, Tokens und Zeit. Bei Aufgaben mit vielen Iterationen können Kosten und Latenz deutlich steigen.

Praxisbeispiel

In Frameworks mit Tool-Unterstützung lässt sich ReAct über eine klare Schleifenstruktur modellieren: Vor jedem Tool-Aufruf beschreibt der Agent kurz seine Absicht, führt die Aktion aus und bewertet anschließend die Rückmeldung.

# Illustratives ReAct-Schema
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."

So bleibt nachvollziehbar, warum ein Agent ein Werkzeug nutzt und wie er auf unerwartete Ergebnisse reagiert.

Pattern 3: Toolformer-Ansatz – Werkzeugnutzung im Sprachfluss

Der Toolformer-Ansatz geht auf Forschung von Meta zurück. Dabei lernt ein Modell, wann und wie externe Werkzeuge wie Rechner, Suchfunktionen oder Kalender genutzt werden. Anders als bei ReAct steht nicht zwingend eine sichtbare Denk-Schleife im Mittelpunkt; der Tool-Aufruf wird stärker in die Generierung integriert.

Ein Modell kann etwa darauf trainiert oder per Prompting instruiert werden, Tool-Aufrufe in einer festen Syntax auszugeben, zum Beispiel [CALC] 2+2 [/CALC]. Das System erkennt diese Sequenz, führt das Werkzeug aus und stellt das Ergebnis wieder im Kontext bereit.

Stärken und Grenzen

Die Integration ist effizient, weil nicht jeder Werkzeugaufruf einen ausführlichen Reasoning-Schritt benötigt. Für klar abgegrenzte Aufgaben mit stabiler Syntax kann das sehr schlank sein.

Die Kehrseite ist die geringe Flexibilität. Toolformer-ähnliche Systeme funktionieren vor allem mit festen Werkzeugen und klaren Mustern. Weicht die Ausgabe von der erwarteten Syntax ab, können Parsing-Fehler entstehen.

Praxisbeispiel

Toolformer-ähnliche Abläufe lassen sich durch präzise Skill- oder Tool-Definitionen abbilden. Entscheidend ist, dass Syntax und erwartete Parameter eindeutig beschrieben sind.

# Beispiel-Skill-Definition, illustrativ
tools:
  - name: "calculator"
    description: "Berechnet mathematische Ausdrücke. Syntax: calc(expression)."
    pattern: "calc\\((.*?)\\)"

Erkennt das System calc(2+2) im generierten Text, kann es die Ausführung pausieren, die Berechnung durchführen und das Ergebnis wieder in den Kontext einfügen.

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.

Umsetzung in der Praxis

Die Wahl des Patterns sollte sich an der Aufgabe orientieren, nicht am Framework. Drei Leitfragen helfen bei der Entscheidung:

1. Ist der Ablauf vorab gut planbar? Dann bietet sich Planner/Executor an.
2. Muss der Agent auf Feedback reagieren? Dann ist ReAct oft robuster.
3. Sind Tool-Aufrufe klein, häufig und syntaktisch stabil? Dann kann ein Toolformer-ähnlicher Ansatz effizient sein.

In produktiven Systemen ist außerdem wichtig, Tool-Ausgaben zu validieren, Zwischenschritte zu protokollieren und Abbruchbedingungen klar zu definieren. Gerade ReAct-Schleifen brauchen Grenzen, damit Agenten nicht unnötig lange iterieren.

Fazit: Patterns als Baukasten

Agentic-AI-Patterns schließen sich nicht gegenseitig aus. Häufig entstehen hybride Architekturen: Ein Planner erstellt einen groben Ablauf, ein Executor führt kritische Schritte im ReAct-Stil aus, und einfache Berechnungen laufen über Toolformer-ähnliche Spezialwerkzeuge.

Patterns sind keine Magie, sondern Baupläne für wartbare Agentenlogik. Ein bewährter Einstieg ist oft ein einfacher ReAct-Ablauf. Wenn Anforderungen an Zuverlässigkeit, Nachvollziehbarkeit und Skalierbarkeit steigen, lohnt sich der Wechsel zu einer klareren Planner/Executor-Struktur.