[EAAPL-WRK011] Conditional Routing
Category: Agentic Workflows
Sub-category: Workflow Control Flow Architecture
Version: 1.0
Maturity: Industry Standard
Tags: conditional-routing, branching, workflow-control-flow, output-classification, loop-until, guard-clauses
Regulatory Relevance: ISO 42001 §8.4, APRA CPS 230, EU AI Act (Art. 9)
1. Executive Summary
The Conditional Routing Pattern defines control flow structures for agentic workflows: if/else branching based on LLM output classification, switch/case dispatch to specialist handlers, and loop-until iteration until a condition is met. Where the Router/Dispatcher (EAAPL-WRK004) routes incoming requests at the system entry point, Conditional Routing governs branching logic within an executing workflow — "based on what this step produced, which path do we take next?". It is the if-statement, switch-statement, and while-loop of agentic workflow programming.
For CIO/CTO audiences: real business workflows are not linear — they branch. A loan application that fails a fraud check takes a different path than one that passes. A document that is classified as "contract" is processed differently from one classified as "policy." A draft that doesn't meet quality criteria goes back for revision. This pattern brings those familiar control flow structures — familiar from every programming language — to AI workflows, enabling complex, branching business processes to be automated with full determinism and auditability. The key governance requirement is that every branch condition and its downstream implications must be documented and tested.
2. Problem Statement
Business Problem
Real enterprise workflows have conditional logic: a customer complaint classified as "billing dispute" takes a different resolution path than one classified as "product defect." An expense report above a threshold takes a different approval path than one below it. Implementing these conditional paths without explicit branching structures produces monolithic, unmaintainable workflows that conflate the routing logic with the execution logic.
Technical Problem
Without explicit conditional routing, developers embed branching logic inside individual step prompts ("If the document is a contract, do X; if it is a policy, do Y"), which is difficult to test, maintain, and extend. There is no separation between the classification decision and the execution path, making it impossible to unit-test branches independently.
Symptoms of Absence
- Long, complex prompts with embedded if/else logic in natural language
- Branches cannot be tested independently
- No explicit record of which branch was taken for audit purposes
- Adding a new branch requires modifying the existing step prompt, risking regressions
Cost of Inaction
- Maintainability: Embedded branching in prompts is unmanageable as workflow complexity grows
- Testability: Cannot test individual branches without executing the entire workflow
- Auditability: No explicit record of which conditions were evaluated and which branch was selected
3. Context
When to Apply
- Workflow has distinct execution paths triggered by LLM output classification or entity extraction
- Paths have materially different processing requirements (different tools, models, data sources)
- The branching condition and its downstream paths must be independently testable
- Branch selection must be recorded for audit purposes
When NOT to Apply
- All outputs take the same path regardless of content (no branching needed)
- Branching is at the system entry point (use Router/Dispatcher, EAAPL-WRK004)
- Branches have trivial differences that can be handled by prompt-level conditionals without structural impact
Prerequisites
- Defined branch conditions (classification labels, entity values, threshold comparisons)
- Branch condition classifier (LLM-based or rule-based)
- Separate handler implementations per branch
- Branch audit record format
Industry Applicability
| Industry |
Conditional Workflow |
Branch Conditions |
| Financial Services |
Loan assessment workflow |
Risk score → high/medium/low path → different approval requirements |
| Legal |
Document processing |
Document type → contract/policy/regulation → specialist review chain |
| Healthcare |
Clinical documentation |
Diagnosis category → different documentation template + guideline set |
| Insurance |
Claims processing |
Claim type + fraud risk → fast track / standard / investigation path |
| Government |
Application processing |
Completeness check → complete/incomplete/ineligible path |
4. Architecture Overview
Conditional routing implements three control flow primitives in agentic workflows, each with distinct characteristics:
If/Else (Binary Branch)
The simplest conditional: based on a binary classification (Yes/No, True/False, Pass/Fail), the workflow proceeds along one of two paths. The condition is evaluated by a classifier node that receives the current step's output and applies a defined classification function (rule-based or LLM-based). The classification result is recorded in the workflow state before any branch execution begins. If/else branching is the most auditable form: the condition, the classification result, and the downstream path are all explicit.
Switch/Case (Multi-way Branch)
Based on a categorical classification with N possible outcomes, the workflow routes to one of N specialist branches. Each case handler is a self-contained processing chain. After the branch completes, the workflow converges back to a common continuation path (post-switch processing). The switch node records the classification confidence and the selected case in the workflow state.
Loop-Until (Conditional Iteration)
The loop-until primitive repeats a workflow step until a condition is met or a maximum iteration count is reached. Common uses: retry until quality threshold is met, iterate until all required information is collected, poll until an external event occurs. The loop-until pattern is a controlled form of the iteration that ReAct (EAAPL-WRK001) uses, but applied to a specific, bounded sub-workflow rather than the entire reasoning loop.
Guard Clauses
Guard clauses are early-exit conditions evaluated at the beginning of a workflow step that short-circuit execution if preconditions are not met (similar to defensive programming patterns). Example: "If the input document is empty, exit immediately with an error; do not execute the analysis chain." Guard clauses are implemented as fast, cheap classifiers that prevent expensive processing of invalid inputs.
Branch Condition Classification
The classification that drives branching can be implemented at different quality/cost points:
- Rule-based: Exact match, keyword, numerical threshold — zero LLM cost, fully deterministic
- Embedding-based: Semantic classification by similarity to branch prototype embeddings — fast, low cost, handles paraphrase
- LLM-based: Prompted classification — most accurate for complex conditions; adds latency and cost
5. Architecture Diagram
flowchart TD
subgraph Input["Workflow Step Output"]
A[Step N Output]
end
subgraph Guard["Guard Clause"]
B{Precondition Check}
end
subgraph Switch["Switch Classifier"]
C[Branch Condition Classifier]
D{Branch Decision}
end
subgraph Branches["Execution Branches"]
E[Branch A Handler]
F[Branch B Handler]
G[Branch C Handler]
H[Default Branch]
end
subgraph Loop["Loop-Until Primitive"]
I[Loop Body Execution]
J{Exit Condition?}
K[Max Iteration Guard]
end
subgraph Convergence["Converge and Continue"]
L[Post-branch Continuation]
end
A --> B
B -->|precondition fails| M[Early Exit]
B -->|precondition passes| C
C --> D
D -->|case A| E
D -->|case B| F
D -->|case C| G
D -->|default| H
E & F & G & H --> L
L --> I
I --> J
J -->|condition met| N[Continue Workflow]
J -->|not yet| K
K -->|within limit| I
K -->|max reached| N
6. Components
| Component |
Type |
Responsibility |
Technology Options |
Criticality |
| Guard Clause Evaluator |
Logic Component |
Evaluates preconditions; short-circuits on failure |
Rule engine; regex; custom validation logic |
High |
| Branch Condition Classifier |
AI/Logic Component |
Classifies step output to determine branch direction |
Rule-based; embedding similarity; LLM prompt |
Critical |
| Branch State Recorder |
State |
Records classification result and selected branch in workflow state |
Workflow state object; JSONB field |
Critical |
| Branch Handlers (N) |
AI Components |
Execute the specific processing for each branch |
Any EAAPL-WRK pattern per branch |
Critical |
| Convergence Coordinator |
Orchestration |
Collects branch output; proceeds to continuation step |
Workflow orchestrator (LangGraph, Step Functions) |
High |
| Loop Controller |
State + Logic |
Manages iteration count; evaluates exit condition; enforces max iterations |
Counter in loop state; configurable max |
Critical |
| Branch Audit Logger |
Governance |
Records: condition evaluated, classification result, branch selected, confidence |
PostgreSQL; CloudWatch Logs |
High |
7. Data Flow
| Step |
Actor |
Action |
Output |
| 1 |
Workflow |
Step 3 produces document analysis output |
{document_content: "...", type: null} |
| 2 |
Guard Clause |
Checks: is document_content non-empty? Length > 50 chars? |
PASS — proceed to classification |
| 3 |
Branch Classifier |
LLM classifies document type |
{branch: "contract", confidence: 0.94} |
| 4 |
Branch State |
Records classification |
Workflow state: {branch_decision: "contract", confidence: 0.94, step: 3} |
| 5 |
Branch Handler (contract) |
Executes Contract Review Chain (EAAPL-WRK002) |
Contract analysis result |
| 6 |
Convergence |
Branch result added to workflow state |
Workflow continues to Step 5 (report generation) |
| 7 |
Loop Controller |
Step 5 checks quality threshold; current score 72 < required 85 |
Loop — iteration 1/3 |
| 8 |
Loop Body |
Revision step executed |
Revised output; quality score 88 |
| 9 |
Loop Controller |
88 ≥ 85; exit condition met |
Exit loop; continue workflow |
Error Flow
| Error |
Detection |
Recovery |
| Guard clause fails |
Precondition evaluator |
Early exit with structured error; do not execute expensive branches |
| Classifier returns low confidence |
Confidence threshold check |
Route to default branch with low-confidence flag; alert for monitoring |
| Branch handler fails |
Branch execution error |
Route to default branch; log branch failure |
| Loop max iterations reached |
Loop controller |
Exit loop with current best output + status: loop_max_reached flag |
8. Security Considerations
Branch Bypassing via Classification Manipulation
- If an attacker can manipulate the input to force classification to a specific branch (e.g., force routing to the highest-privilege branch), they could access processing paths they are not intended to access
- Mitigation: Branch handlers enforce their own access control independently; classification determines path, not permission
OWASP LLM Top 10
| OWASP LLM Risk |
Conditional Routing Applicability |
Mitigation |
| LLM01 Prompt Injection |
Input to classifier may be attacker-controlled |
Input sanitisation before classification; content delimiters |
| LLM08 Excessive Agency |
Branching to high-capability handlers based on misclassification |
Each branch handler has its own permission scope; classification does not grant permissions |
| LLM09 Overreliance |
Automated branching without human review of classification decision |
Log classification confidence; human review gate for low-confidence high-stakes branches |
9. Governance Considerations
Branch Coverage Testing
- Every defined branch must have test cases that exercise it; branches that are never tested may contain latent defects
- Branch coverage is a mandatory metric for conditional routing workflows in regulated processes
Governance Artefacts
| Artefact |
Owner |
Frequency |
Purpose |
| Branch Definition Document |
AI Platform |
On change |
Documents all branches, conditions, handlers, and default paths |
| Branch Coverage Test Report |
QA |
On deployment |
Confirms every branch has been exercised by test suite |
| Branch Decision Audit Log |
Compliance |
Per workflow execution |
Records classification result and branch taken per execution |
| Classifier Performance Report |
ML Engineering |
Monthly |
Per-branch precision/recall; identifies misclassification patterns |
10. Operational Considerations
SLOs
| SLO |
Target |
Window |
Alert |
| Classification accuracy (correct branch for known input) |
≥ 97% |
Weekly eval |
< 94% triggers P2; classifier retraining |
| Default branch usage rate |
≤ 5% |
24-hour rolling |
> 10% triggers P3; review classifier coverage |
| Loop-until completion rate (within max iterations) |
≥ 95% |
24-hour rolling |
< 90% triggers P2 |
| Guard clause rejection rate |
≤ 3% |
24-hour rolling |
> 10% triggers P3; check input quality |
11. Cost Considerations
| Routing Method |
Cost per Classification |
Accuracy |
Use When |
| Rule-based (free) |
$0 |
High for deterministic conditions |
Numerical thresholds, exact match |
| Embedding similarity |
~$0.0001 |
High |
Semantic variety; paraphrase |
| LLM classification (small model) |
$0.001–0.005 |
Very High |
Complex, nuanced conditions |
| Loop-until (per additional iteration) |
+1× step cost per iteration |
N/A |
Quality gates; bounded iteration |
12. Trade-Off Analysis
| Control Flow Type |
Auditability |
Flexibility |
Complexity |
Best For |
| Guard clause |
Very High |
Low |
Very Low |
Input validation; fast precondition check |
| Rule-based if/else |
Very High |
Low |
Low |
Deterministic conditions; regulated decisions |
| LLM-based switch |
High |
Very High |
Medium |
Complex semantic classification |
| Loop-until |
High |
High |
Medium |
Quality gates; iterative refinement |
13. Failure Modes
| Failure Mode |
Likelihood |
Impact |
Detection |
Recovery |
| Classifier systematic misrouting |
Medium |
High — wrong handler for all similar inputs |
Branch distribution monitoring; eval benchmark |
Classifier retrain; add rule-based override for systematic error |
| Loop never exits (condition never met) |
Low |
High — infinite cost |
Max iteration guard |
Hard iteration limit; return best output on exhaustion |
| Default branch overwhelmed |
Medium |
Medium — generic handler slow under load |
Default branch usage rate |
Expand classifier to cover high-volume default triggers |
| Branch state corruption (branch result not recorded) |
Low |
Medium — downstream steps use wrong state |
State validation after branch |
Schema validation of workflow state after each branch |
14. Regulatory Considerations
ISO 42001
- §8.4: Every conditional branch is an operational decision point; the branch condition, classification logic, and downstream handler must all be documented and version-controlled.
APRA CPS 230
- For automated decision-making processes, the branch decision record constitutes evidence that the correct procedure was followed. Must be retained per the organisation's records management policy.
EU AI Act
- Art. 9 (Risk Management): For high-risk AI systems, each conditional branch affecting a regulated decision must be risk-assessed and the branch coverage test must demonstrate that all branches have been validated.
15. Reference Implementations
AWS
| Component |
Service |
| Guard Clause + Classifier |
Lambda function |
| Branch Control Flow |
AWS Step Functions Choice state |
| Branch Handlers |
Lambda functions per branch |
| Loop-Until |
Step Functions Wait state with callback token |
| Audit Log |
CloudWatch Logs with structured branch decision events |
Azure
| Component |
Service |
| Branch Control Flow |
Azure Durable Functions with switch pattern; Logic Apps condition actions |
| Classifier |
Azure OpenAI Function calling or Azure AI Language |
| Branch Handlers |
Azure Functions per branch |
On-Premises
| Component |
Technology |
| Control Flow |
LangGraph conditional edges (add_conditional_edges); custom if/switch |
| Classifier |
Custom Python; Semantic Router |
| Pattern |
ID |
Relationship Type |
Notes |
| Router/Dispatcher |
EAAPL-WRK004 |
Peer |
Dispatcher routes at system entry; conditional routing routes within a workflow |
| Sequential Chain |
EAAPL-WRK002 |
Extends |
Conditional routing adds branching logic to a sequential chain |
| Workflow State Machine |
EAAPL-WRK012 |
Peer |
State machine is a formal model for conditional transitions; this pattern implements common control flow primitives |
| Iterative Constraint Satisfaction |
EAAPL-WRK015 |
Implements |
Loop-until is the iteration primitive used by constraint satisfaction |
17. Maturity Assessment
Overall Maturity: Industry Standard
| Dimension |
Score (1–5) |
Evidence |
| Research Foundation |
4 |
Workflow control flow well-established; LLM-based classification for routing mature |
| Production Deployment |
5 |
Implemented in every enterprise workflow tool; universally deployed |
| Framework Support |
5 |
LangGraph conditional edges; Step Functions Choice; Logic Apps; LangChain routers |
| Testing Tooling |
3 |
Branch coverage tooling maturing; LLM classifier testing frameworks developing |
| Audit Support |
4 |
Step Functions and LangGraph execution history provides branch audit trail |
18. Revision History
| Version |
Date |
Author |
Changes |
| 1.0 |
2025-06-13 |
Architecture Board |
Initial publication in Agentic Workflows category |