Troubleshooting and operations

Agent Tool Failure Recovery

Diagnose tool selection, schema, authorization, execution, result-matching, timeout, and side-effect failures without allowing an agent to retry blindly.

Core concept
CurrentNext review due 2026-09-23Content version 0.30.0
Format
Troubleshooting
Level
Advanced
Audience
Developer, Operator
Owner
Project42 Editorial
Review cadence
Every 60 days
Prerequisites
A tool contract with schemas, execution ownership, and postconditions; Trace access that links model requests, tool calls, and results; An idempotency, compensation, or manual reconciliation strategy
01

Find the first broken contract

Walk the trace from user authority and intended outcome through tool exposure, selection, call identifier, schema validation, policy validation, handler execution, result matching, model continuation, and external postcondition. Distinguish wrong tool, missing tool, invalid arguments, rejected authorization, dependency failure, timeout, malformed result, unmatched result ID, injected tool content, loop exhaustion, and an outcome that is unknown after a write.

Never ask the model to decide whether it had authority or whether a side effect occurred. Enforce those checks in application code. Treat external tool results as untrusted data, preserve provider-specific call/result ordering, and do not substitute prose for a required structured error result.

02

Record and contain the failed transition

Pause the loop before another consequential action. Record stable operation, trace, call, and result identifiers; the redacted arguments; schema and policy versions; executor; timeout; attempt; result class; and observed external state. Use a controlled test client or MCP Inspector against an isolated target when protocol or server behavior needs reproduction.

Agent tool failure decision path
text
User outcome and authority: [REQUEST -> ALLOWED SCOPE]
Trace/call/result IDs: [CORRELATION]
Tool and contract version: [NAME -> SCHEMA/POLICY]
Executor and target: [CLIENT | PROVIDER | MCP SERVER -> RESOURCE]
Failure stage: [SELECTION | VALIDATION | AUTH | EXECUTION | RESULT | CONTINUATION | POSTCONDITION]
Observed result: [SUCCESS | FAILURE | UNKNOWN]
Attempts and budgets: [TOOL/TIME/COST/LOOP]
External-state check: [POSTCONDITION OR RECONCILIATION RESULT]
Owner and cadence: [SERVICE OWNER -> UPDATE INTERVAL]
Stop criteria: [AUTH FAILURE | UNKNOWN WRITE | BUDGET | INJECTION | CONTRACT MISMATCH]
Recovery: [CORRECT RESULT | COMPENSATE | RESTORE | MANUAL QUEUE]
Verification: [ISOLATED REPRODUCTION + END-TO-END POSTCONDITION]
03

Expected evidence and verification

Expected evidence is a complete redacted transition from authorized request to tool contract, execution, result, continuation, and postcondition, plus the containment and owner. Verify the fix with deterministic schema and policy tests, provider-format fixtures, timeout and duplicate-delivery cases, injected-result cases, isolated execution, and a final end-to-end trajectory.

Stop the agent when authorization fails, a write outcome is unknown, result identity or ordering is broken, untrusted content crosses an instruction boundary, budgets are exhausted, or the observed state differs from the claimed state. Recovery means reconciling the target before retry, returning a typed error to the loop, applying an approved compensation or rollback, restoring the last verified tool contract, and routing unresolved operations to a human queue.