Parallel Fetch and Merge Prompt for Multiple Data Sources

This prompt is designed for full-stack AI engineers building agent or copilot systems that must aggregate data from multiple independent sources concurrently. The job-to-be-done is generating a structured execution plan before any tool calls are dispatched. Use it when your system has a defined set of tools—such as API wrappers, database connectors, or internal service clients—that do not depend on each other's outputs, and you need the model to produce a plan specifying which tools to call in parallel, how to merge their results, and how to handle partial failures. This prompt belongs in the orchestration layer, acting as a planner that outputs a machine-readable execution graph, not as a runtime executor that makes the calls itself.

The ideal user has already defined their tool schemas and needs the model to reason about concurrency, conflict resolution, and result normalization. Required context includes the full list of available tools with their input schemas, the user's original request, and any operational constraints such as timeout budgets or rate limits. The prompt is not suitable when tool calls have sequential dependencies—use a dependency graph construction prompt instead. It is also not appropriate for simple single-tool lookups, where the overhead of planning adds latency without benefit. Do not use this prompt after results have already arrived; it is a pre-execution planning step. If the user's request is ambiguous about which data sources to query, resolve that ambiguity with a clarification prompt before invoking this planning step.

Before wiring this into production, ensure you have a validation layer that checks the output plan for correctness: verify that all specified tools exist, that parallel groups contain only independent calls, and that the merge strategy handles schema mismatches explicitly. Common failure modes include the model hallucinating tool names, proposing parallel calls that actually share hidden state, or producing merge logic that silently drops conflicting fields. Start by testing with two or three known-independent data sources, then scale to broader tool sets. If any tool in the plan performs writes or state mutations, route through a human approval gate or a side-effect isolation prompt instead of executing directly from this plan.

This prompt template instructs the model to act as an execution planner. It takes a list of independent data sources, a merge strategy, and operational constraints, then produces a structured execution plan. The plan includes parallel fetch groups, a merge specification, conflict resolution rules, and a normalized output schema. Use this as the core instruction set for an agent or orchestration service that must reliably aggregate data from APIs, databases, or internal services without sequential bottlenecks.

codeCopy
You are an execution planner for a data aggregation system. Your job is to produce a parallel execution plan for fetching data from multiple independent sources and merging the results into a single, consistent output.

## INPUT
- Data Sources: [DATA_SOURCES]
- Merge Strategy: [MERGE_STRATEGY]
- Output Schema: [OUTPUT_SCHEMA]
- Operational Constraints: [CONSTRAINTS]

## INSTRUCTIONS
1. Analyze the list of data sources. Identify which sources are completely independent of each other and can be fetched in parallel.
2. Group independent sources into parallel fetch groups. Each group can execute concurrently.
3. For each group, define:
   - The source identifier
   - The expected data shape
   - A timeout budget in milliseconds
   - A retry policy (max attempts, backoff strategy)
4. Define the merge specification:
   - The primary key or entity used to join results
   - The strategy for combining fields (e.g., first-write-wins, last-write-wins, union, custom logic)
   - Explicit conflict resolution rules for overlapping or contradictory data
5. Define the result normalization schema. Map raw source fields to the final [OUTPUT_SCHEMA] fields.
6. Define partial failure handling:
   - The minimum number of sources that must succeed for the plan to return a partial result
   - The fallback value or behavior for each field when a source fails or times out
   - The structure of the error report included in the final output
7. Output the complete execution plan as a valid JSON object matching the ExecutionPlan schema below.

## EXECUTION PLAN SCHEMA
{
  "plan_id": "string",
  "parallel_groups": [
    {
      "group_id": "string",
      "sources": [
        {
          "source_id": "string",
          "endpoint": "string",
          "timeout_ms": "number",
          "retry_policy": {
            "max_attempts": "number",
            "backoff": "string"
          },
          "expected_schema": {}
        }
      ]
    }
  ],
  "merge_spec": {
    "join_key": "string",
    "strategy": "string",
    "conflict_rules": [
      {
        "field": "string",
        "resolution": "string",
        "priority_source": "string"
      }
    ]
  },
  "normalization_map": [
    {
      "target_field": "string",
      "source_field": "string",
      "source_id": "string",
      "transform": "string"
    }
  ],
  "failure_handling": {
    "min_successful_sources": "number",
    "field_fallbacks": {},
    "error_report_schema": {}
  }
}

