Tool-Output Validation
Validate tool outputs against schema and semantic expectations before the agent acts on them — tools can return malformed, stale, or adversarial data.
This page is the complete instruction page for one pattern called "Tool-Output Validation." It explains the problem this pattern solves, the idea behind the solution, when you should (and should not) use it, and what happens afterward — both the good effects and the costs.
This matters because building AI agents is not just about making them clever. It is also about making them safe and predictable. Following a well-tested pattern like this one helps avoid common mistakes, and shows you exactly which safety rules and regulations it connects to, listed under "Standards Mesh" on this page.
Context
Tools fail in subtle ways: partial results, stale data, injected content from upstream sources. An agent that trusts tool outputs blindly propagates those failures into actions.
Problem
Trusting tool outputs creates an indirect path for poisoning and error propagation.
Forces
- Validation overhead vs robustness
- Strict schema vs real-world messiness
Solution
After each tool call, validate: schema conformance, type bounds, freshness markers, adversarial-pattern detection on free-text fields. On violation: retry, fall back, or escalate. Feed validation failures into observability for tool-health monitoring.
Applicability
- All tool-using agents
- Particularly agents consuming external or web-sourced data
- Multi-agent systems
Anti-Patterns
- Passing raw tool output into the next reasoning step
- Validation only at type level, not semantic
Consequences
- +Resilience to tool failure modes
- +Detection of upstream poisoning
- −Schema authoring cost
- −Overly strict validation rejects valid data