Reasoning und Planning bei AI Agents

Definition: Wie denken und planen AI Agents?

Reasoning und Planning bei AI Agents beschreiben, wie ein KI-Agent denkt und handelt: Er durchläuft iterativ den Loop Perceive → Reason → Act → Observe — nimmt seine Umgebung wahr, schlussfolgert mit dem LLM, wählt eigenständig einen nächsten Schritt oder ein Tool, führt ihn aus, beobachtet das Ergebnis und passt seinen Plan an, bis das Ziel erreicht ist. Genau diese dynamische Steuerung durch das LLM — und nicht ein fest verdrahteter Ablauf — unterscheidet einen Agenten von klassischer Automatisierung.

Die drei Kernantworten vorweg:

• Reasoning ist die Schlussfolgerungsfähigkeit des LLM-Core: Welcher Schritt oder welches Tool ist als Nächstes sinnvoll? Hier wird entschieden, ob überhaupt ein Tool genutzt wird — und welches.
• Planning zerlegt ein Ziel in Teilschritte. Das kann implizit im LLM ablaufen oder explizit als Graph modelliert sein. Der Plan ist dabei kein einmaliger Fahrplan, sondern wird im Loop iterativ angepasst.
• Probabilistik bedeutet: Der Output ist nicht deterministisch reproduzierbar. Derselbe Input kann zu unterschiedlichen Pfaden führen — weshalb Tracing und Evals zwingend dazugehören.

Der Reasoning-Loop: Perceive → Reason → Act → Observe

Das Herzstück jedes Agenten ist ein iterativer Schleifenmechanismus. Konzeptionell geht er auf das ReAct-Muster (Yao et al. 2022, arXiv:2210.03629) zurück, das Reasoning und Acting im selben LLM-Loop verbindet: Der Agent denkt nicht nur nach und antwortet, sondern wechselt zwischen Überlegung und Handlung.

Der Loop läuft in vier Schritten:

1. Perceive — Der Agent nimmt Input und Ziel, den aktuellen Context und sein Memory wahr.
2. Reason — Das LLM plant: Welches Tool oder welcher Schritt ist als Nächstes sinnvoll?
3. Act — Der Agent führt die Aktion aus (Tool-Call, API-Aufruf, Code-Ausführung).
4. Observe — Der Agent liest das Ergebnis aus und schreibt es ins Memory.

Danach prüft der Agent: Ist das Ziel erreicht? Wenn nicht, beginnt der Loop erneut bei Perceive. Sicherheitsmechanismen wie Loop-Limits, Token-Budgets und Human-in-the-Loop-Punkte verhindern dabei endloses Schleifen oder irreversible Fehlhandlungen.

Ein konkretes Beispiel

Angenommen, ein Agent soll die Frage beantworten: „Wie hoch war der KI-Nutzungsanteil deutscher Unternehmen 2024 im Vergleich zu heute?"

