Die Kernidee
Zieht man den Hype ab, besteht jeder Agent aus fünf Zeilen: plan → decide → call tool → observe → stop. Einen Agenten zu reviewen bedeutet, genau diese fünf Schritte zu prüfen – insbesondere Tool-Contracts, Idempotenz, Budgets und was zurück in den Kontext fließt. Frameworks, Multi-Agent-Topologien, „Planner“ – all das sind nur Ausarbeitungen dieser fünf Zeilen.
Deep Dive
Der Fünf-Zeilen-Loop
Jeder Agent – egal wie schick verpackt – führt im Kern eine Variante hiervon aus:
``` state = plan(goal) while not done(state) and within_budget(state): action = decide(state) result = call_tool(action) state = observe(state, result) stop(reason = goal_met | budget_hit | timeout | error_floor) ```
Das ist schon alles. Wenn du über Frameworks, Orchestratoren oder Planner-Worker-Splits liest, geht es letztlich um Gerüste, die auf genau diesem Schema aufbauen.
Die praktische Konsequenz: Versteckt dein Framework diese fünf Schritte hinter Abstraktionen, verschwindet damit auch deine Review-Oberfläche. Wisse genau, welche Zeile in deiner Codebase welchem Schritt entspricht.
Die vier Dinge, die du wirklich überprüfst
Wenn du einen Agenten auditierst, prüfst du eigentlich nur vier Dinge – alles andere ist Nebensache.
**1. Tool-Contracts.** Jedes Tool ist eine typisierte Funktion: Name, Eingabe-Schema, Ausgabe-Schema, Fehlermodi und ob es Seiteneffekte hat. Dein MCP-Server bildet genau diese Vertragsschicht ab. Ist der Contract uneindeutig, füllt das Modell die Lücke mit Vermutungen.
**2. Idempotenz bei Seiteneffekten.** Jedes verändernde Tool (mutating) benötigt einen Idempotenz-Schlüssel (eine vom Client generierte Request-ID, anhand derer der Server dedupliziert) oder einen Check-then-Act-Guard. Read-only-Tools brauchen das nicht. Alles, was Geld ausgibt, hingegen zwingend.
**3. Budgets.** Harte Obergrenzen für Schritte, Tokens, Laufzeit (Wall-Clock) und Dollarausgaben – durchgesetzt im Code, nicht in Prompts. „Bitte stoppe nach 10 Schritten“ ist eine Bitte. `if steps > 10: halt` ist eine echte Kontrolle.
**4. Der Observe-Schritt.** Was tatsächlich zurück in den Kontext gefaltet wird, ist ein bewusst gestaltetes Artefakt. Rohe API-Dumps begraben das Signal. Zu stark zusammengefasste Ergebnisse verbergen den Fehler, den das Modell eigentlich sehen müsste. Keine der beiden Extrempositionen ist standardmäßig sicher.
Framework-Wahl – worauf es wirklich ankommt
Debatten über Frameworks schlucken enorm viel Energie. Hier ist, was dir die jeweilige Wahl wirklich bringt:
**Graph-basiert (LangGraph-Archetyp)** funktioniert hervorragend für explizite State Machines und Interrupts zur menschlichen Freigabe. Du übernimmst deren State-Modell und Debugging-Oberfläche – musst dich aber auch auf deren Denkmodell einlassen.
**Typisierte Agenten (Pydantic AI-Archetyp)** passen perfekt zu einer Kultur des lückenlosen Prüfens: Contracts als Typen, Validierung an den Schnittstellen, minimale Magie. Ideal, wenn du einem Kunden jede einzelne Komponente erklären willst.
**Crew-/Rollen-Frameworks** sind auf Multi-Agent-Rollenspiele optimiert. Überspringe sie, bis du einen nachgewiesenen Bedarf an Multi-Agenten hast – was seltener vorkommt, als das Marketing suggeriert.
**SDK-direkt** sind rund 150 Zeilen, die komplett dir gehören. Für Consultants oft das perfekte v1, wenn das Verkaufsargument lautet: „Ich kann jede einzelne Zeile erklären.“
Eine Entscheidung macht jedoch wirklich einen Unterschied: Alle ernstzunehmenden Frameworks sprechen MCP inzwischen nativ. Baue deine Tools einmal, und du kannst die Loop-Struktur jederzeit flexibel austauschen. Die heiklen Entscheidungen liegen in der Tool-Oberfläche, nicht im Framework-Auswahlmenü.
Ausführung & Setup
- Die Tool-Oberfläche ist die Sicherheitsgrenze. Jede gefährliche Aktion muss schlicht unmöglich aufzurufen sein, nicht bloß im Prompt entmutigt werden. Wenn eine Aktion nicht passieren darf, sollte sie als aufrufbares Tool gar nicht erst existieren.
- Idempotenz bei jedem mutierenden Tool. Ein Idempotency-Key oder Check-then-Act-Guard existiert für alles, was Geld kostet, Daten schreibt oder Nachrichten versendet. Retries sind der Regelfall, keine Ausnahme.
- Vier Budgets, im Code erzwungen. Schritte, Laufzeit, Token-Verbrauch und Dollar-Kosten haben alle harte, im Code geprüfte Obergrenzen mit einem definierten Abbruchgrund bei Überschreitung.
- Der Observe-Schritt ist ein durchdachtes Artefakt. Was wieder in den Kontext gelangt, ist eine explizite Reduktion, kein Raw-Dump und keine verlustbehaftete Zusammenfassung. Rohe Ergebnisse werden im Trace archiviert, unabhängig davon, was das Modell sieht.
- Jeder Abschluss wird mit Begründung protokolliert. goal_met, budget_exhausted, timeout und error_floor sind in den Logs klar unterscheidbar – „hat einfach gestoppt“ ist kein akzeptabler Endzustand.
Aus der Praxis
Aufgabe: „Prüfe dieses Werbekonto und schlage Budget-Umschichtungen vor (nicht ausführen).“ Spezifiziere den Loop vor dem Code – Tool-Oberfläche: get_campaigns, get_ad_performance(range), get_audience_breakdown (alle read-only). propose_change(doc) schreibt in eine Vorschlagstabelle, nicht in die Ads-API – der Loop kann physisch kein Geld ausgeben. Budgets: max. 15 Tool-Calls, 60 s Laufzeit (Wall-Clock), 0,50 $ Modellausgaben; bei Überschreitung Abbruch mit budget_exhausted. Observe-Schritt: Performance-Antworten werden auf (campaign, spend, conversions, CPL, Δ vs prior period) reduziert, bevor sie wieder in den Kontext fließen; das rohe JSON bleibt im Trace. Stop-Bedingung: Modell ruft finish(report) auf – das Beenden ist selbst ein Tool-Call, erscheint also im Trace und kann evaluiert werden. Die riskante Entscheidung – was der Loop überhaupt tun darf – wurde im Code getroffen, bevor das Modell auch nur ein einziges Token gesehen hat.
Wann du es nicht nutzen solltest
Lässt sich der Workflow im Vorfeld klar definieren, handelt es sich um eine Pipeline, nicht um einen Agenten. n8n erledigt das deterministisch zu einem Bruchteil der Kosten und ganz ohne Review-Aufwand. Der häufigste Overengineering-Fehler in aktuellen Kundenprojekten ist es, einen Agenten auszuliefern, obwohl ein Drei-Knoten-Workflow die ehrlichere Lösung gewesen wäre. Eine nützliche Zwischenform: ein Workflow mit einem einzelnen agentischen Knoten – deterministisch überall dort, wo Determinismus möglich ist, und ein abgegrenzter LLM-Schritt dort, wo er nötig ist. Der Standard sollte Single-Agent sein; Multi-Agent nur bei (a) Context-Sharding, wenn ein einzelnes Fenster nicht alles fassen kann, oder (b) echt unterschiedlichen Tool-Berechtigungen pro Rolle (Analyst vs. Executor als Sicherheitsarchitektur, nicht als Architektur-Modeerscheinung).
Stolperfallen und Learnings
- Sicherheit rein über den Prompt. „Modifiziere niemals Live-Kampagnen“ im System-Prompt, während das mutierende Tool weiterhin bereitgestellt wird. Die Tool-Oberfläche ist die Sicherheitsgrenze; der Prompt ist nur eine Empfehlung.
- Nicht-idempotente Retries. Timeout → Framework versucht es erneut → doppelter Seiteneffekt. Symptom: „Manchmal wurde das doppelt angelegt.“
- Context Flooding. Rohantworten werden unverändert angehängt; ab Schritt 8 findet das Modell seinen eigenen Plan nicht mehr. Symptom: Die Qualität sinkt mit zunehmender Loop-Länge.
- Fehlende Budgets. Funktioniert in der 3-Schritte-Demo problemlos, eskaliert aber in der Produktion, wenn ein problematischer Account plötzlich 200 Schritte erzeugt.
- Nicht nachvollziehbare Abbrüche. Der Loop „stoppt einfach“ ohne Reason-Code – in den Logs lässt sich nicht erkennen, ob das Ziel erreicht oder einfach aufgegeben wurde.
- Die Tool-Oberfläche ist die Sicherheitsgrenze; Prompts sind bloß Empfehlungen.
- Mutierende Tools erfordern Idempotency-Keys oder Check-then-Act-Guards.
- Budgets existieren im Code als vier Obergrenzen: Schritte, Tokens, Laufzeit und Kosten.
- Jeder Abschluss ist ein Tool-Call, damit du ihn im Trace nachvollziehen und auswerten kannst.
Mach dich an die Arbeit
Ziel: Schreibe eine vollständige Spezifikation für einen Agent-Loop auf einer echten MCP-Tool-Oberfläche. Unterziehe sie anschließend einem Stresstest, indem du sie einer KI übergibst und den generierten Loop Zeile für Zeile mit deiner eigenen Spezifikation abgleichst. (60 Min.)
- Liste jedes Tool auf und kennzeichne es als lesend (read) oder mutierend (mutating). Notiere den Namen jedes Tools, sein Eingabeschema, das Ausgabeformat und ob es Seiteneffekte hat. Halte für jedes mutierende Tool fest, ob es von Natur aus idempotent ist (also gefahrlos zweimal mit denselben Eingaben aufgerufen werden kann) oder einen Idempotency-Key benötigt.
- Entwirf die Reduktionsregel für den Observe-Schritt jedes Tools. Definiere für die Rohausgabe jedes Tools genau die Reduktion, die wieder in den Kontext zurückfließt – welche Felder erhalten bleiben, welche verworfen werden und wo die Rohantwort für den Trace archiviert wird.
- Definiere alle vier Budgets als im Code erzwungene Obergrenzen. Lege maximale Schritte (max steps), maximale Laufzeit (wall-clock time), maximale Kosten in Dollar und maximale Tokens fest. Bestimme das genaue Abbruchverhalten und den Reason-Code für das Erreichen jeder Obergrenze.
- Definiere jede Abbruchbedingung mit einem eindeutigen Reason-Code. Liste alle Möglichkeiten auf, wie der Loop enden kann: goal_met, budget_exhausted, timeout, error_floor, user_cancelled. Jede davon sollte später in einem Trace eindeutig unterscheidbar sein.
- Generiere den Loop anhand deiner Spezifikation mit einer KI und vergleiche ihn Zeile für Zeile. Übergib deine schriftliche Spezifikation an einen KI-Assistenten und bitte ihn, das Loop-Harness zu implementieren. Übernimm den Code nicht blind – gehe ihn durch und markiere jede Stelle, an der er von deiner Spezifikation abweicht.
- Schreibe ein kurzes Review-Memo (einen Absatz). Fasse zusammen, was die KI richtig gemacht hat, was sie übersehen hat und was du geändert hast, bevor du den Code akzeptiert hast. Dieses Memo dient als Beleg für deine professionelle Review-Disziplin, wie du sie auch Kund:innen vorlegen würdest.
Ergebnis: Eine schriftliche Agent-Loop-Spezifikation (Tool-Tabelle, Observe-Regeln, Budgets, Abbruchbedingungen) plus die KI-generierte Implementierung und ein Diff-Memo mit jeder Abweichung, die du gefunden und behoben hast.
Quellen
- Anthropic, "Building Effective Agents" (engineering blog, 2024)
- OpenAI, "A Practical Guide to Building Agents" (2024)
- Model Context Protocol specification, modelcontextprotocol.io
- LangGraph documentation, "Human-in-the-loop" and state persistence guides