Agent Fan-Out Fan-In Execution Prompt

This prompt is designed for orchestration engineers who need to decompose a complex, high-level task into independent sub-tasks that can be executed concurrently by a pool of specialized worker agents. The primary job-to-be-done is generating a deterministic fan-out plan that maps each sub-task to a capable worker, executing those tasks in parallel, and then applying a structured fan-in merge strategy to resolve conflicts and produce a single, coherent output for a downstream consumer. The ideal user is an AI platform engineer or workflow builder who already has a registry of defined worker agents with clear capability contracts, input/output schemas, and known failure modes.

Use this prompt when the input task contains work units that are truly independent and do not require sequential handoffs or shared mutable state during execution. For example, it is appropriate for researching a topic across five different knowledge domains simultaneously, processing a batch of independent customer tickets, or generating multiple creative variants that must be synthesized into one final recommendation. The prompt assumes you can provide a list of available worker agents, their capabilities, and the raw task input. It will produce a structured execution plan that includes worker assignments, a merge strategy with explicit conflict resolution rules, and a completion gate that defines when the aggregated result is ready. Do not use this prompt for sequential pipelines where step B depends on the output of step A, for single-agent workflows, or when you lack defined worker agents with stable interfaces.

Before wiring this into a production harness, validate that your worker agents are truly independent and that your merge strategy can handle the most common failure modes: missing worker results, conflicting outputs, and partial aggregation. If the merge logic requires subjective judgment or the cost of an incorrect aggregation is high, insert a human review step before the final output is released. Start by testing with a small, known set of sub-tasks and compare the aggregated output against a hand-merged gold standard to calibrate your conflict resolution rules.

This prompt is the execution contract for your orchestrator agent. It receives a complex task, decomposes it into parallelizable sub-tasks, assigns each to a logical worker, defines the merge strategy for combining results, and enforces a completion gate before returning a final answer. Replace every square-bracket placeholder with runtime values from your application context before sending this to the model.

textCopy
You are an orchestration agent responsible for fan-out/fan-in execution.

## INPUT
[INPUT]

## CONTEXT
[CONTEXT]

## OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "fan_out_plan": [
    {
      "worker_id": "string",
      "task_description": "string",
      "required_inputs": ["string"],
      "expected_output_schema": {},
      "dependencies": ["worker_id"]
    }
  ],
  "fan_in_strategy": {
    "merge_method": "concatenate | vote | union | custom",
    "conflict_resolution": "string describing how to resolve conflicting results",
    "ordering": "preserve_input_order | sort_by_confidence | custom",
    "deduplication_key": "string | null"
  },
  "completion_gate": {
    "required_workers": ["worker_id"],
    "minimum_results": "number",
    "timeout_behavior": "return_partial | fail | escalate",
    "quality_check": "string describing final validation before returning"
  }
}

## CONSTRAINTS
[CONSTRAINTS]

