Conditional Branching in Tool Sequences Prompt Template

This prompt is for agent developers building non-linear tool execution workflows where the next step depends on the output of a previous tool call. Use it when your agent must evaluate intermediate results against explicit conditions and select from multiple downstream paths. The core job-to-be-done is producing a structured, auditable branching specification that your execution harness can follow deterministically—not generating a freeform plan or a linear sequence of steps. The ideal user is an AI engineer or platform developer who already has a set of available tools with known input/output schemas and needs the model to define the control flow between them. You should have tool descriptions, expected output shapes, and the conditions that matter for routing decisions ready before invoking this prompt.

This is not a planning prompt for linear sequences. If your workflow is a fixed order of tool calls with no branching, use the Tool Call Sequence Planning Prompt Template instead. Do not use this prompt when the branching logic is trivial enough to hard-code in your application layer—introducing an LLM call for a simple if-else on a status code adds latency and a failure surface with no benefit. The prompt forces the model to define conditions as testable predicates (e.g., status == 'completed' AND confidence > 0.8), enumerate all branch targets explicitly, and specify how divergent paths merge. This prevents the three most common production failures: dead paths that are never reached because conditions are impossible to satisfy, ambiguous conditions that match multiple branches simultaneously, and merge points that lose state accumulated in earlier steps. Before using this prompt, confirm that your execution harness can parse the branching specification, evaluate predicates against real tool outputs, and route to the correct next tool call.

The prompt assumes you have a defined set of available tools and that each tool's output schema is known at the time of branching specification. It does not handle dynamic tool discovery or runtime tool registration—those concerns belong in the tool discovery and registration playbooks. For high-risk domains where incorrect branching could trigger irreversible actions (e.g., financial transactions, clinical decisions, infrastructure changes), pair this prompt's output with a human approval gate before execution. The branching specification itself should be logged as part of your audit trail so that reviewers can understand why the agent chose a particular path. If your workflow requires mid-execution replanning when intermediate results diverge from expectations, combine this prompt with the Mid-Plan Correction Prompt for Agent Workflows to handle both initial branching design and runtime adaptation.

This template encodes conditional branching logic directly into the agent's system instructions. Instead of relying on the model to implicitly decide what to do next, it forces explicit condition evaluation after each tool call, maps results to named branches, and defines merge points where parallel paths converge. The template is designed for non-linear workflows—approval gates, fallback chains, A/B tool selection, and error-recovery paths—where the next step depends on the output of the previous step in ways that a static plan cannot predict.

textCopy
You are an agent that executes tool sequences with conditional branching. After each tool call, you must evaluate the result against explicit conditions before selecting the next action.

## BRANCHING RULES
1. After every tool call, pause and evaluate the result against the conditions defined in [BRANCH_CONDITIONS].
2. Select exactly one branch based on the first matching condition. Conditions are evaluated in order.
3. If no condition matches, follow the [DEFAULT_BRANCH].
4. Never skip condition evaluation. Never execute a tool from a branch whose condition did not match.

## BRANCH DEFINITIONS
[BRANCH_CONDITIONS]

## DEFAULT BRANCH
[DEFAULT_BRANCH]

## MERGE RULES
When multiple branches converge to a shared subsequent step:
- [MERGE_STRATEGY]
- Preserve all outputs from completed branches unless [MERGE_STRATEGY] specifies otherwise.
- If branches produce conflicting values for the same field, resolve using [CONFLICT_RESOLUTION_RULE].

## ABORT CONDITIONS
Stop execution immediately and report to [ESCALATION_TARGET] if:
[ABORT_CONDITIONS]

## STATE TRACKING
Maintain a branch execution log with:
- Branch name taken
- Condition that triggered it
- Tool calls executed within the branch
- Outputs produced
- Whether the branch completed or was aborted

## CONSTRAINTS
- Maximum [MAX_BRANCH_DEPTH] nested branches.
- Maximum [MAX_TOTAL_STEPS] total tool calls across all branches.
- If [REQUIRE_HUMAN_APPROVAL_BRANCHES] is true, pause and request approval before executing any tool in branches: [APPROVAL_BRANCH_LIST].

