Für die Claude Foundations Prüfung ist „Planning“ kein theoretisches Extra, sondern ein Architekturhebel: Es entscheidet über Qualität, Kosten, Latenz und Fehlerrisiko. In der Praxis begegnen dir vor allem drei Muster: ReAct, Plan-then-Execute und Hybrid.
ReAct (Reason + Act) bedeutet: Das System denkt schrittweise, führt einen kleinen nächsten Schritt aus, beobachtet das Ergebnis, passt die Richtung an und macht weiter. Der Vorteil ist hohe Anpassungsfähigkeit bei unsicheren Aufgaben. Wenn Inputs unvollständig sind oder Tool-Antworten überraschend ausfallen, kann ReAct dynamisch reagieren. Der Nachteil: Es kann mehr Tool-Aufrufe verursachen, dadurch teurer und langsamer werden und bei schwachen Guardrails in Schleifen geraten. ReAct passt gut zu Exploration, Diagnose und offenen Problemräumen.
Plan-then-Execute trennt klar in zwei Phasen: Erst erstellt das System einen vollständigen Plan (z. B. Schritte, benötigte Tools, Validierung), danach arbeitet es ihn diszipliniert ab. Das ist nützlich für vorhersehbare, strukturierte Workflows: Reporting, Datenpipelines, Standard-Operations. Vorteile: bessere Nachvollziehbarkeit, geringere Varianz, oft weniger Token- und Tool-Kosten. Nachteil: Wenn die Realität vom Plan abweicht, ist das System weniger flexibel. Ohne Re-Planning kann es „stur“ falsche Wege weiterlaufen.
Hybrid kombiniert beide Welten: Ein grober Plan gibt Richtung und Kontrollpunkte vor, innerhalb einzelner Schritte darf ReAct adaptiv handeln. Typisch ist ein Pattern wie: „Plan → Execute Block A adaptiv → Checkpoint → ggf. Re-Plan → Execute Block B“. Für produktive Systeme ist Hybrid häufig der Sweet Spot, weil Governance und Flexibilität gleichzeitig möglich sind.
Prüfungsrelevant ist weniger, dass du Definitionen auswendig kennst, sondern dass du Pattern-Auswahl begründen kannst. Gute Begründungen nutzen vier Achsen:
1. Aufgabenunsicherheit (hoch = eher ReAct/Hybrid)
2. Compliance/Audit-Anforderungen (hoch = eher Plan-then-Execute/Hybrid)
3. Kosten- und Latenzbudget (eng = eher planvoll und begrenzt)
4. Fehlerfolgen (kritisch = mehr Checkpoints, Human Handoff, validierte Zwischenergebnisse)
Wichtig: Planning ist nie isoliert. Es hängt direkt mit Tool-Design zusammen. Idempotente Tools, klare Fehlermeldungen und typed Inputs machen jedes Pattern stabiler. Ebenso relevant: Stop-Kriterien. Besonders bei ReAct solltest du maximale Iterationen, Timeout und Fallback-Regeln definieren (z. B. „nach 3 fehlgeschlagenen Tool-Calls eskalieren“). Sonst steigt die Failure-Surface unnötig.
Ein häufiger Anti-Pattern im Exam-Kontext: Teams wählen ReAct „weil es smart wirkt“, obwohl der Prozess deterministisch ist. Das führt zu mehr Kosten ohne Qualitätsgewinn. Andersherum ist starres Plan-then-Execute bei hochdynamischen Datenquellen riskant. Die richtige Antwort ist fast immer kontextabhängig, aber argumentierbar.
Merksatz für die Prüfung: ReAct optimiert Anpassung, Plan-then-Execute optimiert Kontrolle, Hybrid optimiert Balance. Wenn du zusätzlich Guardrails, Re-Planning-Trigger und Validierungsschritte benennst, klingst du nicht nur korrekt, sondern architektonisch reif.
Du baust einen Agenten für Incident-Triage in einer Cloud-Umgebung. Logs sind unvollständig, Alerts ändern sich laufend, aber alle Entscheidungen müssen auditierbar sein. Welches Planning-Pattern ist am geeignetsten und warum?
Am sinnvollsten ist ein Hybrid-Pattern: Ein initialer Plan definiert feste Audit-Checkpoints, Eskalationsregeln und erlaubte Tools. Innerhalb jedes Analyse-Blocks darf der Agent ReAct-ähnlich auf neue Log-Hinweise reagieren. So bleiben Entscheidungen nachvollziehbar, ohne bei dynamischen Incident-Daten unflexibel zu werden.