Tool Output Validation After Retry Prompt

This prompt is for integration developers and reliability engineers who have already executed a retry of a failed tool call and now need to verify that the new output is safe to use. The core job is comparing the retry output against the expected schema, the previous failed or partial result, and explicit consistency rules to catch silent data corruption, duplicate records, or incomplete recovery before the data flows into downstream agent logic or user-facing surfaces. If you skip this validation step, a retry that returns a 200 OK with a subtly malformed body or a stale cached response will corrupt your agent's state just as badly as the original failure.

Use this prompt when the tool call is non-trivial—database writes, payment operations, stateful API mutations, or multi-field structured responses where partial failure is possible. Do not use it for pure read-only idempotent GET requests where a simple status code check is sufficient. The prompt requires three concrete inputs to be useful: the expected output schema or contract, the previous failed or partial output (if any), and the new retry output. Without all three, the model cannot perform meaningful differential validation and will default to generic checks that miss production failure modes like duplicate record insertion or field-level corruption that passes basic schema validation.

The ideal reader is an engineer wiring this into a retry harness inside an agent orchestration layer, a tool proxy, or an API gateway. You should already have retry logic, error classification, and circuit breaking in place; this prompt sits after the retry succeeds at the transport level but before the output is committed to the agent's working memory or returned to the user. If you are in a regulated domain—payments, healthcare, identity—you must route validation failures to a human review queue rather than silently falling back to degraded mode. The next section provides the copy-ready template you can adapt to your tool contracts and consistency rules.

This prompt template is designed to sit between a retried tool call and the downstream agent logic that consumes its output. Its job is to verify that the retry produced valid, complete, and consistent data before the agent acts on it. Use this when a tool has already failed once, a retry has been executed (perhaps with modified arguments or after a backoff), and you need a structured assessment of whether the second attempt is trustworthy. Do not use this prompt for initial tool calls or for simple pass/fail checks that don't require comparison against prior state.

textCopy
You are a tool output validator operating after a retry. Your task is to compare the retried tool output against the expected schema, the previous partial or failed output, and consistency rules. Produce a structured assessment that downstream systems can use to decide whether to accept the retried output, request another retry, or escalate.

## INPUTS
- Retried Tool Output: [RETRIED_OUTPUT]
- Previous Output (partial or error): [PREVIOUS_OUTPUT]
- Expected Output Schema: [OUTPUT_SCHEMA]
- Consistency Rules: [CONSISTENCY_RULES]
- Tool Name: [TOOL_NAME]
- Retry Attempt Number: [RETRY_ATTEMPT]
- Max Retries Allowed: [MAX_RETRIES]

## TASK
1. Validate [RETRIED_OUTPUT] against [OUTPUT_SCHEMA]. Check for missing required fields, type mismatches, null values where non-null is expected, and truncated or malformed structures.
2. Compare [RETRIED_OUTPUT] with [PREVIOUS_OUTPUT]. Identify:
   - Fields that were missing before and are now present (repair confirmation).
   - Fields that changed unexpectedly between attempts (possible data corruption).
   - Duplicate records if the retry produced repeated data from a non-idempotent operation.
3. Apply [CONSISTENCY_RULES] to detect anomalies such as:
   - Timestamp regression (newer output has older timestamps than previous).
   - Record count mismatches against expected ranges.
   - Value contradictions between related fields.
   - Silent data corruption patterns (e.g., all strings replaced with empty strings, numeric fields zeroed out).
4. Flag any anomaly with a severity level: CRITICAL (data corruption, cannot use), WARNING (suspicious but possibly valid), or INFO (minor discrepancy, safe to proceed).

## OUTPUT FORMAT
Return a JSON object with this exact structure:
{
  "validation_passed": boolean,
  "schema_errors": [{"field": string, "error": string, "severity": "CRITICAL"}],
  "comparison_findings": [{"field": string, "previous_value": any, "retried_value": any, "assessment": string, "severity": "CRITICAL"|"WARNING"|"INFO"}],
  "consistency_violations": [{"rule": string, "detail": string, "severity": "CRITICAL"|"WARNING"|"INFO"}],
  "duplicate_detected": boolean,
  "duplicate_detail": string | null,
  "recommendation": "ACCEPT" | "RETRY" | "FALLBACK" | "ESCALATE",
  "recommendation_reason": string,
  "confidence_score": number (0.0 to 1.0)
}