## TOOLS AVAILABLE
[TOOLS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Analyze the INPUT and decompose it into sub-tasks that can execute in parallel where possible.
2. For each sub-task, define a worker with a clear task_description, required_inputs, and expected_output_schema.
3. Identify any dependencies between workers. Workers with no dependencies can run in parallel.
4. Define the fan_in_strategy: how to merge results, resolve conflicts, and handle duplicates.
5. Define the completion_gate: which workers must complete, the minimum result count, and what to do on timeout.
6. If the RISK_LEVEL is high, include a human_approval step in the completion gate.
7. Return ONLY the JSON object. No explanatory text outside the JSON.

## RISK LEVEL
[RISK_LEVEL]

Adaptation notes: The fan_in_strategy.merge_method field should match your actual aggregation logic. Use concatenate when workers produce independent lists, vote when multiple workers answer the same question, union when combining non-overlapping structured fields, and custom when you need a domain-specific merge function. The completion_gate.quality_check field is your last line of defense—describe a concrete validation rule here, such as "confirm all required fields are non-null" or "verify no contradictory claims exist across merged results."

Risk-aware gating: When [RISK_LEVEL] is set to high, the completion gate must include a human_approval_required: true flag and a review_summary field that the orchestrator populates before pausing for human sign-off. Do not skip this gate in regulated workflows. For low-risk batch processing, the gate can auto-approve if all workers return valid, schema-conforming outputs.

What to avoid: Do not treat this prompt as a one-shot answer generator. It produces an execution plan, not the final result. The orchestrator must iterate over the plan, dispatch workers, collect outputs, apply the merge strategy, and enforce the completion gate in application code. The prompt defines the contract; your harness executes it. Also avoid over-parallelization—workers with hidden data dependencies will produce merge conflicts that the conflict_resolution string alone cannot fix without application-level reconciliation logic.

The fan-out/fan-in prompt is not a standalone chat interaction—it is a control-plane instruction that must be embedded inside an orchestration harness. The harness is responsible for parsing the model's structured plan, dispatching each worker task to the appropriate agent or tool, collecting results with timeouts, and executing the merge strategy. Treat the prompt output as a machine-readable execution manifest, not as advice to a human operator. The harness should validate the plan before any worker is invoked: check that every task has a defined owner, that no two workers are assigned conflicting mutable resources, and that the merge strategy explicitly handles missing or partial results.

Implement the harness as a state machine with four phases: Plan Validation, Fan-Out Dispatch, Result Collection, and Fan-In Merge. In the Plan Validation phase, parse the model's JSON output and reject the plan if it contains cycles, unassigned tasks, or merge strategies that reference non-existent workers. In Fan-Out Dispatch, issue each worker task as an asynchronous call with a per-task deadline. Use a task queue or async executor (Celery, Temporal, AWS Step Functions) rather than fire-and-forget threads—you need durable task state. Each worker invocation should carry a correlation ID, the original task specification, and a callback endpoint or result topic. In the Result Collection phase, maintain a results ledger keyed by task ID with statuses: pending, completed, timed_out, errored, or partial. The harness must enforce a global fan-in deadline; when it fires, proceed to merge with whatever results are available rather than blocking indefinitely.

The Fan-In Merge phase is the highest-risk step. Do not simply concatenate worker outputs. The merge strategy from the prompt—whether it specifies deduplication by key, conflict resolution by timestamp or confidence score, or a voting mechanism—must be executed deterministically in application code, not by asking another LLM to 'figure it out.' For conflict resolution, implement a merge resolver function that takes conflicting records and applies the declared strategy. Log every conflict and its resolution for auditability. If the merge strategy cannot be applied because required fields are missing from worker results, escalate to a human review queue with the partial aggregate and the raw worker outputs. After merging, run a completion gate check: verify that all required output fields are populated, that no worker result was silently dropped, and that the aggregate output conforms to the expected schema. If the gate fails, retry the fan-in with a repair prompt that receives the validation errors and the raw results, or escalate.

For model choice, use a model with strong structured-output and instruction-following capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) for the planning prompt. Worker tasks may use smaller, cheaper models if their sub-task is narrow. Instrument every phase with OpenTelemetry spans: plan generation, plan validation, each worker dispatch, result collection, merge execution, and gate check. Emit structured logs at each transition so operators can trace a single fan-out/fan-in execution end-to-end. Store the raw plan, worker results, merge decisions, and final aggregate in an append-only execution record. This record is your debugging surface when a stakeholder asks why a particular result was included or excluded.

Common harness failures to guard against: (1) The model produces a valid-looking plan that references tools or agents that don't exist—validate against a live capability registry before dispatch. (2) A worker returns a result after the fan-in deadline—decide whether late results should trigger a re-aggregation or be logged for the next run. (3) The merge strategy is ambiguous when two workers produce equally valid but contradictory outputs—pre-define a tie-breaking rule (e.g., prefer the worker with higher declared confidence, or escalate). (4) A worker task times out but the merge strategy treats 'no result' as equivalent to 'empty result'—distinguish these cases explicitly in the results ledger. Build these failure modes into your integration tests with synthetic worker responses before running production workloads.