Parallel Tool Call Result Correlation Prompt

This prompt is for observability engineers and agent infrastructure developers who need to reconstruct relationships between results from concurrent tool calls that share entities, resources, or temporal dependencies. The job-to-be-done is producing correlation keys, join logic, and temporal ordering reconstruction when a set of parallel tool calls returns overlapping or related data. The ideal user is someone building agent execution traces, debugging distributed tool call side effects, or implementing result aggregation pipelines where independent calls touch the same logical objects. Required context includes the full set of parallel tool call results, their execution timestamps, the tool schemas that describe output fields, and any known entity identifiers that span multiple calls.

Do not use this prompt when the tool calls are already sequenced with explicit input-output dependencies, when the results are fully disjoint with no shared entities, or when you control the execution plan and can enforce correlation at call time rather than reconstructing it post-hoc. This prompt is also inappropriate for simple result merging where no entity resolution is required. If your system can inject correlation IDs or request IDs into tool call arguments before execution, prefer that approach over post-hoc correlation. Use this prompt when you inherit parallel results from an execution engine you don't fully control, when tool calls fan out to independent services that don't share a correlation context, or when you're building observability tooling that must make sense of concurrent execution traces after the fact.

The prompt expects you to provide the raw tool call results, their start and end timestamps, the tool names and output schemas, and any known entity types that might appear across results. It produces structured correlation output: a set of correlation keys, join conditions, confidence scores for each proposed relationship, and a reconstructed temporal ordering where relevant. Before deploying this into a production pipeline, validate the correlation output against ground-truth relationships you can verify independently. Build an eval set with known entity overlaps and missing correlation data to measure precision and recall. For high-stakes systems where incorrect correlation could cause data corruption or incorrect user-facing state, route low-confidence correlations to a human review queue. The next step after reading this section is to examine the prompt template and adapt the placeholders to your specific tool schemas and entity types.

This template is designed to be dropped into an observability or agent orchestration pipeline immediately after a set of parallel tool calls completes. It instructs the model to act as a correlation engine, ingesting multiple raw tool outputs and producing a structured analysis that links related results, reconstructs temporal order, and flags missing or ambiguous data. The prompt assumes you have already executed the tool calls and have their outputs available; its sole job is to make sense of the results as a coherent set.

textCopy
You are a correlation engine for concurrent tool call results. Your task is to analyze the outputs of multiple tool calls that were executed in parallel and produce a structured correlation report.

## INPUT
You will receive a set of tool call results. Each result includes:
- `call_id`: a unique identifier for the tool call
- `tool_name`: the name of the tool that was called
- `timestamp`: the time the call completed (ISO 8601)
- `output`: the raw output from the tool call

Tool Call Results:
[TOOL_CALL_RESULTS]

## TASK
1. Identify which results share common entities, resources, or identifiers.
2. For each group of related results, generate a `correlation_key` that uniquely identifies the shared entity.
3. Reconstruct the temporal ordering of related results based on timestamps and any causal indicators in the outputs.
4. Detect and flag any of the following:
   - Missing correlation data: results that reference entities not present in other outputs
   - Ambiguous relationships: results that could belong to multiple correlation groups
   - Conflicting data: results that disagree on shared entity attributes

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "correlation_groups": [
    {
      "correlation_key": "string",
      "entity_type": "string",
      "entity_identifier": "string",
      "related_call_ids": ["string"],
      "temporal_order": ["call_id"],
      "merged_attributes": {},
      "confidence": "high|medium|low"
    }
  ],
  "uncorrelated_calls": [
    {
      "call_id": "string",
      "reason": "string"
    }
  ],
  "ambiguities": [
    {
      "call_id": "string",
      "possible_groups": ["correlation_key"],
      "description": "string"
    }
  ],
  "conflicts": [
    {
      "attribute": "string",
      "conflicting_call_ids": ["string"],
      "values": {},
      "resolution_suggestion": "string"
    }
  ]
}

## CONSTRAINTS
- Use only the data present in the provided tool call outputs. Do not invent entities or relationships.
- If a correlation is uncertain, set confidence to "low" and add an entry to `ambiguities`.
- If two results conflict on a shared attribute, do not pick a winner. Document the conflict and suggest a resolution strategy.
- If a result cannot be correlated with any other result, place it in `uncorrelated_calls` with a specific reason.
- Preserve all original `call_id` values exactly as provided.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace [TOOL_CALL_RESULTS] with the actual outputs from your parallel tool calls, formatted as an array of objects matching the described schema. The [FEW_SHOT_EXAMPLES] placeholder should be populated with 2-3 worked examples showing correct correlation, ambiguity handling, and conflict documentation for your specific domain. Set [RISK_LEVEL] to high if the correlation results drive automated downstream actions (requiring human review of low-confidence groups), or low if the output is purely for observability dashboards. For production use, wrap this prompt in a validation layer that checks the output JSON against the schema before ingestion, and log any schema violations for prompt refinement.

The Parallel Tool Call Result Correlation Prompt is not a standalone utility—it is a post-execution processing step that must be embedded within an agent's observability pipeline. After a fan-out of concurrent tool calls completes, the raw results arrive as an unordered collection of payloads with no inherent relationship markers. The prompt's job is to reconstruct the logical connections: which results belong to the same entity, which temporal order can be inferred, and where correlation data is missing or ambiguous. In production, this prompt should be triggered automatically by the orchestration layer once all parallel calls in a batch have returned, timed out, or failed. The input to the prompt is the full set of tool call metadata (tool name, arguments, invocation timestamp, completion timestamp, status) and their raw outputs, packaged into the [TOOL_CALL_RESULTS] placeholder.

To integrate this into an agent harness, wrap the prompt in a post-processing function that first validates the input structure: every tool call entry must include a unique call_id, a tool_name, a started_at and completed_at timestamp, and the output payload. If any of these fields are missing, the harness should reject the batch and log a schema violation before the prompt ever runs—this prevents the model from hallucinating correlation keys from incomplete data. After the prompt returns its structured output (a JSON object containing correlation_groups, orphaned_results, temporal_ordering, and ambiguity_notes), the harness must validate that every input call_id appears exactly once across the correlation groups and orphaned list. Any missing or duplicated IDs indicate a model error and should trigger a retry with a stricter [CONSTRAINTS] block or a fallback to a deterministic correlation method (e.g., exact entity ID matching). For high-stakes observability use cases, log the prompt's correlation output alongside the raw tool call results in your trace store so that downstream debugging tools can compare the model's inferred relationships against ground truth.

Model choice matters here. This prompt requires strong reasoning over structured metadata and the ability to detect implicit relationships (e.g., two tool calls referencing the same user ID in different argument fields). Use a model with a large context window and strong JSON mode support—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate. Avoid small or fast models for this task unless you have a deterministic fallback for correlation failures. Set temperature=0 and enable structured output mode to enforce the correlation schema. Implement a retry budget of 2 attempts with exponential backoff; if both attempts produce invalid or incomplete correlation groups, escalate to a human operator with the raw tool call results and the failed correlation attempts. Do not silently accept partial correlations in production—an observability system that loses track of which results are related undermines the entire debugging workflow.