Level 2 Agents: Router Pattern Deep Dive

The simplest agents follow fixed paths. They receive input, process it, and produce output in a predetermined sequence. But real-world problems rarely fit neat linear patterns. Users ask questions that require different handling strategies. Tasks branch based on content type. Workflows diverge depending on context.

Level 2 agents solve this through the router pattern. Instead of following a single path, the LLM examines the input and decides which path to take. This transforms agents from rigid pipelines into intelligent systems that adapt to the task at hand.

This guide explores the router pattern in depth. You will understand when to use routing, how to implement effective routers, and common patterns that make routing reliable.

Understanding the Router Pattern

What Makes a Router Agent?

A router agent has one primary job: examine input and decide where to send it. Unlike Level 1 agents that execute a fixed sequence, router agents introduce decision points where the LLM chooses between multiple paths.

The key characteristics of router agents:

Decision Points The LLM evaluates input at defined points and selects from available options. This might mean choosing between functions, selecting a processing strategy, or directing to different sub-workflows.

Explicit Options Router agents work with defined paths. The LLM does not invent new routes; it selects from established alternatives. This bounded choice makes routing predictable and debuggable.

Context-Aware Selection The routing decision considers the full context: the input content, user intent, current state, and any relevant metadata. The LLM uses this context to make intelligent selections.

Router vs. Level 1 Agents

Consider a document processing system. A Level 1 agent might:

Input → Parse → Extract → Format → Output

Every document follows the same path regardless of type.

A Level 2 router agent:

Input → Classify Document Type
        ├── PDF → Extract with PDF Parser
        ├── Word → Extract with DOCX Parser
        ├── Image → OCR Processing
        └── Unknown → Human Review Queue

The router agent handles diverse inputs appropriately. Each document type gets specialized processing.

The Anatomy of a Routing Decision

Every routing decision has three components:

1. Classification Context Information the LLM uses to make the decision. This includes the input content, metadata, user history, and any relevant state.

2. Route Definitions The available paths the LLM can select. Each route has clear criteria for when it should be chosen and what processing it provides.

3. Selection Logic The reasoning process the LLM uses to match context to routes. This logic should be explicit in your agent design.

Implementing Router Agents

Basic Router Structure

A router agent in Claude Code follows this pattern:

---
description: Routes customer inquiries to appropriate handlers
version: 1.0.0
tools:
  - filesystem
  - shell
---

# Customer Inquiry Router

## Objective

Analyze incoming customer inquiries and route them to the appropriate handling workflow based on inquiry type, urgency, and customer context.

## Available Routes

### Route: Technical Support
**Criteria:**
- Inquiry mentions product issues, bugs, or errors
- Customer describes something not working as expected
- Questions about technical implementation or integration

**Handler:** Technical support workflow

### Route: Billing
**Criteria:**
- Questions about charges, invoices, or payments
- Subscription or plan changes
- Refund requests

**Handler:** Billing support workflow

### Route: Sales
**Criteria:**
- Pricing questions for new customers
- Enterprise or volume inquiries
- Feature comparison questions

**Handler:** Sales team workflow

### Route: General
**Criteria:**
- Does not match specific categories
- General product questions
- Feedback or suggestions

**Handler:** General support workflow

## Routing Process

1. Read the incoming inquiry
2. Identify key signals (keywords, tone, context)
3. Match signals against route criteria
4. Select the best matching route
5. Hand off to appropriate handler with context summary

Multi-Criteria Routing

Simple keyword matching breaks quickly. Effective routers consider multiple criteria:

## Routing Decision Framework

### Primary Signals (Weight: 40%)
Content analysis of the inquiry text:
- Technical terms → Technical Support
- Financial terms → Billing
- Buying signals → Sales

### Secondary Signals (Weight: 30%)
Customer context from their history:
- Active support tickets → Technical Support priority
- Recent purchase → Billing priority
- Trial user → Sales priority

### Urgency Signals (Weight: 20%)
Time sensitivity indicators:
- Words like "urgent," "ASAP," "down" → Expedited handling
- Standard language → Normal queue

