There are two moments where a tool response can fail you: when it arrives, and when your agent acts on it. A validation step at the first moment gives you the chance to intervene before the second moment makes the problem harder to trace.
An HTTP 200 from a tool endpoint confirms that the request was received and a response was generated. It does not confirm that the response is correct, complete, structurally sound, or that acting on it is low-risk.
This gap is more consequential for AI agents than for traditional software. A conventional application receiving a malformed response typically fails immediately and loudly — a parsing error, a missing key, an exception. The failure is visible and local.
An AI agent receiving a malformed, incomplete, or hedging response often doesn't fail immediately. It processes what it received, fills in what's missing, and continues. The risk propagates downstream, often several steps away, in a form that is much harder to trace back to its origin.
Two kinds of validation matter here, and they surface different things.
Structural validation checks whether the response conforms to the shape your code expects. Required fields are present. Types are correct. A count field agrees with the length of the list it describes. A success indicator is not co-occurring with a populated error field. An empty data array is not appearing behind a success status. These are detectable from the response alone, without any knowledge of what the response should contain.
Reliability validation checks whether the response exhibits patterns associated with increased risk of unreliable downstream output — patterns that structural conformance alone does not surface. A response can be structurally valid while also containing hedging language co-occurring with unexplained numeric values, or showing the same content as a response from an identical call two turns ago, or missing fields that were present in previous calls to the same tool.
Both types are worth running. Structural validation catches clear breakage. Reliability validation surfaces the subtler conditions that tend to produce problems later.
Drawing from ReliAgent's eight publicly documented failure modes:
Does the response have internal consistency? A success indicator co-occurring with a populated error field. An empty data or results payload behind a success status. A count or total field that disagrees with the length of the list it describes. A response that echoes back a different scalar value than a parameter you passed. An explicit truncated or has_more flag that an agent may silently ignore.
If your downstream code was built against a specific response structure, validate the response against that structure before your agent acts on it. Type mismatches, missing required fields, and out-of-range values are all catchable at this point. Note that schema validation covers a documented subset of JSON Schema — if your schema uses keywords outside that subset, be clear about whether your validator actually covers those branches or silently skips them.
Does the response contain assertive knowledge-claim language or hedging language co-occurring with numeric values that don't trace to your request parameters? These are patterns associated with increased risk of unreliable downstream output — not a determination of whether the values are correct.
Does the response contain overclaiming language, direct-agreement phrasing, or unsupported consensus claims? These patterns appear when a model-backed tool component produces plausible-sounding content to fill gaps rather than admitting what it doesn't know.
Is this response identical or near-identical to one the agent received recently for the same tool? A response that doesn't change across consecutive calls with the same parameters is a signal that no progress is being made, even if the individual response looks valid in isolation.
Did this call take significantly longer than recent calls to the same tool? A latency spike is not itself a reliability failure, but it is worth surfacing before the result is acted on — particularly when the response content also shows other signals.
The right place to validate a tool response is after it returns and before the agent's next turn begins — before the response is appended to the conversation context or used to update any state that downstream actions will depend on.
This is typically inside the harness or orchestration layer, not inside the agent itself. The agent receives the tool response through the harness. The harness validates it before passing it on. If validation surfaces a concern, the harness can inject a directive, request a different tool, or escalate — rather than letting the agent proceed on a result it may not be able to use reliably.
ReliAgent provides this validation as an API. After your tool call returns, you POST the call record to /run: tool name, parameters, raw response, and latency. ReliAgent runs eight publicly documented reliability checks and returns a status (pass, warn, fail, or critical), a list of detected signals with confidence scores and supporting evidence, and concrete remediation recommendations.
Each check operates independently — a response can pass some and flag others, and each finding is reported separately. The combined status reflects the most significant finding across all checks. A warn status indicates something worth examining before proceeding; fail and critical indicate conditions more likely to cause downstream problems if ignored.
Optionally, supply an expected_schema to enable structural validation against your specific response shape. History-dependent checks — repetition, context degradation, parameter drift, confidence signals, and adaptive timeout — run automatically using your recent call history, with no additional configuration.
ReliAgent does not modify the response or make decisions for your orchestration layer. It returns a reliability report; what to do with it is your orchestration layer's call.
This approach is most useful when tool responses feed model-backed pipelines that may gap-fill rather than reject incomplete data, when responses come from external or model-backed services where content quality varies, or when agent sessions are long enough that repetition and context degradation are realistic concerns. Simpler workflows with deterministic, well-validated internal tools and short supervised sessions may not need this layer.
ReliAgent costs $0.01 per validated call, with no subscription. Your first 15 calls are free — no account or email required, just solve a short proof-of-work challenge to claim a trial token. Paid-tier settlement is in USDC on Base via x402.