## CONSTRAINTS
- Do not create sequential dependencies where none exist.
- If a merge conflict cannot be resolved automatically, flag it for human review in the plan.
- All timeout values must respect the global deadline in [CONSTRAINTS].
- The plan must be valid JSON. Do not include comments or markdown fences in the output.

To adapt this template, replace the placeholders with concrete values. [DATA_SOURCES] should be a structured list of available sources, each with an identifier, endpoint, and known schema. [MERGE_STRATEGY] defines the business rule for combining records (e.g., "prioritize the CRM source for contact fields, but use the billing system for financial fields"). [OUTPUT_SCHEMA] is the target schema your application expects. [CONSTRAINTS] should include a global deadline, rate limits, and any required human-review triggers. After generating the plan, validate it programmatically: check for cycles in dependencies, ensure all target fields in the output schema have a mapped source, and confirm that timeout budgets sum to less than the global deadline. For high-stakes data (financial, clinical, legal), route the generated plan through a human approval step before execution.

The Parallel Fetch and Merge prompt is designed to sit inside an orchestration layer that receives a user request, identifies independent data sources, and dispatches concurrent tool calls. The prompt itself produces a structured execution plan—not the actual fetched data. Your application must parse this plan, execute the specified tool calls in parallel, collect results (including partial failures and timeouts), and then feed everything into a second merge-and-normalize step. Do not treat this prompt as a one-shot answer generator; it is a planner that requires a reliable executor and a separate merge prompt or deterministic merge function downstream.

Execution flow: (1) Receive user query and available tool schemas. (2) Populate the prompt template with [USER_QUERY], [AVAILABLE_TOOLS], [CONSTRAINTS] (timeout budgets, rate limits, max concurrency), and [OUTPUT_SCHEMA] (the expected execution plan structure). (3) Call the model with response_format set to the parallel plan schema—require fields like parallel_groups, merge_strategy, conflict_resolution, and timeout_coordination. (4) Validate the plan: check that each tool in the plan exists in your registry, that no tool depends on another tool's output within the same parallel group, and that timeout budgets sum to less than your total SLA. Reject plans that reference unknown tools or create circular dependencies. (5) Execute each parallel group with Promise.all (or equivalent), wrapping each call in a timeout and error boundary. Capture partial results, error types, and latency per call. (6) Feed the raw results, the original plan, and any error metadata into a merge prompt or deterministic merge function that applies the specified merge_strategy and conflict_resolution rules. (7) Return the merged result to the user, including a partial_failure flag and unavailable_sources list when some fetches failed.

Validation and safety gates: Before executing any tool call, validate that each argument matches the tool's schema—type-check required fields, enforce enums, and reject calls with missing mandatory parameters. For read-only fetches, this is a correctness gate; for tools that could mutate state, this is a safety requirement. Log the full execution plan, validation results, and per-call outcomes to your observability pipeline. Include a plan_id or trace_id so you can correlate the plan with its execution results during debugging. If the model produces a plan that fails validation, retry once with the validation errors injected into the prompt as [PREVIOUS_PLAN_ERRORS]. If the retry also fails, fall back to a sequential execution mode or escalate to a human operator. Never execute an invalid plan silently.

Model choice and performance: This prompt works best with models that support structured outputs and have strong instruction-following for multi-step reasoning—GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are good starting points. Smaller models may struggle with dependency detection and produce plans that look valid but contain subtle ordering bugs. If latency is critical, consider caching the execution plan for repeated query patterns with different parameters. The merge step can often be handled deterministically (e.g., concatenation, field-level union with timestamp-based conflict resolution) rather than requiring a second model call—reserve the model for complex semantic merging or conflict resolution that requires judgment. Always set explicit max_tokens and timeout values on both the planning call and each tool execution to prevent a single slow source from blocking the entire fan-out.