### Sentiment Signals (Weight: 10%)
Emotional context:
- Frustrated language → Senior handler
- Neutral/positive → Standard handler

Confidence-Based Routing

Routers should express confidence in their decisions:

## Confidence Levels

### High Confidence (>80%)
- Clear, unambiguous signals
- Single obvious route match
- Action: Route directly

### Medium Confidence (50-80%)
- Mixed signals
- Multiple possible routes
- Action: Route to best match, flag for review

### Low Confidence (<50%)
- Unclear or conflicting signals
- No strong route match
- Action: Route to human triage queue

Router Pattern Variations

Hierarchical Routing

For complex systems, use multi-level routing:

## Level 1: Domain Router
├── Customer Service Domain
│   └── Level 2: Service Type Router
│       ├── Technical
│       ├── Billing
│       └── General
├── Internal Operations Domain
│   └── Level 2: Department Router
│       ├── HR
│       ├── IT
│       └── Facilities
└── Partner Domain
    └── Level 2: Partner Type Router
        ├── Vendor
        ├── Reseller
        └── Integration

Each level refines the routing decision with more specific criteria.

Semantic Routing

Use embeddings for meaning-based routing:

## Semantic Router

### Setup
1. Create embeddings for each route's description
2. Store route embeddings for comparison

### Routing Process
1. Generate embedding for incoming query
2. Calculate similarity to each route embedding
3. Select route with highest similarity above threshold
4. If no route exceeds threshold, use fallback

This approach handles paraphrasing and variant expressions that keyword matching misses.

Dynamic Routing

Routes can change based on current state:

## Dynamic Route Configuration

### Load-Based Routing
- If Technical Support queue > 50: Overflow to General
- If Billing team offline: Route to voicemail callback

### Time-Based Routing
- Business hours: Route to live agents
- After hours: Route to async queue

### Capacity-Based Routing
- Check handler availability before routing
- Distribute load across available handlers

Building a Complete Router Example

Let us build a code review router that directs reviews to appropriate specialists:

---
description: Routes code reviews to appropriate specialist reviewers
version: 1.0.0
tools:
  - filesystem
  - git
---

# Code Review Router

## Objective

Analyze incoming code changes and route to the most appropriate reviewer based on the code characteristics, change scope, and reviewer expertise.

## Route Definitions

### Route: Security Review
**Trigger Criteria:**
- Changes to authentication, authorization, or session handling
- Modifications to cryptographic code
- Changes to input validation or sanitization
- Updates to dependency versions
- Files matching: `**/auth/**`, `**/security/**`, `**/crypto/**`

**Reviewer Pool:** security-reviewers
**Priority:** High
**SLA:** 4 hours

### Route: Performance Review
**Trigger Criteria:**
- Changes to database queries or ORM usage
- Modifications to caching logic
- Updates to API endpoints with high traffic
- Algorithmic changes in hot paths
- Files matching: `**/db/**`, `**/cache/**`, `**/api/**`

**Reviewer Pool:** performance-reviewers
**Priority:** Medium
**SLA:** 8 hours

### Route: Architecture Review
**Trigger Criteria:**
- New module or package creation
- Changes to core abstractions or interfaces
- Dependency additions
- Significant refactoring (>500 lines changed)
- Files matching: `**/core/**`, `**/shared/**`

**Reviewer Pool:** architecture-reviewers
**Priority:** Medium
**SLA:** 24 hours

### Route: Frontend Review
**Trigger Criteria:**
- Changes to UI components
- Style or CSS modifications
- Frontend state management changes
- Accessibility updates
- Files matching: `**/*.tsx`, `**/*.css`, `**/components/**`

**Reviewer Pool:** frontend-reviewers
**Priority:** Normal
**SLA:** 24 hours

### Route: Standard Review
**Trigger Criteria:**
- Does not match specialized criteria
- General feature development
- Bug fixes
- Documentation updates

**Reviewer Pool:** general-reviewers
**Priority:** Normal
**SLA:** 48 hours

## Routing Process

