Ein Agent stößt an sein Kontingent, der andere verliert den Kontext: wie Sie Claude Code und Codex ohne manuelle Übergaben als Team betreiben

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect aus Freiburg im Breisgau, Germany, und ich baue bei DennisCraft AI Studio produktive KI-Systeme für DACH-B2B-Kunden auf Basis von Claude, Supabase, n8n, Doppler und selbst betriebenem Postgres. Einer der teuersten Fehler im Produktivbetrieb ist kein Modellausfall, sondern ein stiller Bruch in der Übergabe: Claude Code stößt an ein Kontingent oder ein Zeitlimit, Codex übernimmt ohne ausreichenden Zustand, und kurze Zeit später liegen widersprüchliche Änderungen, doppelte Befehle und unnötige manuelle Eingriffe vor.

Wenn Sie zwei Code-Agenten wie zwei Personen an derselben Tastatur behandeln, bleibt dieses Muster bestehen. Wenn Sie sie dagegen wie ein koordiniertes System mit explizitem Zustand, festen Übergabeverträgen und ereignisgesteuerter Steuerung betreiben, verschwinden manuelle Neustarts in vielen Fällen. Der entscheidende Unterschied liegt nicht im Modell, sondern im Betriebsmodell.

Das eigentliche Problem ist Zustandsverlust, nicht nur Kontextverlust

Viele Teams sprechen zuerst vom Kontextfenster. Das ist verständlich, trifft aber nur einen Teil des Problems. In der Praxis scheitert die Übergabe meist daran, dass der zweite Agent nur einen Prompt bekommt, aber keinen belastbaren Arbeitszustand. Ein Prompt kann das Ziel beschreiben. Er kann jedoch nicht zuverlässig den aktuellen Branch, den letzten erfolgreichen Testlauf, die geänderten Dateien, die Ergebnisse der Sicherheitsprüfung oder den Abbruchgrund des ersten Agenten ersetzen.

Anthropic betont in der Dokumentation von 2024 zu Tool Use und strukturierten Ausgaben, dass maschinenlesbare Antworten für automatisierte Abläufe wichtig sind: https://docs.anthropic.com/. Das OpenAI Cookbook zeigt 2024 ebenfalls Muster, bei denen einzelne Schritte explizite Artefakte erzeugen und nachfolgende Schritte Zustand lesen, statt sich auf Gesprächsverlauf zu verlassen: https://cookbook.openai.com/.

Wo die Übergabe im Produktivbetrieb bricht

Ich beobachte vor allem drei Fehlermuster. Erstens wird eine längere Implementierungsaufgabe durch Kontingentgrenzen oder Zeitüberschreitungen mitten im Fortschritt unterbrochen. Zweitens durchsucht der übernehmende Agent zu viel vom Repository, weil keine eingegrenzte Zustandsübergabe vorliegt. Drittens gehen Risikosignale verloren, sodass der nächste Agent Änderungen vornimmt, ohne zu wissen, welche Tests bereits fehlgeschlagen sind oder welche Schranke schon ausgelöst wurde.

Beide Agenten sollten gegen einen gemeinsamen Zustandsvertrag arbeiten

Die einfachste Lösung ist zugleich die verlässlichste: Speichern Sie den Aufgabenstatus außerhalb des Modells. Ich nutze dafür meist Postgres oder Supabase Postgres und lasse n8n die Ereignisse steuern. Claude Code und Codex sollten einander nicht „erinnern“. Beide sollten denselben normalisierten Datensatz lesen und schreiben.

Ein minimaler Übergabevertrag

Verlangen Sie vom abgebenden Agenten keinen Fließtext, sondern einen festen Vertrag. Ist dieser unvollständig, sollte der Ablauf kontrolliert stoppen, statt eine schwache Übergabe automatisch weiterzureichen.

from pydantic import BaseModel
from typing import List, Literal

class HandoffState(BaseModel):
    task_id: str
    agent: Literal["claude_code", "codex"]
    branch: str
    commit_sha: str
    changed_files: List[str]
    test_status: Literal["passed", "failed", "not_run"]
    security_status: Literal["passed", "failed", "not_run"]
    next_action: str
    blocker: str | None = None

Diese Struktur wirkt unspektakulär. Genau das ist im Produktivbetrieb hilfreich. Unspektakuläre Verträge halten auch dann, wenn am späten Nachmittag eine Sitzung abbricht und ein anderer Agent ohne Spekulation übernehmen muss.

Ereignisgesteuerte Weiterleitung statt manueller Neustarts

In meinem Stack übernimmt n8n häufig die Rolle des Verkehrsleiters. Claude Code startet mit der Implementierung. Trifft der Agent auf ein Kontingent, verliert den Sitzungszusammenhang oder läuft in ein Zeitlimit, speichert n8n den zuletzt validierten Zustand in Postgres, markiert den aktuellen Bearbeiter als blockiert und übergibt die Aufgaben-ID an Codex. Codex beginnt dann mit dem Lesen des Zustands und nicht mit dem Lesen eines langen Übergabetextes.

version: "3"
steps:
  - name: run_claude_code
    on_error: persist_state
  - name: persist_state
    action: write_postgres
  - name: run_checks
    action: bash
  - name: route_next_agent
    when: "quota_hit || context_loss || timeout"
    action: assign_codex
  - name: require_review
    when: "security_failed"
    action: notify_human

