Multi-Modell-Workflow mit Dynamic Agents

Ein Dynamic Agent / DeepAgent muss nicht alles mit einem Modell lösen. Wer die Arbeit auf drei Rollen aufteilt, baut bessere Software. Ein teures Modell plant. Ein günstiges Modell schreibt den Code. Ein Modell aus einer fremden Familie prüft adversarial. Dieser Beitrag zeigt den Workflow anhand einer echten Session – inklusive eines Bugs, den erst der fremde Reviewer fand.

Was ist ein Dynamic Agent?

Ein Dynamic Agent – auch Deep Agent genannt – ist ein KI-System, das seine eigenen Arbeitsschritte zur Laufzeit bestimmt. Beide Begriffe meinen dasselbe: Der Agent plant, ruft Werkzeuge auf, liest Ergebnisse und entscheidet den nächsten Schritt selbst. Eine Coding Harness wie Claude Code ist ein Beispiel: Sie liest Dateien, schreibt Code, ruft Tools auf, führt Tests aus und startet weitere Agenten.

Der Unterschied zu einem starren Skript: Der Ablauf steht nicht fest. Der Agent reagiert auf das, was er findet.

Genau hier setzt der Multi-Modell-Workflow an. Denn nicht jeder Schritt braucht dasselbe Modell.

Das Prinzip: drei Modelle, drei Rollen

Ein einzelnes Modell für alles ist teuer oder schwach. Die bessere Antwort ist Arbeitsteilung. Drei Rollen, drei Modelle:

Rolle	Aufgabe	Modell im Beispiel
Planer / Orchestrator	Aufgabe zerlegen, Reihenfolge festlegen, Sub-Agents steuern	Fable (teuer)
Implementierer	Code schreiben, Tests grün machen	Opus 4.8 (günstiger)
Reviewer	Fehler finden, adversarial prüfen	OpenAI Codex / GPT-5 (fremde Familie)

Das teure Modell trifft die teuren Entscheidungen. Das günstige Modell macht die Fleißarbeit. Der fremde Reviewer bricht den blinden Fleck des Implementierers auf.

Die folgenden Zahlen stammen aus einer echten Session: 57 Tasks, 16 Slices, mehr als 20 Workflow-Läufe. Kein Lehrbuch, sondern gebaute Software.

Schritt 1: Planung mit dem teuren Modell

Am Anfang steht der Plan. Diese Phase entscheidet über alles Weitere. Ein schlechter Plan kostet später zehnfach.

Deshalb übernimmt hier das teuerste Modell: Fable. Es zerlegt das Ziel in Tasks und Slices, legt Abhängigkeiten fest und schreibt einen Plan, den jeder Sub-Agent mit frischem Kontext lesen kann.

Ein Beispiel aus der Praxis ist der Expansion-Plan eines meiner Projekte. Er wurde nicht nur geschrieben, sondern vor der ersten Zeile Code extern gegengelesen. Im Plandokument steht:

„Ein externes Zweit-Review (Codex/gpt-5.5, 2026-07-02) ist eingearbeitet.“

Das ist wichtig: Der adversarial Review beginnt nicht beim Code. Er beginnt beim Plan. Ein Fehler im Plan ist teurer als ein Fehler in einer Funktion.

Das teure Modell plant. Das teure Review härtet den Plan. Erst dann geht es los.

Schritt 2: Advisor-Pattern – Implementierung mit Opus 4.8

Jetzt kommt das Advisor-Pattern. Der Planer bleibt der Berater im Hintergrund. Die eigentliche Umsetzung übernimmt ein günstigeres, aber starkes Modell: Opus 4.8.

Der Aufbau ist klar geregelt:

• Ein Implementierer pro Task. Jeder startet mit frischem Kontext. Kein Modell schleppt Ballast aus anderen Tasks mit.
• Der Implementierer committet nicht. Er schreibt Code und macht Tests grün. Das Zusammenführen bleibt beim Orchestrator.
• Self-Healing intern, maximal fünf Runden. Bricht ein Test, analysiert der Agent den Fehler selbst und fixt ihn. Nach fünf Runden ohne Erfolg wird der Task als blocked markiert.

