Conditional Branching Dispatch Prompt Template

This prompt is designed for AI agent platform builders who need a deterministic, auditable routing decision after an initial classification step. The core job-to-be-done is evaluating multiple business rules, feature flags, or state-based conditions against input attributes and prior classification results to select a single, correct processing branch. The ideal user is an engineering lead or platform architect building a multi-step AI pipeline where a wrong branch selection leads to incorrect tool use, broken user experiences, or compliance violations. You must have already classified the input's intent, priority, or risk tier before using this prompt; it does not perform open-ended reasoning or classification itself.

Use this prompt when your system requires a traceable, rule-based dispatch decision that downstream workflow engines can act on without ambiguity. The prompt expects structured inputs such as [CLASSIFICATION_OUTPUT], [USER_ATTRIBUTES], [SESSION_STATE], and a defined [BRANCH_CONDITIONS] schema. It is ideal for scenarios like routing a high-priority, authenticated user's refund request to an expedited handler while sending a low-priority, guest inquiry to a self-service queue. Do not use this prompt for multi-branch parallel execution, open-ended conversational routing, or when the conditions themselves require complex inference rather than straightforward attribute checks. For those cases, a more open-ended planning or intent-detection prompt is appropriate.

Before implementing, ensure you have a well-defined set of branches with mutually exclusive conditions. The prompt's effectiveness depends entirely on the clarity and completeness of the [BRANCH_CONDITIONS] you provide. A common failure mode is overlapping conditions that make the selection non-deterministic. To mitigate this, always include a default or fallback branch and test for condition coverage. The next step is to copy the prompt template and adapt the [BRANCH_CONDITIONS] and [OUTPUT_SCHEMA] placeholders to match your specific workflow state machine. Avoid using this prompt for high-frequency, latency-critical paths where a simple application-level switch statement would suffice; reserve it for complex, multi-attribute evaluations that benefit from an LLM's ability to interpret nuanced policy descriptions.

This template provides the core dispatch logic for a conditional branching router. It is designed to be copied directly into your prompt management system or codebase. The prompt instructs the model to act as a deterministic rules engine, evaluating a set of ordered conditions against provided input attributes. The output is a structured JSON object containing the selected branch, the satisfied condition, and a trace of the evaluation path for auditability. This is not a conversational prompt; it is a machine-to-machine instruction set for a critical routing junction in your AI pipeline.

textCopy
You are a deterministic dispatch router. Your task is to evaluate the provided [INPUT_ATTRIBUTES] against a predefined decision tree and return the single correct branch. Do not improvise. Do not use outside knowledge. If no conditions are met, select the [DEFAULT_BRANCH].

## Decision Tree
Evaluate the following conditions in strict top-to-bottom order. The first condition that evaluates to `true` determines the branch. Stop evaluation immediately upon a match.

1.  **Condition:** [CONDITION_1_DESCRIPTION]
    **Branch ID:** [BRANCH_1_ID]
2.  **Condition:** [CONDITION_2_DESCRIPTION]
    **Branch ID:** [BRANCH_2_ID]
3.  **Condition:** [CONDITION_3_DESCRIPTION]
    **Branch ID:** [BRANCH_3_ID]

## Input Attributes
[INPUT_ATTRIBUTES]

## Output Schema
Return ONLY a valid JSON object. Do not include any text outside the JSON block.
{
  "selected_branch": "[BRANCH_ID]",
  "matched_condition": "[CONDITION_DESCRIPTION]",
  "evaluation_trace": [
    {
      "condition": "[CONDITION_1_DESCRIPTION]",
      "result": true | false
    },
    ...
  ],
  "reasoning": "Brief, factual explanation of why the condition was met, referencing specific input attributes."
}

## Constraints
- [CONSTRAINT_1, e.g., 'If attribute X is missing, treat it as false.']
- [CONSTRAINT_2, e.g., 'Case-insensitive string comparison for all text fields.']

To adapt this template, replace the square-bracket placeholders with your specific logic. The [INPUT_ATTRIBUTES] should be a clear, structured list of the data points available for evaluation, such as intent: "refund", priority_score: 0.9, or user_tier: "enterprise". Define your conditions precisely, using boolean logic where necessary. The [DEFAULT_BRANCH] is a critical safety net; it should route to a safe fallback queue, a human review bucket, or a dead-letter queue for unhandled cases. After implementing, you must test this prompt with a suite of inputs that covers every branch, including the default, to ensure the evaluation order and logic are correct.

The Conditional Branching Dispatch Prompt is not a standalone chatbot; it is a deterministic routing component inside a larger AI pipeline. The prompt evaluates multiple conditions against input attributes and classification results to select exactly one processing branch. In production, this prompt should be called after upstream classification is complete, with all required attributes already extracted and normalized. The prompt's output must be a structured branch selection that downstream orchestrators can act on without further interpretation. This means the application layer is responsible for providing clean, typed inputs and consuming a machine-readable routing decision, not free-text reasoning.

To wire this prompt into an application, wrap it in a function that accepts a validated input object containing the required attributes (e.g., intent_label, priority_score, confidence, customer_tier, data_residency_region) and returns a structured routing decision. Before calling the model, validate that all required fields are present and within expected ranges. After receiving the model response, parse the output against a strict schema that includes selected_branch_id, branch_label, conditions_matched, and audit_trail. If parsing fails, retry once with a stronger format constraint appended to the prompt. If the retry also fails, route to a designated fallback queue and log the failure for investigation. For high-risk domains such as healthcare, finance, or legal workflows, insert a human review step before executing the selected branch when the confidence score falls below a configured threshold or when the conditions matched include a requires_approval flag.

Model choice matters here. This prompt requires strong instruction-following and structured output discipline, not creative reasoning. Use a model with reliable JSON mode or function-calling support, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that may hallucinate branch IDs or ignore condition precedence. Set temperature=0 to maximize determinism. Log every dispatch decision with the full input attributes, the model's raw response, the parsed branch selection, and the timestamp. This audit trail is essential for debugging misroutes, proving compliance, and measuring branch coverage over time. If your system uses multiple models or prompt versions, include the model ID and prompt version in the log as well.

Before deploying, build a test harness that exercises every defined branch with representative inputs. Include edge cases where multiple conditions could match and verify that the prompt respects the specified precedence rules. Add negative test cases where no conditions should match and confirm the prompt selects the designated default or fallback branch rather than hallucinating. Monitor production traffic for branch distribution anomalies, unexpected fallback rates, and condition evaluation mismatches. If you observe drift—such as a branch that should be rare suddenly receiving high traffic—investigate upstream classification changes before adjusting the prompt. The prompt itself should be version-controlled alongside the application code, with each change reviewed for impact on downstream workflows.