## RECOMMENDATION LOGIC
- If any CRITICAL finding exists: recommend ESCALATE (if [RETRY_ATTEMPT] >= [MAX_RETRIES]) or RETRY (if attempts remain).
- If only WARNING findings exist: recommend ACCEPT with caveats noted in recommendation_reason.
- If validation_passed is true and no findings exist: recommend ACCEPT with high confidence.
- If duplicate_detected is true for a non-idempotent tool: recommend ESCALATE immediately regardless of retry count.

## CONSTRAINTS
- Do not hallucinate schema fields. Only validate against the provided [OUTPUT_SCHEMA].
- If [PREVIOUS_OUTPUT] is null or unavailable, skip comparison but note this in recommendation_reason.
- If [RETRIED_OUTPUT] is empty or still an error, set validation_passed to false and recommend based on [RETRY_ATTEMPT] vs [MAX_RETRIES].
- Confidence must reflect both schema completeness and consistency check results. A fully valid output with no prior state to compare against should score 0.85, not 1.0.

To adapt this template, replace each square-bracket placeholder with data from your agent's runtime context. The [OUTPUT_SCHEMA] should be a JSON Schema or a structured description of expected fields and types. The [CONSISTENCY_RULES] are domain-specific: for a database query tool, you might check that row counts match query parameters; for an API call, you might verify that response timestamps are monotonically increasing. If you don't have a previous output (first retry after a total failure), pass null for [PREVIOUS_OUTPUT] and the prompt will handle it. Wire this prompt into your agent's retry loop immediately after receiving the retried tool response and before passing data to any downstream step. For high-risk domains such as finance or healthcare, route any ESCALATE recommendation to a human reviewer with the full validation payload attached.

This prompt operates as a post-retry validation gate inside your agent's tool execution loop. After a tool call fails, your retry logic executes the call again, and the raw response—along with the original error context, the previous partial result (if any), and the expected output schema—is passed into this prompt. The prompt's job is not to decide whether to retry; that decision was already made upstream. Its job is to verify that the retry produced a valid, complete, and consistent result before the agent acts on it. Wire this prompt immediately after the retry call returns and before the output is merged into the agent's working context or passed to downstream tools.

The implementation requires four inputs: the retry output payload, the expected output schema (JSON Schema, TypedDict definition, or a structured description of required fields and types), the previous partial result if the original call returned incomplete data, and a set of consistency rules (e.g., 'record count must match upstream query limit,' 'timestamps must be monotonic,' 'IDs must not duplicate previous batch'). The prompt returns a structured validation result containing a pass/fail flag, a list of anomalies found, a completeness score, and a recommended action (accept, reject, partial-accept-with-flags, escalate). In code, parse this output into a typed object and branch on the action field. If the action is 'accept,' forward the validated output. If 'reject' or 'escalate,' do not silently consume the output—log the full validation report and route to your fallback or human-review path.

Validation failures from this prompt are high-signal events. Log every rejection with the retry attempt count, the tool name, the anomaly list, and the raw output. These logs become your primary debugging surface for silent data corruption and duplicate detection in production. Set up an alert if the rejection rate for a given tool exceeds a threshold (start with 5% over a rolling 10-minute window). For tools that handle mutable data or non-idempotent operations, add a duplicate-detection rule in the consistency rules input: require the prompt to compare record IDs, timestamps, or content hashes against the previous partial result and flag any overlap. If the prompt flags duplicates, do not deduplicate silently—escalate, because duplicate writes may indicate a double-execution bug in your retry layer. Finally, never use this prompt as your only validation layer for high-risk tool outputs. Pair it with deterministic schema validation (Pydantic, Zod, JSON Schema validators) before the prompt runs, and use the prompt only for semantic consistency checks that require reasoning.