Warum ein Agent nicht mehr ausreicht: Claude Code, Codex und Kiro ohne tmux-Chaos orchestrieren

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany, und ich liefere mit DennisCraft AI Studio produktive KI-Systeme für DACH-B2B-Kunden auf Basis von Claude, Supabase, n8n, Doppler und selbst betriebenem Postgres. Der kritische Punkt beginnt nicht dann, wenn ein Modell einmal falschen Code erzeugt. Er beginnt dann, wenn 3 Agenten parallel im selben Repository arbeiten, jeweils plausibel aussehen und am Ende niemand sauber belegen kann, welche Sitzung, welcher Branch oder welcher Prompt die Änderung in der Hauptlinie erzeugt hat.

Genau dort endet das Muster „ein Agent pro Aufgabe“ als verlässlicher Ansatz. Ein einzelner Agent kann bei einer begrenzten Funktion noch ausreichen. Sobald jedoch Anwendungscode, SQL-Migrationen, Automatisierung, Geheimnisverwaltung und Prüfregeln zusammenkommen, ist nicht mehr die Textgenerierung das Hauptproblem, sondern die Orchestrierung: Zuständigkeiten, Reihenfolge, Berechtigungen und Nachvollziehbarkeit.

Warum der Einzelagent in der Praxis scheitert

Das Muster scheitert aus demselben Grund, aus dem eine Person nicht gleichzeitig Produktverantwortung, Umsetzung, Abnahme und Freigabe tragen sollte. Zu viel Kontext konkurriert zur selben Zeit, Fehler lassen sich schlechter zuordnen, und Änderungen über mehrere Schichten verlieren ihre klare Herkunft.

In realen Systemen berührt eine Aufgabe oft 4 Ebenen zugleich: Geschäftslogik, Datenbankschema, Automatisierung und Sicherheitsprüfung. In mehreren Projekten habe ich gesehen, dass ein einzelner Agent dabei zu viel Kontext mit Schichtwechseln verbraucht. Mehrere Agenten im selben Arbeitsbereich ohne klare Grenzen erzeugen dagegen doppelte Arbeit, widersprüchliche Annahmen und Merge-Konflikte, die später ein Mensch bereinigen muss.