### Phase 1: Change Analysis

1. Get list of changed files from diff
2. Categorize files by extension and path
3. Calculate change statistics (lines added, removed, files touched)
4. Identify high-risk patterns in the diff

### Phase 2: Signal Collection

For each route, calculate a match score:

Score = (file_pattern_matches * 0.4) + (content_pattern_matches * 0.3) + (change_scope_factor * 0.2) + (historical_context * 0.1)


### Phase 3: Route Selection

1. Rank routes by score
2. If top score > 0.7, select that route
3. If multiple routes score > 0.5, select highest priority route
4. If no route scores > 0.5, use Standard Review

### Phase 4: Assignment

1. Query reviewer pool for availability
2. Select reviewer with relevant expertise and capacity
3. Create review request with context summary
4. Set SLA timer based on route priority

## Multi-Route Handling

Some changes require multiple specialist reviews:

**Condition:** If two or more routes score > 0.6

**Action:**
1. Create primary review request for highest-scoring route
2. Create secondary review requests for other high-scoring routes
3. Mark as "multi-review required"
4. All reviews must approve before merge

## Context Handoff

When routing, include:

Review Context

Route: [Selected Route] Confidence: [Score]% Triggered By: [Specific signals that matched]

Change Summary:

Files: [Count] ([Extensions breakdown])
Lines: +[Added] -[Removed]
Primary areas: [Top 3 directories]

Risk Assessment:

[Risk factors identified]

Suggested Focus:

[Specific areas to review based on route]

Error Handling in Routers

Fallback Strategies

Every router needs fallback handling:

## Fallback Hierarchy

### Level 1: Default Route
When no specific route matches with sufficient confidence, use a default route that can handle general cases.

### Level 2: Human Escalation
When the default route cannot handle the case or expresses uncertainty, escalate to human decision-maker.

### Level 3: Queue for Later
When human escalation is unavailable, queue the request for handling during next available window.

### Never: Silent Failure
Never drop requests silently. Every input must produce either a routing decision or an explicit escalation.

Route Failure Recovery

When a selected route fails:

## Route Failure Handling

### Detection
Monitor route handlers for:
- Timeout (no response within SLA)
- Error responses
- Handler unavailability

### Recovery Actions

**Timeout:**
1. Retry once with extended timeout
2. If still timeout, route to backup handler
3. If no backup, escalate to human

**Error:**
1. Log error details for debugging
2. Route to alternate handler if available
3. If error is input-related, request clarification
4. If system error, escalate to operations

**Unavailable:**
1. Check backup handlers
2. Queue for when handler returns
3. Notify requestor of delay

Testing Router Agents

Coverage Testing

Ensure all routes are reachable:

## Route Coverage Test Suite

For each defined route:
1. Create test case that clearly triggers route
2. Verify routing decision matches expected route
3. Verify context handoff contains required information

For edge cases:
1. Create test case at route boundaries
2. Verify consistent decisions for boundary cases
3. Document expected behavior for ambiguous inputs

Confusion Testing

Test for routing confusion:

## Confusion Test Cases

### Overlapping Criteria
Input that matches multiple routes:
- Expected: Consistent selection based on priority
- Verify: Same input always routes the same way

### Near-Miss Cases
Input that almost matches a route:
- Expected: Fallback to more general route
- Verify: Does not incorrectly match specialized route

### Adversarial Input
Input designed to confuse routing:
- Expected: Safe fallback behavior
- Verify: Does not route to inappropriate handler

Load Testing

Verify router performance under load:

## Load Test Scenarios

### High Volume
- Route 1000 requests in sequence
- Measure routing latency
- Verify no requests dropped

### Concurrent Load
- Route 100 simultaneous requests
- Verify consistent routing decisions
- Check for race conditions in route selection

Best Practices

Keep Routes Orthogonal

Routes should be mutually exclusive where possible:

Good:

Route A: Input type = Image
Route B: Input type = Text
Route C: Input type = Audio

Problematic:

Route A: Input contains numbers
Route B: Input is a question
Route C: Input is short