Warum das günstige Modell für die Fleißarbeit? Weil Code schreiben und Tests grün machen ein enges, gut definiertes Problem ist. Der Plan gibt die Richtung vor. Opus 4.8 füllt sie aus – schnell und in großer Zahl parallel.

Das spart Geld, ohne Qualität zu kosten. Die Qualität sichert der nächste Schritt.

Schritt 3: Adversarial Review mit OpenAI Codex

Der Implementierer prüft seinen eigenen Code schlecht. Er hat die gleichen Annahmen, die den Bug erst erzeugt haben. Deshalb braucht es einen zweiten Blick.

Diesen Blick liefert das Skill skill-codex. Es delegiert den Review an das OpenAI Codex CLI, also an ein Modell einer anderen Familie (GPT-5.4, GPT-5.5). Der Review läuft strikt lesend:

codex exec --sandbox read-only --skip-git-repo-check "<review prompt>" </dev/null 2>/dev/null

Installiert wird es in zwei Zeilen:

/plugin marketplace add skills-directory/skill-codex 
/plugin install skill-codex@skill-codex

Warum eine fremde Modellfamilie?

Man könnte den Review auch mit einem Anthropic-Modell wie Sonnet 5 fahren. Das funktioniert, und im selben Projekt lief genau das für viele Slices: Opus baut, Sonnet 5 prüft, Opus fixt. Sonnet fand dabei ernste Fehler – dazu gleich mehr.

Aber ein Modell aus einer fremden Familie hat einen eigenen Vorteil. Es wurde anders trainiert, es hat andere blinde Flecken und es findet anders strukturierte Fehler.

Ein Anthropic-Modell und sein Anthropic-Reviewer teilen sich einen Teil ihrer “Denkmuster”. Ein GPT-5-Reviewer nicht. Er stolpert über Dinge, die zwei verwandte Modelle beide übersehen.

Das ist keine Theorie, wie der nächste Abschnitt zeigt.

Der Bug, den nur die fremde Familie fand

Ein Task betraf die Funktion normalize_profile_url() in dm_identity.py. Sie soll LinkedIn-Profil-URLs vereinheitlichen. Ein relativer Pfad wie /in/bob soll zur vollen URL https://www.linkedin.com/in/bob werden, damit er sich mit dem eigenen Profil vergleichen lässt.

Opus 4.8 schrieb diese Bedingung:

if not parsed.scheme or not parsed.netloc:
    # als LinkedIn-Profil behandeln

Die Tests waren grün. Der Code sah harmlos aus. Opus übersah den Fehler … und seine eigenen Tests deckten ihn nicht auf.

Dann kam Codex (GPT-5.4) und meldete einen Blocker:

„Die neue Branch if not parsed.scheme or not parsed.netloc akzeptiert nicht nur echte bare-relative Pfade, sondern auch malformed/non-relative Inputs als LinkedIn-Profil. Beispiele:

• //evil.com/in/x → wird zu https://www.linkedin.com/in/x
• https:/in/x oder mailto:/in/x → wird ebenfalls zu https://www.linkedin.com/in/x
• /in/../x → wird zu https://www.linkedin.com/in/../x„

Das ist ein klassisches Identity-Spoofing-Loch über protokoll-relative URLs. Ein //evil.com/... wird zu einem gültigen LinkedIn-Link umgeschrieben. Die Ursache ist ein Logikfehler: ein or, wo ein and hingehört.

Der Fix von Opus, nach dem Review:

if not parsed.scheme and not parsed.netloc:
    path = parsed.path.rstrip("/")
    if (path and ".." not in path.split("/")
            and any(path.startswith(p) for p in _RELATIVE_PROFILE_PREFIXES)):
        return f"https://www.linkedin.com{path}"
    return None
if not parsed.scheme or not parsed.netloc:  # malformed / protokoll-relativ → None
    return None

or wurde zu and. Ein Schutz gegen ..-Pfade kam dazu. Malformte Eingaben liefern jetzt sauber None. Und die fehlenden Negativ-Tests wurden ergänzt.

Ein Ein-Zeichen-Fehler mit einer Sicherheitslücke dahinter. Zwei verwandte Modelle hätten ihn womöglich beide übersehen. Der fremde Reviewer fand ihn.

