Partial Result Synthesis Prompt

This prompt is designed for orchestration engineers and SRE teams managing multi-agent workflows where one or more agents have failed, timed out, or returned degraded results. The primary job-to-be-done is producing a single, coherent, and honest consolidated response from fragmented partial outputs. The ideal user is a platform engineer building a supervisor or arbitrator agent that must never silently hallucinate content for missing sections. Required context includes the original user request, the list of agents and their assigned subtasks, the partial outputs (including error messages or timeout signals), and a defined output schema with confidence scoring. Use this when you need to merge what you have, document what is missing, and assign explicit confidence levels so downstream systems or human reviewers can make informed decisions.

Do not use this prompt when all agents have completed their tasks successfully and you simply need to concatenate results—a standard assembly prompt is sufficient. Avoid it when the failure is a critical safety or compliance violation that requires immediate human intervention without any AI-generated summary. This prompt is also inappropriate when the partial results are so corrupted or contradictory that any synthesis would be misleading; in those cases, escalate the entire context to a human operator. The prompt assumes you have at least one partial result to work with. If every agent has failed with no output, this prompt will correctly produce a document consisting entirely of 'not completed' markers, which may be the desired behavior but offers little value beyond a structured error report.

Before wiring this into your application, ensure you have a robust validation layer that checks the output against the expected schema, verifies that confidence scores are present for every section, and confirms that no fabricated content has been injected into sections marked as 'not completed.' In high-risk domains, always route the synthesized output to a human review queue before it reaches the end user. The next step is to pair this prompt with the Partial Result Validation Prompt to automatically gate whether the synthesis is safe to forward.

This prompt template is designed to be the final synthesis step in an orchestration layer. It receives the outputs of multiple agents, some of which may have failed, timed out, or returned partial results. The prompt's job is not to fabricate missing data but to produce a coherent, structured summary that clearly separates completed work from gaps. Wire this into your application after collecting all agent outputs and before returning to the user or downstream system.

textCopy
You are a synthesis engine responsible for merging partial outputs from multiple specialized agents into a single consolidated response. Your primary directive is accuracy and honesty: you must never invent, guess, or hallucinate information for sections where an agent failed or provided no output.

## INPUT
You will receive a collection of agent outputs. Each output includes:
- agent_id: A unique identifier for the agent.
- status: One of 'completed', 'partial', 'failed', or 'timed_out'.
- output: The raw text or structured data produced by the agent. This field may be empty or contain an error message if the status is not 'completed'.
- error_message: A description of the failure if status is 'failed' or 'timed_out'.

[AGENT_OUTPUTS]

## OUTPUT SCHEMA
Return a single valid JSON object conforming to this structure:
{
  "overall_status": "partial" | "complete" | "failed",
  "summary": "A concise, high-level summary of what was accomplished and what is missing. Do not mention specific agents by ID; describe the work product.",
  "sections": [
    {
      "section_name": "A descriptive name for this part of the response",
      "status": "completed" | "partial" | "missing",
      "confidence": 0.0-1.0,
      "content": "The synthesized content for this section. If status is 'missing', this must be an explicit statement that the information is unavailable, e.g., 'This analysis could not be completed because the responsible agent timed out.'",
      "source_agent_id": "The agent_id that provided the primary input for this section",
      "gap_description": "If status is not 'completed', a clear explanation of what is missing and why."
    }
  ],
  "gaps_summary": [
    "A list of human-readable descriptions of each significant gap in the final output."
  ],
  "user_facing_message": "A message suitable for display to an end-user, explaining the state of the response without exposing internal agent details."
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Review all agent outputs. Identify which agents completed successfully and which did not.
2. For completed agents, synthesize their output into the appropriate sections. Preserve factual accuracy.
3. For failed or timed-out agents, create a section with status 'missing' or 'partial'. The content field must explicitly state that the information is unavailable. Reference the gap_description for details.
4. If an agent returned a partial output, include what is usable and clearly mark the incomplete parts.
5. Calculate a confidence score for each section based on the agent's status and the coherence of its output. A completed agent with clear output should have high confidence (0.9-1.0). A partial agent should have lower confidence (0.4-0.7). A missing section has a confidence of 0.0.
6. Set the overall_status to 'complete' only if all agents completed successfully. Use 'partial' if some agents failed or timed out. Use 'failed' if no usable output was produced.
7. The user_facing_message should be polite, honest, and avoid technical jargon like 'agent failure' or 'timeout'. Frame it in terms of what information is ready and what requires further action.
8. Never fabricate data to fill a gap. If you are unsure about any detail, lower the confidence score and note the uncertainty.

To adapt this template, replace the placeholders with your specific context. [AGENT_OUTPUTS] should be populated programmatically with the raw results from your agent execution graph. [CONSTRAINTS] can include rules like maximum section count, forbidden topics, or required disclaimers. [EXAMPLES] should contain one or two few-shot demonstrations of correct synthesis, especially showing how to handle a 'missing' section without hallucination. Before deploying, run this prompt against a golden test set where you intentionally cause agent failures and verify that the output never contains fabricated data in the 'missing' sections. For high-risk domains, always route the final output through a human review step before displaying it to users.

The Partial Result Synthesis Prompt is designed to be called by an orchestrator after one or more downstream agents have failed, timed out, or returned incomplete results. The orchestrator should collect all partial agent outputs, failure metadata (error codes, timeout durations, last successful step), and the original user intent into a structured context object before invoking this prompt. The prompt itself is stateless—it does not retry failed agents or fetch missing data. Its sole job is to merge what exists into a coherent, honest, and machine-readable synthesis that downstream systems or human reviewers can act on. This means the calling harness must own the retry policy, the timeout budget, and the decision about when to stop waiting for agents and invoke synthesis.

Wire the prompt into your agent framework as a terminal fallback step in any multi-agent graph or DAG. When a node fails or a parallel agent group returns with a failure count above a configured threshold, the orchestrator should: (1) collect all partial outputs and error metadata into a partial_results array, (2) attach the original user request and any session context, (3) call the synthesis prompt with a strict [OUTPUT_SCHEMA] that includes completed_sections, missing_sections, confidence_scores, and gap_documentation, and (4) validate the returned JSON against that schema before forwarding it. If validation fails, retry once with the validation error injected into [CONSTRAINTS]. If the retry also fails, log the raw output and escalate to a human reviewer with a structured handoff payload. Do not silently forward unvalidated synthesis output to users or downstream agents—hallucinated completions in missing sections are the primary failure mode here.

For production reliability, instrument the synthesis step with the following checks: confirm that every section marked completed has a non-null confidence_score between 0.0 and 1.0; confirm that every section marked missing has an explicit gap_documentation entry explaining what was not completed and why; and confirm that no section appears in both lists. Use a lightweight JSON Schema validator (such as ajv in Node.js or pydantic in Python) as a post-processing gate. If the synthesis output will be shown to end users, wrap it in a human-readable template that clearly separates completed content from gap notices—never present a raw synthesis payload as a final user-facing answer. For high-stakes domains (healthcare, finance, legal), require human approval on any synthesis where the ratio of missing sections to completed sections exceeds a configured threshold, or where any individual section confidence falls below 0.7.