OWASP weist in den Leitlinien für LLM-Anwendungen darauf hin, dass klare Vertrauensgrenzen und Werkzeugvalidierung erforderlich sind, statt sich allein auf Prompts zu verlassen (OWASP, 2024, https://owasp.org/www-project-top-10-for-large-language-model-applications/). Für die Code-Erzeugung bedeutet das praktisch: Derselbe Agent sollte Änderungen nicht gleichzeitig erstellen, prüfen und freigeben.

Ein tragfähiges Muster: Rollen statt Terminal-Theater

Ich versuche nicht, einen einzigen Über-Agenten für alles zu bauen. Ich trenne Rollen. Claude Code eignet sich für längere Architekturzusammenhänge und Änderungen über mehrere Dateien hinweg. Codex ist nützlich für eng gefasste Umsetzungen und alternative Varianten. Kiro kann als eigener Hilfskanal für Recherche oder Randfälle sinnvoll sein, aber nicht als maßgebliche Instanz für ein produktives Repository. Die maßgebliche Instanz muss in git, den Prüfungen und einer expliziten Aufgabenwarteschlange liegen.

Minimale Rollentrennung

• Planer: zerlegt die Aufgabe in atomare Änderungen und Reihenfolge.
• Umsetzer: schreibt den Code in einem isolierten Branch.
• Prüfer: führt Tests, semgrep, bandit, gitleaks und Richtlinienprüfungen aus.
• Freigeber: bewertet Unterschiede und entscheidet über Annahme oder Ablehnung.

Die wichtigste Regel ist einfach: ein Agent, eine Verantwortung, ein Branch, ein bearbeitbarer Dateibereich. Lassen Sie 2 Agenten nicht gleichzeitig dieselben Verzeichnisse verändern. Sonst verlagern Sie die Arbeit nur von der Implementierung in die Konfliktbereinigung.

git checkout -b agent/umsetzer-aufgabe-142
pytest tests/unit -q
semgrep --config auto .
bandit -r app -q
gitleaks detect --source . --no-banner
git add .
git commit -m "aufgabe-142: isolierte Umsetzung"
git push origin agent/umsetzer-aufgabe-142

Steuerung gehört in eine Warteschlange, nicht in tmux

tmux ist als Beobachtungsoberfläche nützlich. Als Steuerungsebene ist es ungeeignet. Sobald der operative Zustand hauptsächlich in Terminalfenstern lebt, verlieren Sie Reproduzierbarkeit und Prüfbarkeit. Ich bevorzuge ein einfaches Muster: Aufgaben in Postgres, Statuswechsel über API oder n8n, und jeder Agent erhält nur die Rechte, die er in seiner aktuellen Phase benötigt.

Dafür braucht es kein neues Produkt mit großem Namen. Postgres, n8n und Prozessdisziplin reichen aus.

create table agent_jobs (
  id bigserial primary key,
  task_key text not null,
  role text not null check (role in ('planner','builder','verifier','merger')),
  branch text not null,
  status text not null check (status in ('queued','running','failed','done')),
  payload jsonb not null,
  created_at timestamptz default now(),
  updated_at timestamptz default now()
);

n8n übernimmt dabei die Verteilung: Aufgabe anlegen, Agent aufrufen, Artefakte einsammeln, Prüfungen starten und den Status weiterführen oder zurücksetzen. Der Vorteil ist betrieblich relevant: Jeder Fehler erscheint als nachvollziehbares Ereignis im System und nicht als verlorene Terminalausgabe.

Was vor der Freigabe blockieren sollte

Mindestens erforderlich sind Unit-Tests, semgrep, bandit für Python, gitleaks zur Erkennung von Geheimnissen, Prüfungen auf parametrisierte SQL-Zugriffe und eine Plausibilitätsprüfung der Migrationen. Anthropic empfiehlt in der Dokumentation zur Werkzeugnutzung klar definierte Werkzeuge und ausdrückliche Bestätigung bei sensiblen Aktionen (Anthropic Docs, 2024, https://docs.anthropic.com/). In der Praxis heißt das: Ein Agent darf sich keine destruktiven Rechte selbst verschaffen.

steps:
  - run: pytest tests/unit -q
  - run: semgrep --config auto .
  - run: bandit -r app -q
  - run: gitleaks detect --source . --no-banner
  - run: python scripts/check_sql_params.py
  - run: python scripts/check_migrations.py

Wie ich Claude Code, Codex und Kiro verteile

Für mich ist nicht entscheidend, welches Werkzeug in einer Debatte gewinnt. Entscheidend ist das jeweilige Fehlermuster im Produktivbetrieb.

Ein typischer Ablauf sieht so aus: Claude Code plant und bearbeitet eine größere Umstrukturierung in einem eigenen Branch. Codex übernimmt eine enge Teilaufgabe, etwa Tests oder ein einzelnes Modul. Kiro untersucht Randfälle oder erstellt eine Ausweichvariante. Danach laufen alle Ergebnisse in eine Prüfstufe. Wenn die Prüfung scheitert, geht die Aufgabe zurück in die Warteschlange und nicht in eine Diskussion darüber, welches Terminalfenster schuld war.

Was sich im regulierten DACH-Umfeld ändert

Im DACH-Markt ist diese Frage nicht nur technisch, sondern auch regulatorisch relevant. Je nach Branche kommen DSGVO, NIS2, ISO 27001, BSI Grundschutz oder der EU AI Act ins Spiel. Dann zählen Nachvollziehbarkeit, Rechtevergabe, Protokollierung und kontrollierte Freigabe nicht als Zusatz, sondern als Teil des eigentlichen Systems.

Darum halte ich mich an 3 Regeln. Erstens: Agenten erhalten keine rohen Geheimnisse im Prompt, sondern nur eng begrenzten Zugriff, etwa über Doppler. Zweitens: Jede relevante Aktion hinterlässt einen Eintrag im Aufgabensystem oder in den CI-Protokollen. Drittens: Die Freigabe ist ein Kontrollereignis und nicht das automatische Ende der Modellantwort. Wenn Sie diese Regeln umsetzen, wird aus mehreren Agenten kein tmux-Chaos, sondern ein prüfbarer Bereitstellungsprozess.

FAQ

Brauchen Sie tmux überhaupt?

Nicht zur Steuerung. Für Beobachtung und lokale Fehlersuche ist tmux nützlich, aber Aufgabenstatus, Prüfungen und Nachweise sollten außerhalb des Terminals liegen.

Sollte jeder Agent einen eigenen Arbeitsbereich erhalten?

Ja, sobald Schreibzugriff auf den Code besteht. Eigene Branches und getrennte Arbeitsbereiche senken das Risiko von Zustandsvermischung und erleichtern die Reproduktion von Fehlern.

Reicht eine einzige Prüfstufe aus?

Meistens nicht. Sinnvoll ist eine schnelle Vorprüfung vor dem Commit und eine strengere Prüfung vor der Freigabe, damit offensichtliche Fehler keine manuelle Abnahme blockieren.

Wo sollte das Gedächtnis des Agenten liegen?

Nicht in der Terminalhistorie. Kurzlebiger Betriebszustand gehört in Postgres oder Supabase, dauerhafte Entscheidungen in git, Architekturentscheidungen und nachverfolgbare Aufgaben.

Wann lohnt sich ein Mehragentensystem überhaupt?

Dann, wenn Sie unabhängige Teilprobleme mit unterschiedlichen Artefakten haben, etwa Code, SQL, Automatisierung und Richtlinien. Für kleine lineare Aufgaben ist ein einzelner Agent oft günstiger und verlässlicher.

An welcher Stelle Ihrer LLM-Pipeline entstehen im Produktivbetrieb aktuell die meisten Probleme: bei der Code-Erzeugung, in der Prüfphase, bei der Freigabe oder erst nach der Bereitstellung? Ich würde das gern mit den Mustern vergleichen, die ich bei Teams im DACH-Markt sehe.
Ich biete einen kostenlosen 30-Minuten-Stack-Audit für Gründer und CTOs an, die KI in regulierten Märkten bauen. Schreiben Sie mir auf LinkedIn oder an @ger_dennis_ai.