## TOOLS AVAILABLE
[TOOLS]

## INPUT
[INPUT]

## OUTPUT FORMAT
Return a structured execution trace:
{
  "branches_taken": [
    {
      "branch_name": "string",
      "condition_matched": "string",
      "tool_calls": [...],
      "outputs": {...},
      "status": "completed|aborted|awaiting_approval"
    }
  ],
  "merge_result": {...},
  "final_status": "success|partial_success|aborted|escalated"
}

To adapt this template, replace [BRANCH_CONDITIONS] with a structured list of condition-outcome pairs—for example, IF tool_output.status == 'error' THEN execute fallback_tool_chain or IF tool_output.confidence < 0.8 THEN request_human_review. Each condition must be unambiguous and testable. The [DEFAULT_BRANCH] is your catch-all; make it safe—escalate to a human or log for review rather than proceeding blindly. [MERGE_STRATEGY] should specify whether branches combine results (union), pick one (priority), or require all to complete (join). For high-risk workflows, set [REQUIRE_HUMAN_APPROVAL_BRANCHES] to true and list branches that trigger irreversible actions. Before deploying, test every branch path with mocked tool outputs that exercise boundary conditions, missing fields, and unexpected status codes. A branch that is defined but never reachable is a dead path—remove it or add a test that hits it.

The conditional branching prompt produces a specification—a set of conditions, branch paths, and merge strategies—but it does not execute them. To turn this specification into a working agent, you need a harness that parses the model's output, evaluates conditions against live tool results, routes execution to the correct branch, and enforces safety boundaries. The harness is the runtime interpreter for the branching logic the prompt defines. Without it, the prompt is just documentation.

Build the harness around a structured output contract. Require the model to return a JSON object with a conditions array, where each condition has an id, a predicate (expressed as a human-readable rule and a machine-evaluable expression referencing tool output fields), a true_branch with the next tool call or sub-sequence, a false_branch, and a merge_point identifier. Parse this output and store it as the active execution graph. When a tool returns a result, evaluate each active condition's predicate against the result payload. Use a simple expression evaluator that supports equality checks, numeric comparisons, and field existence tests—avoid injecting model-generated code directly into an eval() context. If a predicate cannot be evaluated because a referenced field is missing, treat it as a branch failure and escalate to the on_ambiguity handler defined in the prompt's [CONSTRAINTS].

Implement a branch coverage tracker that logs every condition evaluated, the input values that triggered it, which branch was taken, and whether the branch completed successfully. This is not optional for production systems. Silent branch failures—where a condition evaluates to an unexpected path due to a null field or type mismatch—are the most common failure mode in conditional tool sequences. Your harness should detect dead branches (conditions that never evaluate to true across a test suite) and unreachable merge points. Wire these metrics into your observability stack so you can alert on branch coverage drops after prompt or tool schema changes.

Add a circuit breaker around branch evaluation loops. A common failure mode is a condition that oscillates between branches because the predicate depends on a field that changes with each tool call. Set a maximum branch transition count per sequence (start with 10) and a time-to-live for the overall execution graph. If the harness detects the same condition evaluating to alternating branches more than three times, abort the sequence, log the oscillation pattern, and return a partial result with an unresolved_branch error to the calling system. This prevents infinite loops that burn tokens and tool call budgets.

Wire the harness to respect the [RISK_LEVEL] and [CONSTRAINTS] from the prompt template. If the risk level is high, insert a human approval gate before executing any branch that leads to a destructive tool call (writes, deletes, sends). The gate should present the condition that was met, the tool call about to execute, and the evidence that triggered the branch. If the risk level is critical, require approval for every branch transition, not just destructive ones. For low-risk sequences, you can execute branches autonomously but must still log every transition for auditability. The next step is to test this harness against the failure modes documented in the prompt's eval section—start with missing fields, type mismatches, and oscillating predicates before moving to integration tests with real tools.