The second set will frequently conflict since input can match multiple routes.

Document Route Criteria Clearly

Each route should have unambiguous selection criteria:

### Route: Premium Support

**Selection Criteria:**
- Customer has active Premium or Enterprise subscription (required)
- OR customer lifetime value > $10,000 (required)
- AND inquiry is not a simple FAQ question (required)

**Not selected when:**
- Customer is on free tier
- Question is answered in documentation
- Request is spam or abuse

Monitor Route Distribution

Track where requests go:

## Routing Metrics

### Distribution Metrics
- Requests per route over time
- Route utilization percentage
- Overflow frequency

### Quality Metrics
- Reroute rate (wrong initial routing)
- Escalation rate per route
- Time to resolution by route

### Performance Metrics
- Routing decision latency
- End-to-end processing time
- Queue depth by route

Version Your Routes

As routing logic evolves, maintain versions:

## Route Version: 2.3.0

### Changes from 2.2.0
- Added new "Enterprise" route for large accounts
- Updated Security route to include API key changes
- Reduced threshold for Performance route from 0.8 to 0.7

### Migration Notes
- Existing requests in queue will use old routing
- New requests use updated logic immediately

Common Mistakes

Over-Complex Routing

Too many routes make maintenance difficult and increase confusion:

Symptom: More than 10 routes at a single level Solution: Use hierarchical routing to group related routes

Under-Specified Criteria

Vague criteria lead to inconsistent routing:

Symptom: Same input routes differently on different runs Solution: Add specific, measurable criteria to each route

Missing Fallback

No default route causes failures:

Symptom: Some inputs receive no routing decision Solution: Always define a default route for unmatched inputs

Ignoring Context

Routing based only on content misses important signals:

Symptom: Technically correct routing that frustrates users Solution: Incorporate user history, urgency, and sentiment into routing

Summary

Router agents represent a significant step up from fixed-path agents. By allowing the LLM to select execution paths, you create systems that adapt to diverse inputs and contexts.

Key principles:

Define routes clearly with explicit, measurable criteria
Handle uncertainty with confidence levels and fallbacks
Test thoroughly including edge cases and confusion scenarios
Monitor continuously to catch routing drift and issues

The router pattern forms the foundation for more advanced agent architectures. Level 3 agents extend this by allowing the LLM to select and parameterize tools, not just routes. Level 4 agents use routing to coordinate multiple sub-agents. Master routing first, and these advanced patterns will follow naturally.

Ready to give your agents tool-calling capabilities? Continue to Level 3 Agents: Tool Calling Mastery to learn how agents can select and use external tools.

Level 2 Agents: Router Pattern Deep Dive

This guide explores the router pattern in depth. You will understand when to use routing, how to implement effective routers, and common patterns that make routing reliable.

Understanding the Router Pattern

What Makes a Router Agent?

The key characteristics of router agents:

Explicit Options Router agents work with defined paths. The LLM does not invent new routes; it selects from established alternatives. This bounded choice makes routing predictable and debuggable.

Router vs. Level 1 Agents

Consider a document processing system. A Level 1 agent might:

Input → Parse → Extract → Format → Output

Every document follows the same path regardless of type.

A Level 2 router agent:

Input → Classify Document Type
        ├── PDF → Extract with PDF Parser
        ├── Word → Extract with DOCX Parser
        ├── Image → OCR Processing
        └── Unknown → Human Review Queue

The router agent handles diverse inputs appropriately. Each document type gets specialized processing.

The Anatomy of a Routing Decision

Every routing decision has three components:

1. Classification Context Information the LLM uses to make the decision. This includes the input content, metadata, user history, and any relevant state.

2. Route Definitions The available paths the LLM can select. Each route has clear criteria for when it should be chosen and what processing it provides.

3. Selection Logic The reasoning process the LLM uses to match context to routes. This logic should be explicit in your agent design.

Implementing Router Agents

Basic Router Structure

A router agent in Claude Code follows this pattern:

---
description: Routes customer inquiries to appropriate handlers
version: 1.0.0
tools:
  - filesystem
  - shell
