Response Corruption: Wenn Agent-Antworten beschädigt werden

Das Problem

Die Anfrage wirkt einfach: ein CRM-Feld nach Prüfung des Nutzerprofils aktualisieren.

In den Traces sieht es anders aus: In 11 Minuten machte ein Run 18 Schritte, erhielt 6 Antworten mit 200 OK, aber 4 davon hatten beschädigten payload (HTML statt JSON, abgeschnittener body oder invalide Felder).

Der Service ist formal "lebendig": kein Timeout, Statuscodes wirken erfolgreich. Aber der Agent trifft Entscheidungen auf kaputten Daten und führt falsche Aktionen aus.

Das System stürzt nicht ab.

Es beschädigt still das Ergebnis unter dem Anschein einer "erfolgreichen" Antwort.

Analogie: Stell dir eine Kassiererin vor, die einen beschädigten Barcode scannt. Die Kasse geht nicht aus, aber auf dem Bon erscheint der falsche Artikel. Response Corruption in Agent-Systemen sieht genauso aus: der Prozess läuft weiter, aber die Daten sind bereits kaputt.

Warum das passiert

Response Corruption entsteht meist nicht durch einen einzelnen API-Ausfall, sondern durch schwache Qualitätskontrolle von tool output im runtime.

LLM hat einen starken Bias zu einer "vollständigen" Antwort. Ohne schema-gates setzt der Agent deshalb eher den Run mit "fast validen" Daten fort, als mit einem Fehler zu stoppen.

In Production ist es meistens so:

1. das Tool liefert formal einen erfolgreichen Status, aber beschädigten body;
2. runtime prüft nur den status code und reicht payload weiter;
3. schema/invariant checks fehlen oder sind zu weich;
4. der Agent interpretiert "fast valide" Daten als echte Fakten;
5. ohne fail-closed erreichen kaputte Daten die write-Aktionen.

Im Trace sieht man das als Wachstum von tool_output_invalid_rate bei gleichzeitig hohem tool_2xx_rate.

Das Problem ist nicht ein einzelnes kaputtes JSON.

Runtime filtert beschädigten tool output nicht aus, bevor er zur Entscheidung oder write-Aktion wird.

Häufigste Fehlermuster

In Production sieht man am häufigsten vier Muster von Response Corruption.

Erfolgreiches 2xx, aber beschädigter payload

Tool liefert 200, aber der body entspricht nicht dem Vertrag.

Typische Ursache: Kontrolle basiert nur auf HTTP-Status.

Teilweises oder abgeschnittenes JSON (Partial payload)

Antwort kommt unvollständig: Felder fehlen oder JSON bricht in der Mitte ab.

Typische Ursache: kein strict parse und kein size/content-type gate.

Stiller schema drift

Tool-Anbieter ändert Feldnamen oder Typen, aber der Agent arbeitet weiter nach altem Vertrag.

Typische Ursache: kein schema-versioning und keine Kontrolle Pflichtfelder.

Logische Korruption nach parse (Semantic corruption)

JSON ist formal valide, aber Werte verletzen Invarianten (currency="USD" + amount=-15, status="active" + deleted_at gesetzt, status="paid" + paid_at=null).

Typische Ursache: Syntax wird geprüft, Business-Invarianten nicht.

Wie man diese Probleme erkennt

Response Corruption sieht man gut an der Kombination aus Data-Quality- und runtime-Metriken.

Wie man Response Corruption von einfachem Tool Failure unterscheidet

Nicht jeder Tool-Ausfall bedeutet Datenkorruption. Die Kernfrage: liegt das Problem an Tool-Verfügbarkeit oder an payload-Qualität.

Normal für tool failure, wenn:

• Tool liefert 5xx/timeout, und der Aufruf erreicht Daten gar nicht;
• stop reason sieht aus wie tool_timeout oder tool_unavailable;
• nach Retry liefert dieselbe Anfrage validen payload.

Gefährlich für response corruption, wenn:

• viele 2xx auftreten, aber payload parse/schema/invariant checks nicht besteht;
• Agent Run mit "fast validen" Daten fortsetzt;
• Incident als falsche Business-Aktion erscheint, nicht als klarer API-Fehler.

Wie man solche Ausfälle stoppt

Praktisch sieht es so aus:

1. size- und content-type gate vor jedem parse setzen;
2. strict parse ohne "best effort" JSON-Reparatur;
3. schema und Business-Invarianten vor Datennutzung prüfen;
4. bei Verstoß stop reason zurückgeben und write-Aktionen blockieren.

