Partial Result Recovery Prompt for Incomplete Tool Outputs

This prompt is for integration developers and reliability engineers who need to salvage usable data from a tool call that failed mid-execution, returned a truncated response, or produced malformed output. The job-to-be-done is extracting valid, structured fields from incomplete JSON, streaming chunks, or partially populated objects while explicitly flagging which required fields are missing or corrupted. Use this when a downstream system or user still needs a best-effort answer, and discarding the entire payload is more costly than working with partial data.

The ideal user has a tool output that failed validation or was cut off by a timeout, network interruption, or upstream error. They have the raw, incomplete payload and the expected output schema. The prompt requires three concrete inputs: the [INCOMPLETE_OUTPUT] string, the [EXPECTED_SCHEMA] defining required and optional fields, and any [ERROR_CONTEXT] such as the exception type or HTTP status code. Do not use this prompt when the tool output is completely empty, when the failure is an authentication or authorization error with no data returned, or when partial data could cause silent corruption in a financial, clinical, or safety-critical system without human review.

This prompt is a recovery step, not a replacement for retry logic or circuit breakers. It should be wired into a tool execution harness that first attempts retries for transient failures, then invokes this prompt only when a retry budget is exhausted and partial data is acceptable. The output must be validated against the schema before being passed downstream. For high-risk domains, route the recovered output to a human approval queue with a clear summary of what was recovered, what is missing, and what the original error was. Never silently substitute partial data for complete data in audit trails or compliance records.

The following prompt template is designed to be inserted into an agent's recovery path immediately after a tool call returns a partial, truncated, or malformed response. It instructs the model to salvage what it can, identify what is missing, and produce a structured assessment that downstream logic can act on—whether that means proceeding with degraded data, retrying with modified parameters, or escalating for human review. The template uses square-bracket placeholders that your application must populate before sending the request to the model.

textCopy
You are a partial result recovery specialist. A tool call returned incomplete or corrupted output. Your job is to extract every usable field, identify what is missing, and assess whether the partial result is safe to use downstream.

## CONTEXT
- Tool name: [TOOL_NAME]
- Tool description: [TOOL_DESCRIPTION]
- Expected output schema: [OUTPUT_SCHEMA]
- Required fields (must be present for downstream use): [REQUIRED_FIELDS]
- Optional fields (nice to have): [OPTIONAL_FIELDS]
- Error or interruption context: [ERROR_CONTEXT]
- Previous successful output shape (if available): [PREVIOUS_OUTPUT_EXAMPLE]

## RAW TOOL OUTPUT

[RAW_TOOL_OUTPUT]

codeCopy

## INSTRUCTIONS
1. Parse the raw tool output and extract every field that matches the expected output schema, even if partially populated.
2. For each field in the schema, report:
   - `field`: the field name
   - `status`: one of `complete`, `partial`, `truncated`, `corrupted`, `missing`
   - `extracted_value`: the value you recovered, or null if unrecoverable
   - `confidence`: 0.0 to 1.0 indicating how confident you are that the extracted value is correct
   - `issue`: description of any problem with the field, or null if none
3. Flag any data that appears corrupted (encoding errors, mid-field truncation, structural breaks, inconsistent types).
4. Determine whether all required fields are present with confidence >= [MIN_CONFIDENCE_THRESHOLD].
5. Assess overall output safety: can the partial result be used downstream, or must it be discarded?

## OUTPUT FORMAT
Return a JSON object with this exact structure:
{
  "tool_name": "string",
  "recovery_timestamp": "ISO 8601",
  "overall_completeness": 0.0-1.0,
  "required_fields_satisfied": true/false,
  "safe_for_downstream_use": true/false,
  "safety_rationale": "string explaining the decision",
  "fields": [
    {
      "field": "string",
      "status": "complete|partial|truncated|corrupted|missing",
      "extracted_value": any or null,
      "confidence": 0.0-1.0,
      "issue": "string or null"
    }
  ],
  "corruption_indicators": ["string"],
  "recommended_action": "proceed_degraded|retry|retry_with_modified_args|fallback|escalate_to_human|discard",
  "retry_suggestions": {
    "modified_args": {},
    "reason": "string or null"
  }
}

