Response Corruption: When Agent Outputs Break

The Problem

The request looks simple: update a CRM field after validating a user profile.

Traces show something else: in 11 minutes one run made 18 steps, got 6 responses with 200 OK, but 4 of them had corrupted payload (HTML instead of JSON, truncated body, or invalid fields).

The service is formally "alive": no timeout, statuses look successful. But the agent makes decisions on broken data and performs wrong actions.

The system does not crash.

It silently corrupts outcomes under the label of a "successful" response.

Analogy: imagine a cashier scanning a damaged barcode. The register does not turn off, but the wrong item appears on the receipt. Response corruption in agent systems works the same way: process keeps going, but data is already broken.

Why This Happens

Response corruption usually appears not because of one API failure, but because runtime control of tool-output quality is weak.

LLM has a strong bias toward a "completed" answer. So without schema gates, the agent more often continues a run on "almost valid" data instead of stopping with an error.

In production, this usually looks like:

1. tool returns a formally successful status but corrupted body;
2. runtime checks only status code and passes payload forward;
3. schema/invariant checks are missing or too weak;
4. agent interprets "almost valid" data as real facts;
5. without fail-closed, broken data reaches write actions.

In trace, this appears as growth of tool_output_invalid_rate while tool_2xx_rate remains high.

The problem is not one broken JSON.

Runtime does not cut off corrupted tool output before it becomes a decision or write action.

Most Common Failure Patterns

In production, four response-corruption patterns appear most often.

Successful 2xx but broken payload

Tool returns 200, but body does not match contract.

Typical cause: control is built only on HTTP status.

Partial or truncated JSON (Partial payload)

Response arrives incomplete: fields are missing or JSON is cut in the middle.

Typical cause: no strict parse and no size/content-type gate.

Silent schema drift

Tool provider changes field names or types, while the agent continues using an old contract.

Typical cause: no schema versioning and no required-field control.

Semantic corruption after parse

JSON is formally valid, but values break invariants (currency="USD" + amount=-15, status="active" + deleted_at present, status="paid" + paid_at=null).

Typical cause: syntax is checked, but business invariants are not.

How To Detect These Problems

Response corruption is visible through a combination of data-quality and runtime metrics.

How To Distinguish Response Corruption From Tool Failure

Not every tool failure means data corruption. The key question: is the problem tool availability or payload quality.

Normal for tool failure if:

• tool returns 5xx/timeout, and call does not reach data;
• stop reason looks like tool_timeout or tool_unavailable;
• after retry, the same request returns valid payload.

Dangerous for response corruption if:

• there are many 2xx, but payload fails parse/schema/invariant checks;
• agent continues run on "almost valid" data;
• incident appears as wrong business actions, not explicit API error.

How To Stop These Failures

In practice, this is the pattern:

1. place size and content-type gate before any parse;
2. use strict parse without "best effort" JSON repair;
3. validate schema and business invariants before using data;
4. on violation, return stop reason and block write actions.

Minimal guard for tool-output validation:

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

This is a basic guard. In production, it is usually extended with schema versioning, per-tool validators, and quarantine flow for suspicious payload. verify_tool_output(...) is called before any write action, so corrupted data does not reach external systems.

Where This Is Implemented In Architecture

In production, response-corruption control is almost always split across three system layers.

Tool Execution Layer owns the first line: content-type, size limits, strict parse, schema checks, and contract versioning. This is where the quality boundary is formed between "data is valid" and "data is corrupted".

Agent Runtime decides what happens next: stop reasons, fail-closed, fallback, and write-action blocking. If runtime is not disciplined, corrupted payload quickly becomes a business incident.

Policy Boundaries defines when the system must finish run as fail-closed and which actions are forbidden on invalid data. This is critical for all write tools.

Self-check

Quick pre-release check. Tick the items and see the status below.
This is a short sanity check, not a formal audit.

FAQ

Q: If tool is internal, can validation be weaker?
A: No. Internal tools also drift and return corrupted payload. Validation is required the same way as for external API.

Q: Why not let model "fix" invalid JSON?
A: Because model does not restore truth, it generates a plausible version of corrupted data. For write scenarios, it is safer to stop run and return explicit stop reason.

Q: Is a full JSON schema library required from day one?
A: No. Start with strict parse and critical invariants, then expand schema-level coverage in high blast-radius zones.

Q: What should user see when payload is invalid?
A: Stop reason, what is already verified, and a safe next step: partial answer or rerun after dependency recovery.

Response corruption almost never looks like a loud crash. It is a silent data-quality degradation that invisibly breaks agent decisions. So production agents need not only available tools, but strict validation of their outputs.

Related Pages

If this happens in production, these pages are also useful:

• Why AI agents fail - general map of failures in production.
• Tool failure - how tool failures differ from payload corruption.
• Hallucinated sources - how invalid data turns into untrusted citations.
• Prompt injection - why untrusted tool output must not be treated as instructions.
• Agent Runtime - where to place stop reasons, fail-closed, and fallback.
• Tool Execution Layer - where to run parse/schema/invariant validation.