Real systems rarely get to assume one kind of input. The document pipeline receives invoices and contracts; the assistant fields questions and complaints. You could deploy a separate prompt per type — but then something upstream must classify first. The alternative is conditional branching: a single system prompt that says "if the input is X, do this; if Y, do that." Claude follows such instructions well when they're written with the same rigor you'd want in a runbook handed to a new colleague.
The anatomy of a branching prompt
A reliable conditional prompt has three parts, in order: how to recognize each input type, what to do for each, and what to do when nothing matches. Anthropic's best practices recommend structuring prompt sections with consistent, descriptive XML tags — which suits branches perfectly, one tag per case:
SYSTEM_PROMPT = """You process incoming customer emails.
First decide which ONE case applies, then follow only that case.
<case_complaint>
Applies when: the customer reports a problem or expresses dissatisfaction.
Do: acknowledge, summarize the issue in one sentence, apologize once,
state the concrete next step. Never offer compensation.
</case_complaint>
<case_cancellation>
Applies when: the customer asks to end or not renew a service.
Do: confirm the request back, list what ends and when, link the form.
</case_cancellation>
<case_other>
Applies when: neither case above clearly fits.
Do: answer if simple; otherwise route to a human with a one-line summary.
</case_other>"""Three details in that skeleton do the heavy lifting. The "decide first, then follow only that case" line prevents blended responses that mix branch behaviors. Each branch defines its own trigger, not just its action — per Anthropic's golden rule, if a colleague with minimal context couldn't tell which case applies, Claude can't either. And the explicit fallback branch means unrecognized inputs get designed behavior instead of improvisation.
Show the branches firing
Conditional prompts benefit disproportionately from few-shot examples. The official guidance calls for 3–5 relevant, diverse examples in <example> tags; for a branching prompt, "diverse" means at least one example per branch, plus one ambiguous input resolved the way you'd want. The ambiguous example matters most — it teaches the tie-breaking rule ("an unhappy customer who also asks to cancel is a cancellation") that prose alone states weakly.
It also helps to have Claude announce its decision. Requiring a first line such as case: complaint — or, more robustly, a case field constrained by an enum in a structured-outputs schema — makes every response auditable: you can log branch frequencies, spot misrouted inputs, and evaluate the classifier and the behaviors separately.
When to branch in the prompt — and when not to
Conditional logic in a prompt is judgment-based routing, and it earns its keep exactly when recognition requires judgment: tone, intent, content that resists regular expressions. When recognition is mechanical, don't spend model attention on it:
- Deterministic signals belong in code. If the file extension, sender domain, or form field already tells you the type, branch in your application and send a type-specific prompt. Code is free, instant, and never misreads.
- Many branches deserve a two-step chain. Anthropic's best-practices page includes chaining complex prompts as a technique in its own right. Past roughly a handful of cases, a giant conditional prompt turns into a wall of mostly-irrelevant instructions; a small classification call (see classification patterns) followed by a per-type prompt is easier to test and cheaper to maintain — each branch's prompt can be evaluated, versioned, and fixed independently.
- Branches that trigger actions may want tools instead. If "case: cancellation" should call your cancellation API, defining tools and letting Claude select one moves the branch decision into a structured, schema-validated channel rather than prose.
However you branch, test the seams. Build a small eval set with clear-cut inputs for every branch plus the ambiguous ones from production, and re-run it whenever a case definition changes — adding branch four is precisely when branch two quietly breaks. That's the empirical discipline Anthropic's prompt-engineering overview asks for before any tuning.
Where to go next
Branching interacts with rule precedence — see instruction hierarchy — and with splitting work across calls in task decomposition. For validating inputs before they hit a branch, read input validation.