• Reason: Das LLM erkennt, dass es zwei Werte aus einer verlässlichen Quelle braucht und keinen internen Faktenstand zitieren sollte. Es plant einen Such-Schritt.
• Act: Es ruft ein Such-Tool auf (web_search mit der Anfrage „Bitkom KI-Nutzung deutsche Unternehmen 2024").
• Observe: Es liest das Ergebnis — etwa, dass laut Bitkom 2024 erst 17 % der Unternehmen ab 20 Mitarbeitenden KI aktiv nutzten, 2026 hingegen 41 %.
• Reason (Iteration 2): Das LLM stellt fest, dass beide Werte vorliegen, und formuliert die Antwort statt eines weiteren Tool-Calls.

Ein Chatbot hätte die Frage in einem Schritt aus seinem Trainingswissen beantwortet — möglicherweise mit veralteten oder erfundenen Zahlen. Der Agent hingegen plant den Pfad dynamisch und beendet den Loop erst, wenn das Ziel erreicht ist.

Implizites vs. explizites Planning

Planning kann auf zwei Arten realisiert werden — die Wahl bestimmt, wie kontrollierbar und nachvollziehbar der Agent ist.

In der Praxis liegt der „Sweet Spot" für produktive B2B-Anwendungen zwischen L3 und L4: genug Autonomie, damit das LLM den Pfad dynamisch wählt, aber genug Struktur, um den Ablauf governen zu können. Der Planner zerlegt das Ziel, der Executor führt die Tool-Calls aus, managt die Turns sowie Loop-Limits und setzt die Guardrails durch.

Warum der Output probabilistisch ist — und was das bedeutet

Ein Agent baut auf einem (Large) Language Model auf, und LLMs erzeugen ihre Ausgabe probabilistisch: Sie sagen das jeweils nächste Token mit einer Wahrscheinlichkeit voraus. Daraus folgt eine zentrale, oft unterschätzte Konsequenz: Derselbe Input kann zu unterschiedlichen Reasoning-Pfaden und Ergebnissen führen. Ein Agent ist keine deterministische Pipeline.

Genau hier liegt einer der häufigsten Pitfalls: Agenten als deterministisch zu behandeln. Wer von einem Agenten die reproduzierbare Verlässlichkeit eines klassischen Skripts erwartet, plant falsch — und wird von Abweichungen, Fehlentscheidungen und schwankenden Kosten überrascht.

Die praktische Antwort darauf ist zweigeteilt:

• Tracing macht jeden Schritt des Loops sichtbar: Welche Reason-Entscheidung wurde getroffen, welches Tool aufgerufen, welches Observe-Ergebnis verarbeitet? Ohne diese Nachvollziehbarkeit bleibt der Agent eine Blackbox — und Fehlerursachen sind nicht auffindbar.
• Evals prüfen das Verhalten systematisch gegen erwartete Ergebnisse. Statt sich auf Outputs zu verlassen, misst man die Erfolgsquote über viele Durchläufe und erkennt Regressionen, bevor sie produktiv schaden.

Mehrere führende Frameworks adressieren das direkt: Das OpenAI Agents SDK etwa liefert Tracing als festen Bestandteil mit. Observability ist damit kein Add-on, sondern eine Grundvoraussetzung für produktive Agenten — fehlende Observability zählt zu den klassischen Projektfehlern.

Belegte Fakten zum Reifegrad

Dass Reasoning- und Planning-Architekturen noch jung und fehleranfällig sind, zeigt der Marktstand:

• Laut McKinsey State of AI 2025 skalieren erst 23 % der Unternehmen mindestens einen agentischen Use Case, weitere 39 % experimentieren — in keiner einzelnen Funktion liegt der Anteil skalierter Agenten jedoch über 10 %.
• Gartner (Juni 2025) prognostiziert, dass über 40 % der agentischen KI-Projekte bis Ende 2027 abgebrochen werden — häufig wegen unterschätzter Komplexität und Kosten.

Beide Zahlen unterstreichen, warum belastbares Reasoning, kontrolliertes Planning und durchgängige Observability über Erfolg oder „Pilot Purgatory" entscheiden.

Praxis: Reasoning-Loops absichern

Aus der Funktionsweise ergeben sich konkrete Leitplanken für den produktiven Einsatz:

• Loop-Limits und Token-Budgets setzen, um Endlosschleifen und Token-Kosten-Explosionen zu verhindern.
• Human-in-the-Loop für alle irreversiblen Aktionen vorsehen — der Agent plant, der Mensch gibt frei.
• Tracing von Tag 1 einbauen, nicht nachträglich. Nur so sind probabilistische Fehlentscheidungen überhaupt diagnostizierbar.
• Evals als laufenden Test gegen Outcome-KPIs etablieren, statt Erfolg nur punktuell zu beurteilen.
• Den Loop nur dort einsetzen, wo der Pfad nicht vorab planbar ist. Lässt sich der Ablauf vollständig modellieren, sind eine Workflow-Automation oder ein Copilot günstiger und robuster.

So wird aus einem theoretisch mächtigen, aber probabilistischen Reasoning-Loop ein governbares, nachvollziehbares System — die Grundlage dafür, dass ein Agenten-Projekt nicht zu den über 40 % zählt, die laut Gartner scheitern.