---

# Customer Inquiry Router

## Objective

Analyze incoming customer inquiries and route them to the appropriate handling workflow based on inquiry type, urgency, and customer context.

## Available Routes

### Route: Technical Support
**Criteria:**
- Inquiry mentions product issues, bugs, or errors
- Customer describes something not working as expected
- Questions about technical implementation or integration

**Handler:** Technical support workflow

### Route: Billing
**Criteria:**
- Questions about charges, invoices, or payments
- Subscription or plan changes
- Refund requests

**Handler:** Billing support workflow

### Route: Sales
**Criteria:**
- Pricing questions for new customers
- Enterprise or volume inquiries
- Feature comparison questions

**Handler:** Sales team workflow

### Route: General
**Criteria:**
- Does not match specific categories
- General product questions
- Feedback or suggestions

**Handler:** General support workflow

## Routing Process

1. Read the incoming inquiry
2. Identify key signals (keywords, tone, context)
3. Match signals against route criteria
4. Select the best matching route
5. Hand off to appropriate handler with context summary

Multi-Criteria Routing

Simple keyword matching breaks quickly. Effective routers consider multiple criteria:

## Routing Decision Framework

### Primary Signals (Weight: 40%)
Content analysis of the inquiry text:
- Technical terms → Technical Support
- Financial terms → Billing
- Buying signals → Sales

### Secondary Signals (Weight: 30%)
Customer context from their history:
- Active support tickets → Technical Support priority
- Recent purchase → Billing priority
- Trial user → Sales priority

### Urgency Signals (Weight: 20%)
Time sensitivity indicators:
- Words like "urgent," "ASAP," "down" → Expedited handling
- Standard language → Normal queue

### Sentiment Signals (Weight: 10%)
Emotional context:
- Frustrated language → Senior handler
- Neutral/positive → Standard handler

Confidence-Based Routing

Routers should express confidence in their decisions:

## Confidence Levels

### High Confidence (>80%)
- Clear, unambiguous signals
- Single obvious route match
- Action: Route directly

### Medium Confidence (50-80%)
- Mixed signals
- Multiple possible routes
- Action: Route to best match, flag for review

### Low Confidence (<50%)
- Unclear or conflicting signals
- No strong route match
- Action: Route to human triage queue

Router Pattern Variations

Hierarchical Routing

For complex systems, use multi-level routing:

## Level 1: Domain Router
├── Customer Service Domain
│   └── Level 2: Service Type Router
│       ├── Technical
│       ├── Billing
│       └── General
├── Internal Operations Domain
│   └── Level 2: Department Router
│       ├── HR
│       ├── IT
│       └── Facilities
└── Partner Domain
    └── Level 2: Partner Type Router
        ├── Vendor
        ├── Reseller
        └── Integration

Each level refines the routing decision with more specific criteria.

Semantic Routing

Use embeddings for meaning-based routing:

## Semantic Router

### Setup
1. Create embeddings for each route's description
2. Store route embeddings for comparison

### Routing Process
1. Generate embedding for incoming query
2. Calculate similarity to each route embedding
3. Select route with highest similarity above threshold
4. If no route exceeds threshold, use fallback

This approach handles paraphrasing and variant expressions that keyword matching misses.

Dynamic Routing

Routes can change based on current state:

## Dynamic Route Configuration

### Load-Based Routing
- If Technical Support queue > 50: Overflow to General
- If Billing team offline: Route to voicemail callback

### Time-Based Routing
- Business hours: Route to live agents
- After hours: Route to async queue

### Capacity-Based Routing
- Check handler availability before routing
- Distribute load across available handlers

Building a Complete Router Example

Let us build a code review router that directs reviews to appropriate specialists:

---
description: Routes code reviews to appropriate specialist reviewers
version: 1.0.0
tools:
  - filesystem
  - git
---

# Code Review Router

## Objective

Analyze incoming code changes and route to the most appropriate reviewer based on the code characteristics, change scope, and reviewer expertise.

## Route Definitions