Minimaler Guard zur Prüfung von tool output:

import json
from dataclasses import dataclass
from typing import Any


@dataclass(frozen=True)
class OutputLimits:
    max_chars: int = 200_000
    required_content_type: str = "application/json"


def parse_json_strict(raw: str, max_chars: int) -> Any:
    if len(raw) > max_chars:
        raise ValueError("output_too_large")
    return json.loads(raw)


def validate_profile(obj: Any) -> None:
    if not isinstance(obj, dict):
        raise ValueError("schema:expected_object")
    if not isinstance(obj.get("user_id"), str):
        raise ValueError("schema:user_id_missing")
    if obj.get("plan") not in {"free", "pro", "enterprise"}:
        raise ValueError("schema:plan_invalid")
    if obj.get("quota", 0) < 0:
        raise ValueError("invariant:quota_negative")


def verify_tool_output(raw: str, content_type: str, limits: OutputLimits = OutputLimits()) -> str | None:
    if content_type != limits.required_content_type:
        return "response_corruption:content_type_mismatch"

    try:
        obj = parse_json_strict(raw, limits.max_chars)
        validate_profile(obj)
    except json.JSONDecodeError:
        return "response_corruption:invalid_json"
    except ValueError as e:
        return f"response_corruption:{e}"

    return None

Das ist ein Basis-Guard. In Production wird er meist ergänzt durch schema versioning, per-tool Validators und einen Quarantine-Flow für verdächtigen payload. verify_tool_output(...) wird vor jeder write-Aktion aufgerufen, damit beschädigte Daten nicht in externe Systeme gelangen.

Wo das in der Architektur umgesetzt wird

In Production ist Response-Corruption-Kontrolle fast immer auf drei Systemschichten verteilt.

Tool Execution Layer ist die erste Linie: content-type, size limits, strict parse, schema checks und Vertragsversionierung. Genau hier entsteht die Qualitätsgrenze zwischen "Daten sind valide" und "Daten sind beschädigt".

Agent Runtime entscheidet, wie es weitergeht: stop reasons, fail-closed, fallback und write-Blockierung. Ohne diszipliniertes runtime wird beschädigter payload schnell zum Business-Incident.

Policy Boundaries definiert, wann das System einen Run fail-closed beenden muss und welche Aktionen bei invaliden Daten verboten sind. Das ist kritisch für alle write-Tools.

Selbstcheck

Schneller Check vor dem Release. Hake die Punkte ab und sieh dir den Status unten an.
Das ist ein kurzer Sanity-Check, kein formales Audit.

FAQ

Q: Wenn das Tool intern ist, kann man Checks lockern?
A: Nein. Interne Tools driften ebenfalls und liefern beschädigten payload. Validierung ist genauso nötig wie bei externen API.

Q: Warum nicht das Modell invalides JSON "reparieren" lassen?
A: Weil das Modell keine Wahrheit rekonstruiert, sondern eine plausible Version beschädigter Daten erzeugt. Für write-Szenarien ist Run-Stopp mit klarem stop reason sicherer.

Q: Ist eine vollständige JSON-schema-Bibliothek ab Tag 1 nötig?
A: Nein. Starte mit strict parse und kritischen Invarianten, und erweitere schema-level Abdeckung in Bereichen mit hohem blast radius.

Q: Was soll der Nutzer sehen, wenn payload invalide ist?
A: Stop reason, was bereits geprüft wurde, und den sicheren nächsten Schritt: partial Antwort oder erneuter Run nach Recovery der Abhängigkeit.

Response Corruption sieht fast nie wie ein lauter Crash aus. Es ist eine stille Degradation der Datenqualität, die Agent-Entscheidungen unbemerkt beschädigt. Darum brauchen Production-Agents nicht nur verfügbare tools, sondern auch strikte Validierung ihrer Antworten.

Verwandte Seiten

Wenn dieses Problem in Production auftritt, sind diese Seiten ebenfalls hilfreich:

• Warum AI-Agenten scheitern - allgemeine Karte von Ausfällen in Production.
• Tool failure - wie sich Tool-Ausfälle von payload-Korruption unterscheiden.
• Hallucinated sources - wie invalide Daten zu nicht vertrauenswürdigen Quellen werden.
• Prompt injection - warum untrusted tool output nicht als Instruktion behandelt werden darf.
• Agent Runtime - wo stop reasons, fail-closed und fallback gesetzt werden.
• Tool Execution Layer - wo parse/schema/invariant validation durchgeführt wird.