Der Fairness halber – der In-Family-Review liefert auch: In derselben Session fand Sonnet 5 einen Blocker in der Outcome-Analytik. Kennzahlen wie Accept- und Reply-Rate wurden aus Event-Typen berechnet, die kein realer Ingest-Pfad je schreibt. In Produktion hätten die Werte „still immer 0″ gezeigt. Opus zog die Quelle danach auf ein belastbares Signal um.

Die Lehre ist nicht „GPT schlägt Claude“. Die Lehre ist: Ein Reviewer, der nicht der Autor ist, findet, was der Autor nicht sieht. Eine fremde Familie erweitert diesen Effekt.

Orchestrierung über Sub-Agents

Die drei Rollen laufen nicht nacheinander in einem Kopf. Sie laufen als getrennte Sub-Agents, gesteuert vom Planer. Der Kern ist eine Pipeline pro Task:

implement (Opus, eigener Worktree) → review (Codex/Sonnet) → fix (Opus)

Wichtige Details aus der Praxis:

• Isolierte Git-Worktrees. Jeder Opus-Implementierer arbeitet in einem eigenen Worktree. Bis zu vier Tasks liefen so parallel, ohne sich in die Quere zu kommen.
• Über 20 Workflow-Läufe in einer Session, in Wellen unabhängiger Tasks (als Dynamic Workflow, von Fable selbst initiiert).
• Serielle Integration. Der Planer führt jeden Worktree einzeln zusammen. Er verifiziert extern über Exit-Codes, nicht über Selbsteinschätzung. Ein Task, ein Commit.
• Sanftes Polling. Der Fortschritt wird über ein Journal je Workflow verfolgt, im Minutentakt. Der Orchestrator liest nie die vollen Agent-Transkripte – das hält seinen Kontext schlank.

So skaliert der Workflow. Der teure Planer bleibt frei für Entscheidungen. Die günstigen Implementierer arbeiten breit und parallel. Der Reviewer hängt sich an jeden Task.

Der Mensch als Orchestrator: Poller, Heartbeat und Remote Control

Über dem Agenten steht in diesem Beispiel noch eine Instanz: der Mensch. In diesem Projekt war das die Rolle des Autors – als Human Orchestrator.

Diese Rolle will man nicht mit Dauerbeobachtung ausfüllen. Niemand starrt stundenlang auf eine laufende Agent-Session. Genau dafür gab es den Poller.

Der Poller fragt in festen Abständen den Status ab, statt am Stream zu kleben. Das hat zwei Nutznießer:

• Den Menschen. Über die Remote-Control-Funktion in Claude lief die Arbeits-Session auf dem Smartphone mit. Der Autor musste nicht am Schreibtisch bleiben. Ein Blick aufs Handy in Abständen reichte, um den Stand zu sehen. Fantastische Gelegenheit, das Sommerwetter zu genießen.
• Den KI-Orchestrator. Derselbe Status war für den Planer ein Heartbeat. Er meldete, welcher Sub-Agent gerade wo steht – ohne dass der Orchestrator die vollen Transkripte lesen musste.

Ein Heartbeat ist mehr als eine Statusanzeige. Er ist die Grundlage zum Nachsteuern. Ein Beispiel aus der Session: Ein Sub-Agent brauchte auffällig lange. Das machte den Orchestrator stutzig (gemeint ist hier das teure, maschinelle Planer-Modell, nicht der Mensch). Statt blind weiterzuwarten, setzte er sich eigene Kalibrierungspunkte; feste Zeitpunkte, an denen er gezielt nachsah und bei Bedarf eingriff.

Das ist der Kern. Ein langer Lauf ist nicht automatisch ein Problem. Aber er ist ein Signal. Wer den Heartbeat liest, erkennt das Signal früh und steuert nach, bevor Zeit verbrennt.

So bleibt der Mensch in Kontrolle, ohne gefesselt zu sein. Und der Agent bleibt handlungsfähig, ohne blind zu laufen.

Nicht vergessen: deterministische Gates in der Outer Loop