### Route: Security Review
**Trigger Criteria:**
- Changes to authentication, authorization, or session handling
- Modifications to cryptographic code
- Changes to input validation or sanitization
- Updates to dependency versions
- Files matching: `**/auth/**`, `**/security/**`, `**/crypto/**`

**Reviewer Pool:** security-reviewers
**Priority:** High
**SLA:** 4 hours

### Route: Performance Review
**Trigger Criteria:**
- Changes to database queries or ORM usage
- Modifications to caching logic
- Updates to API endpoints with high traffic
- Algorithmic changes in hot paths
- Files matching: `**/db/**`, `**/cache/**`, `**/api/**`

**Reviewer Pool:** performance-reviewers
**Priority:** Medium
**SLA:** 8 hours

### Route: Architecture Review
**Trigger Criteria:**
- New module or package creation
- Changes to core abstractions or interfaces
- Dependency additions
- Significant refactoring (>500 lines changed)
- Files matching: `**/core/**`, `**/shared/**`

**Reviewer Pool:** architecture-reviewers
**Priority:** Medium
**SLA:** 24 hours

### Route: Frontend Review
**Trigger Criteria:**
- Changes to UI components
- Style or CSS modifications
- Frontend state management changes
- Accessibility updates
- Files matching: `**/*.tsx`, `**/*.css`, `**/components/**`

**Reviewer Pool:** frontend-reviewers
**Priority:** Normal
**SLA:** 24 hours

### Route: Standard Review
**Trigger Criteria:**
- Does not match specialized criteria
- General feature development
- Bug fixes
- Documentation updates

**Reviewer Pool:** general-reviewers
**Priority:** Normal
**SLA:** 48 hours

## Routing Process

### Phase 1: Change Analysis

1. Get list of changed files from diff
2. Categorize files by extension and path
3. Calculate change statistics (lines added, removed, files touched)
4. Identify high-risk patterns in the diff

### Phase 2: Signal Collection

For each route, calculate a match score:

Score = (file_pattern_matches * 0.4) + (content_pattern_matches * 0.3) + (change_scope_factor * 0.2) + (historical_context * 0.1)


### Phase 3: Route Selection

1. Rank routes by score
2. If top score > 0.7, select that route
3. If multiple routes score > 0.5, select highest priority route
4. If no route scores > 0.5, use Standard Review

### Phase 4: Assignment

1. Query reviewer pool for availability
2. Select reviewer with relevant expertise and capacity
3. Create review request with context summary
4. Set SLA timer based on route priority

## Multi-Route Handling

Some changes require multiple specialist reviews:

**Condition:** If two or more routes score > 0.6

**Action:**
1. Create primary review request for highest-scoring route
2. Create secondary review requests for other high-scoring routes
3. Mark as "multi-review required"
4. All reviews must approve before merge

## Context Handoff

When routing, include:

Review Context

Route: [Selected Route] Confidence: [Score]% Triggered By: [Specific signals that matched]

Change Summary:

Files: [Count] ([Extensions breakdown])
Lines: +[Added] -[Removed]
Primary areas: [Top 3 directories]

Risk Assessment:

[Risk factors identified]

Suggested Focus:

[Specific areas to review based on route]

Error Handling in Routers

Fallback Strategies

Every router needs fallback handling:

## Fallback Hierarchy

### Level 1: Default Route
When no specific route matches with sufficient confidence, use a default route that can handle general cases.

### Level 2: Human Escalation
When the default route cannot handle the case or expresses uncertainty, escalate to human decision-maker.

### Level 3: Queue for Later
When human escalation is unavailable, queue the request for handling during next available window.

### Never: Silent Failure
Never drop requests silently. Every input must produce either a routing decision or an explicit escalation.

Route Failure Recovery

When a selected route fails:

## Route Failure Handling

### Detection
Monitor route handlers for:
- Timeout (no response within SLA)
- Error responses
- Handler unavailability

### Recovery Actions

**Timeout:**
1. Retry once with extended timeout
2. If still timeout, route to backup handler
3. If no backup, escalate to human