Es geht dabei nicht nur um n8n. Der zentrale Punkt ist die ereignisgesteuerte Übergabe. Ein Mensch sollte nicht der Warteschlangenmanager für vorhersehbare Agentenabbrüche sein.

Welche Signale Sie tatsächlich auswerten sollten

Ich arbeite meist mit fünf Signalen: Kontingent erreicht, Kontext gekürzt, Befehlszeit überschritten, Tests fehlgeschlagen und Sicherheitsprüfung fehlgeschlagen. Die ersten drei sind Weiterleitungsereignisse. Die letzten beiden sind Qualitätsschranken. Je nach Risiko geht die Aufgabe damit entweder mit einem engen Reparaturziel an denselben Agenten zurück oder in eine menschliche Prüfung, etwa bei Authentisierung, SQL, Geheimnissen oder Zahlungslogik.

Sicherheitsprüfungen dürfen bei der Übergabe nicht verloren gehen

Eine verbreitete Fehleinschätzung ist, Übergaben nur als Effizienzthema zu behandeln. Tatsächlich handelt es sich auch um ein Thema der Software-Sicherheit und Nachvollziehbarkeit. Der übernehmende Agent arbeitet häufig unter Zeitdruck und mit schwächerem Kontext. Genau dort entstehen unsaubere Korrekturen.

OWASP führt in den Top 10 von 2021 Injection weiterhin als grundlegendes Risiko auf: https://owasp.org/Top10/. Deshalb lasse ich keine automatische Weitergabe ohne erneute Prüfungen zu. In Python-lastigen Repositories nutze ich dafür häufig bandit, für allgemeine Muster semgrep und für Geheimnisse gitleaks.

#!/usr/bin/env bash
set -euo pipefail

pytest -q
semgrep --config auto .
bandit -r app -q
gitleaks detect --no-banner --redact

echo "checks_passed=true"

In drei aktuellen Agenten-Setups habe ich wiederholt dasselbe Muster gesehen: Der erste Agent verwendete parametrisierte Datenbankzugriffe korrekt, der zweite führte bei einer schnellen Fehlerbehebung rohes SQL in einer Hilfsschicht ein. Das ist kein Marketingproblem eines Modells, sondern eine Schwäche der Übergabequalität.

Warum dieser Ansatz für den DACH-Markt sinnvoll ist

Für Kunden aus Logistik, Fintech und industrieller Automatisierung im DACH-Raum halte ich die Architektur bewusst prüfbar. Quellcodeänderungen liegen in Git, Aufgabenstatus in Postgres, Geheimnisse in Doppler, die Orchestrierung in n8n, und jeder Vorgang erhält zugeordnete Artefakte für Tests und Prüfungen. Das ist nicht nur betrieblich sinnvoll, sondern auch für Nachweisbarkeit relevant.

Wenn Ihre Organisation nach DSGVO, ISO 27001, BSI Grundschutz, NIS2 oder künftig unter Anforderungen des EU AI Act arbeitet, brauchen Sie nachvollziehbare Übergaben statt schwer prüfbarer Modellgespräche. Sie müssen beantworten können, welcher Agent welche Änderung vorgenommen hat, unter welchen Prüfungen dies geschah und an welcher Stelle ein Mensch eingegriffen hat. Genau deshalb sollte „Agenten-Gedächtnis“ nicht als ein großer Textblock gespeichert werden, sondern als normalisierte Felder, die sich prüfen, filtern und auswerten lassen.

FAQ

Brauchen Sie dafür zwingend n8n?

Nein. Dasselbe Muster lässt sich auch in Python mit einer Auftragswarteschlange umsetzen. n8n ist besonders nützlich, wenn Sie Weiterleitungslogik, Benachrichtigungen und Webhooks schnell anpassen möchten.

Sollten beide Agenten auf demselben Branch arbeiten?

Oft ja, allerdings nur mit festgehaltenem Commit-Stand und eindeutigem Aufgabenstatus. In risikoreichen Abläufen empfehle ich einen neuen Branch vom letzten validierten Commit, damit die Fortsetzung kontrolliert erfolgt.

Reicht ein langer Übergabe-Prompt aus?

Nein. Ein langer Prompt kann Absicht zusammenfassen, ersetzt aber keinen strukturierten Zustand mit Befehlsverlauf, Dateiliste, Testausgaben und Ergebnissen der Sicherheitsprüfung. Prompts sind Zusammenfassungen, keine belastbare Quelle der Wahrheit.

Wann ist eine menschliche Prüfung zwingend?

Immer dann, wenn Änderungen Authentisierung, Berechtigungen, SQL, Geheimnisse, Zahlungsabläufe oder personenbezogene Daten betreffen. Je näher der Code an einer Vertrauensgrenze liegt, desto weniger sinnvoll ist eine vollautomatische Weitergabe ohne Prüfung.

Woran erkennen Sie, dass Ihre Übergaben bereits scheitern?

Wenn Agenten wiederholt das gesamte Repository neu lesen, dieselben Befehle erneut ausführen, frühere Entscheidungen infrage stellen oder widersprüchliche Änderungen erzeugen, ist die Zustandsübergabe zu schwach. Das ist zuerst ein Betriebsproblem und erst danach ein Modellproblem.

An welcher Stelle Ihres LLM-Ablaufs verlieren Sie im Produktivbetrieb heute am meisten Zeit und Qualität: an Kontingentgrenzen, an Kontextverlust, an der statischen Analyse oder an der menschlichen Prüfung? Das würde ich gern mit Erfahrungen aus DACH-Projekten abgleichen.
I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.