Dieser Artikel dreht sich um LLM-basierte Reviews. Sie sind mächtig, aber sie sind nicht deterministisch. Zweimal derselbe Prompt liefert nicht garantiert dasselbe Ergebnis. Das ist ihre Stärke – sie finden Unerwartetes – und zugleich ihr Risiko.

Deshalb ein klarer Hinweis, auch wenn er nicht der Fokus hier ist: Ein LLM-Review ersetzt keine deterministischen Prüfungen. Er ergänzt sie.

Der richtige Ort dafür ist die Outer Loop. Die Inner Loop ist die enge Schleife des Implementierers: schreiben, testen, fixen, wiederholen. Die Outer Loop umschließt sie – Orchestrierung, Integration, CI-Gates. Genau dort, um jeden Task herum, gehören feste, reproduzierbare Checks:

• Statische Analyse mit einem Werkzeug wie SonarQube für Code-Smells, Sicherheitsmuster und Coverage-Schwellen.
• Linter und Formatter mit hartem Exit-Code.
• Typprüfung und eine Testsuite, die bei jedem Task grün sein muss.

Der Punkt ist die Kombination. Deterministische Tools fangen bekannte Fehlerklassen zuverlässig und immer gleich. LLM-Reviews fangen das Unerwartete, das keine Regel abdeckt. Erst zusammen ergibt sich echte Härtung.

Ein Dynamic Agent, der nur auf LLM-Urteile setzt, hat eine wackelige Basis. Einer, der die Outer Loop mit deterministischen Gates absichert, steht fest.

Wie man den SonarQube-Teil konkret in die Agent-Loop hängt, ist ein Thema für sich und einen eigenen Beitrag wert.

Kosten senken: Review bündeln

Ein fremder Reviewer kostet Geld und Zeit. Deshalb lohnt sich Feintuning.

In einem Sweep-Task lief der Codex-Review zuerst pro Slice – 18 Läufe auf gpt-5.5. Das war zu teuer. Die Anpassung mitten im Lauf:

• Modell heruntergestuft: von gpt-5.5 auf gpt-5.4 mit Medium-Effort.
• Reviews gebündelt: statt nach jedem Slice nur an zwei Phasengrenzen.
• Ergebnis: vier Codex-Läufe statt achtzehn.

Die zwei Prüf-Perspektiven blieben erhalten: eine für Korrektheit und Contracts, eine für Safety und Datenschutz. Weniger Läufe, gleiche Abdeckung.

Die Regel dahinter: Prüfe an sinnvollen Grenzen, nicht nach jedem Handgriff. Wähle das kleinste Reviewer-Modell, das den Fehlertyp noch findet.

Praxis-Setup und Tools

Zum Nachbauen braucht es wenig:

1. Eine Coding Harness als Dynamic Agent. Im Beispiel: Claude Code.
2. Drei Modelle in drei Rollen. Ein teures zum Planen, ein günstigeres zum Bauen, ein fremdes zum Prüfen.
3. Sub-Agent-Orchestrierung mit isolierten Worktrees für paralleles Arbeiten.
4. Das Review-Skill skill-codex für den Cross-Family-Review über die OpenAI Codex CLI.

Installation des Review-Skills:

/plugin marketplace add skills-directory/skill-codex
/plugin install skill-codex@skill-codex

Danach steht der Review als /codex bereit; read-only, mit wählbarem Modell und Effort.

Fazit

Ein Dynamic Agent – oder Deep Agent – wird nicht dadurch besser, dass ein Modell alles macht. Er wird besser durch Arbeitsteilung.

Der Ablauf in drei Sätzen:

1. Teuer planen. Das beste Modell zerlegt die Aufgabe und wird selbst gegengelesen.
2. Günstig bauen. Ein starkes, günstigeres Modell schreibt den Code – parallel und in frischem Kontext.
3. Fremd prüfen. Ein Reviewer aus einer anderen Familie findet, was der Autor übersieht.

Der Beweis steckte in einem einzigen Zeichen: ein or, das ein and sein musste. Das günstige Modell schrieb es. Seine eigenen Tests deckten es. Erst der fremde Blick fand die Lücke.

Genau dafür lohnt sich der Multi-Modell-Workflow.