**Error:**
1. Log error details for debugging
2. Route to alternate handler if available
3. If error is input-related, request clarification
4. If system error, escalate to operations

**Unavailable:**
1. Check backup handlers
2. Queue for when handler returns
3. Notify requestor of delay

Testing Router Agents

Coverage Testing

Ensure all routes are reachable:

## Route Coverage Test Suite

For each defined route:
1. Create test case that clearly triggers route
2. Verify routing decision matches expected route
3. Verify context handoff contains required information

For edge cases:
1. Create test case at route boundaries
2. Verify consistent decisions for boundary cases
3. Document expected behavior for ambiguous inputs

Confusion Testing

Test for routing confusion:

## Confusion Test Cases

### Overlapping Criteria
Input that matches multiple routes:
- Expected: Consistent selection based on priority
- Verify: Same input always routes the same way

### Near-Miss Cases
Input that almost matches a route:
- Expected: Fallback to more general route
- Verify: Does not incorrectly match specialized route

### Adversarial Input
Input designed to confuse routing:
- Expected: Safe fallback behavior
- Verify: Does not route to inappropriate handler

Load Testing

Verify router performance under load:

## Load Test Scenarios

### High Volume
- Route 1000 requests in sequence
- Measure routing latency
- Verify no requests dropped

### Concurrent Load
- Route 100 simultaneous requests
- Verify consistent routing decisions
- Check for race conditions in route selection

Best Practices

Keep Routes Orthogonal

Routes should be mutually exclusive where possible:

Good:

Route A: Input type = Image
Route B: Input type = Text
Route C: Input type = Audio

Problematic:

Route A: Input contains numbers
Route B: Input is a question
Route C: Input is short

The second set will frequently conflict since input can match multiple routes.

Document Route Criteria Clearly

Each route should have unambiguous selection criteria:

### Route: Premium Support

**Selection Criteria:**
- Customer has active Premium or Enterprise subscription (required)
- OR customer lifetime value > $10,000 (required)
- AND inquiry is not a simple FAQ question (required)

**Not selected when:**
- Customer is on free tier
- Question is answered in documentation
- Request is spam or abuse

Monitor Route Distribution

Track where requests go:

## Routing Metrics

### Distribution Metrics
- Requests per route over time
- Route utilization percentage
- Overflow frequency

### Quality Metrics
- Reroute rate (wrong initial routing)
- Escalation rate per route
- Time to resolution by route

### Performance Metrics
- Routing decision latency
- End-to-end processing time
- Queue depth by route

Version Your Routes

As routing logic evolves, maintain versions:

## Route Version: 2.3.0

### Changes from 2.2.0
- Added new "Enterprise" route for large accounts
- Updated Security route to include API key changes
- Reduced threshold for Performance route from 0.8 to 0.7

### Migration Notes
- Existing requests in queue will use old routing
- New requests use updated logic immediately

Common Mistakes

Over-Complex Routing

Too many routes make maintenance difficult and increase confusion:

Symptom: More than 10 routes at a single level Solution: Use hierarchical routing to group related routes

Under-Specified Criteria

Vague criteria lead to inconsistent routing:

Symptom: Same input routes differently on different runs Solution: Add specific, measurable criteria to each route

Missing Fallback

No default route causes failures:

Symptom: Some inputs receive no routing decision Solution: Always define a default route for unmatched inputs

Ignoring Context

Routing based only on content misses important signals:

Symptom: Technically correct routing that frustrates users Solution: Incorporate user history, urgency, and sentiment into routing

Summary

Router agents represent a significant step up from fixed-path agents. By allowing the LLM to select execution paths, you create systems that adapt to diverse inputs and contexts.

Key principles:

Define routes clearly with explicit, measurable criteria
Handle uncertainty with confidence levels and fallbacks
Test thoroughly including edge cases and confusion scenarios
Monitor continuously to catch routing drift and issues

Ready to give your agents tool-calling capabilities? Continue to Level 3 Agents: Tool Calling Mastery to learn how agents can select and use external tools.