Partial Tool Result Synthesis Prompt Template

This prompt is designed for AI infrastructure teams and full-stack AI engineers who need to recover from a tool call that returned incomplete, truncated, or partially failed data. The core job-to-be-done is to take a set of partial results—where some expected fields are missing, some data sources timed out, or some sub-queries returned errors—and produce a single, structured synthesis. This synthesis must explicitly flag what is missing, estimate the completeness of the overall result, and recommend a concrete next step: proceed with the available data, retry a specific failed sub-call, or escalate to a human operator. The ideal user is an engineer building a resilient agent or copilot loop where a single user request fans out into multiple tool calls, and the system must gracefully handle partial failure without crashing the entire workflow.

Use this prompt when you have a defined output schema and a collection of tool results where at least one result is incomplete, empty, or flagged with an error. It is particularly valuable in production systems where you cannot simply discard a partial result and start over due to latency budgets, token costs, or side-effect constraints. The prompt works best when you provide it with the original user intent, the expected output schema, and the raw results from each tool call, including any error metadata. Do not use this prompt for simple retry logic on a single failed call; that is better handled by a dedicated retry recovery prompt. Do not use it when the partial results are so corrupted that any synthesis would be misleading—in that case, escalate directly to a human.

Before implementing this prompt, ensure you have a clear definition of 'completeness' for your use case. This might mean the percentage of required fields populated, the number of successful sub-calls out of total, or a business-specific criticality weighting. The prompt's value comes from its ability to make a structured decision under uncertainty, but it can only do that if the constraints and thresholds are well-defined. Pair this prompt with a post-execution validator that checks the synthesized output against your schema before it is surfaced to the user or passed to the next step in the pipeline.

This template is designed to be copied directly into your application's prompt management system. It instructs the model to act as a synthesis engine for incomplete or fragmented tool results. The core job is to merge multiple partial payloads, deduplicate overlapping information, flag missing required fields, estimate overall completeness, and produce a structured output that a downstream system can reliably consume. The prompt is built for production recovery loops where a primary tool call timed out, a paginated API returned only a subset of results, or multiple fallback tools each contributed fragments of the needed data.

textCopy
You are a partial-result synthesis engine. Your task is to merge and interpret incomplete tool outputs into a single coherent response.

[CONTEXT]

[INPUT]

[OUTPUT_SCHEMA]

[CONSTRAINTS]

[EXAMPLES]

[TOOLS]

[RISK_LEVEL]

Adaptation guidance: Replace [CONTEXT] with the original user intent, the tool call history, and any error messages or timeout metadata. Populate [INPUT] with the raw partial payloads from each tool attempt, clearly labeling which tool produced which fragment. Define [OUTPUT_SCHEMA] as a strict JSON schema that includes fields for merged_result, missing_fields, completeness_confidence (a float from 0.0 to 1.0), conflicting_fields, and a recommended_action enum of proceed, retry, fallback, or escalate. Use [CONSTRAINTS] to enforce deduplication logic, conflict-resolution rules, and a prohibition on inventing data to fill gaps. Provide [EXAMPLES] of correct synthesis for your most common partial-result patterns. If the synthesis requires calling another tool to fill a critical gap, list those tools in [TOOLS]. Set [RISK_LEVEL] to low, medium, or high to control the model's conservatism; for high, the model should refuse to synthesize if completeness falls below a defined threshold and should instead escalate for human review. Always validate the output against [OUTPUT_SCHEMA] before allowing it to proceed to the next step in your application.

The Partial Tool Result Synthesis prompt is designed to sit inside a tool-call recovery handler, not as a standalone chat interaction. When a tool call returns a partial payload—some fields populated, others null or truncated, or a response that fails schema validation on a subset of fields—the recovery handler should invoke this prompt with the raw partial result, the expected output schema, and the tool's original purpose. The prompt's job is to produce a structured synthesis that flags what is present, what is missing, estimates completeness, and recommends whether to proceed, retry, or escalate. This synthesis becomes the input to the next decision node in your recovery state machine.

Wiring pattern: Wrap the prompt in a function that accepts partial_result, expected_schema, tool_name, tool_purpose, and retry_budget_remaining. The function should call the model with response_format set to the synthesis JSON schema (fields: synthesized_output, missing_fields, completeness_estimate, confidence_band, merge_conflicts, recommendation, rationale). After the model returns, run a structural validator that checks: (1) completeness_estimate is a float between 0.0 and 1.0, (2) confidence_band is one of high, medium, or low, (3) recommendation is one of proceed, retry, fallback, or escalate, and (4) every field in missing_fields maps to a path in expected_schema. If validation fails, retry the prompt once with the validation error appended to [CONSTRAINTS]. If it fails again, force recommendation: escalate and log the failure for human review.

Merge-deduplication logic is critical when the partial result contains overlapping or conflicting data from multiple tool calls. The prompt template includes a [PRIOR_RESULTS] placeholder for previously synthesized outputs. Your harness should populate this with the last N syntheses from the same recovery session, ordered by recency. The model will flag merge_conflicts when the new partial result contradicts prior data. Downstream, your application code should not automatically merge conflicting fields—route them to a human review queue if the conflict involves a high-risk field (marked in your schema with a critical: true annotation). For low-risk fields, apply a configurable resolution strategy (e.g., prefer most recent, prefer highest-confidence source).

Model choice and latency budget: This prompt is a recovery-path operation, so it runs on the critical latency path for degraded user experiences. Use a fast model (e.g., GPT-4o-mini, Claude 3.5 Haiku) for the synthesis step, reserving larger models for the escalation review path where a human is already in the loop. Set a strict timeout (500-1000ms) on the synthesis call. If the model doesn't return within the timeout, bypass synthesis and force recommendation: escalate with a timeout flag. Log every synthesis attempt—including timeouts, validation failures, and merge conflicts—to your tool-call observability system so you can tune completeness thresholds and confidence-band accuracy over time.

What to avoid: Do not use this prompt to paper over systemic tool failures. If a tool consistently returns partial results, fix the tool or its integration layer. The synthesis prompt is a recovery mechanism, not a data-quality crutch. Never pass synthesized output back to the user as if it were a complete, authoritative result—always surface completeness_estimate and missing_fields in the user-facing response when completeness is below your product's threshold (typically 0.9). Finally, ensure your harness respects the retry_budget_remaining input: if the budget is zero, the prompt should never recommend retry, and your harness should enforce this by overriding any retry recommendation to escalate before acting on the synthesis output.