## CONSTRAINTS
- Never invent data to fill missing fields. Use null when a value cannot be recovered.
- If the raw output contains multiple records or streaming chunks, consolidate them before field extraction.
- Flag encoding errors (mojibake, invalid UTF-8 sequences, binary artifacts) as corruption.
- If a field is present but its type does not match the expected schema, mark it as `corrupted`.
- Do not trust field ordering in truncated output; validate each field independently.

To adapt this template for your system, replace each bracketed placeholder with live data from your agent's execution context. [OUTPUT_SCHEMA] should contain a JSON Schema or a clear field-by-field description of what the tool is expected to return. [REQUIRED_FIELDS] is the subset of fields that downstream logic cannot function without—this is your circuit breaker. [MIN_CONFIDENCE_THRESHOLD] should be tuned per workflow: 0.9 for financial data, 0.7 for informational summaries, and 0.5 or lower only when partial data is strictly better than nothing. The [ERROR_CONTEXT] placeholder should include the exception type, status code, or interruption reason so the model can correlate specific failures with specific field damage. If your tool returns streaming chunks, concatenate them into [RAW_TOOL_OUTPUT] before invoking this prompt; the model's consolidation instruction handles chunk boundaries but cannot reassemble fragments you haven't provided.

Before deploying this prompt into a production recovery path, wire the output through a schema validator that enforces the JSON structure described in the OUTPUT FORMAT block. A common failure mode is the model producing a correct assessment but omitting the retry_suggestions object or using a non-enum value for recommended_action. Post-process the safe_for_downstream_use boolean against your own business rules—the model may be optimistic about degraded data that your system cannot safely consume. For high-risk domains, route any output where required_fields_satisfied is false or overall_completeness is below your threshold to a human review queue before allowing downstream consumption.

The Partial Result Recovery Prompt is not a standalone module; it is a recovery interceptor that sits between a failed or incomplete tool call and the rest of your agent's execution context. When a tool returns a 200 OK with a truncated JSON body, a streaming response that closed early, or a batch result where only 7 of 10 requested records arrived, this prompt extracts what is usable and flags what is missing. Wire it into your tool execution harness as a post-processing step that fires when the tool's output fails a completeness check but is not entirely empty. The prompt expects the raw partial output, the expected schema or field list, and any error metadata the tool provided. It returns a structured recovery payload: usable_fields, missing_required_fields, corruption_flags, and a confidence_score that downstream logic can threshold against.

Integration pattern: In your tool execution wrapper, after catching a PartialResultError or detecting a schema validation failure, call this prompt with the raw output and the tool's contract. Use the returned confidence_score to decide whether to pass the recovered data forward. For example, if the score is above 0.85 and no missing_required_fields are critical, inject the usable_fields into the agent's context with a clear [PARTIAL RESULT] prefix. If the score is below 0.5 or critical fields are missing, route to the Retry Decision Prompt or the Fallback Tool Selection Prompt instead. Validation layer: Before the recovered output re-enters the agent's context, run a schema validator against the usable_fields to confirm they match the expected types and constraints. Log every recovery event with the original error, the prompt's output, and the validator's pass/fail result. This audit trail is essential for debugging silent data corruption in multi-step agent workflows.

Model choice and latency: This prompt is a recovery path, not the happy path. It should be fast and cheap. Use a lightweight model (e.g., a small fast variant) for this classification and extraction task unless the tool output contains complex nested structures that require stronger reasoning. Set a short timeout—if the recovery prompt itself times out, treat the tool output as unrecoverable and escalate to the Retry Budget Exhaustion Escalation Prompt. What to avoid: Do not pass the raw partial output directly into the agent's main reasoning context without this recovery step. Partial JSON, truncated arrays, and mid-stream fragments cause the agent to hallucinate missing data or silently proceed with corrupted state. Also avoid using this prompt as a substitute for proper tool output validation on successful calls—it is designed for incomplete outputs, not for normalizing valid but messy responses.