FallbackAgent Component
Provides automatic failover across multiple AI providers with retry logic and graceful degradation. Tries agent children in priority order, falling back to next provider on error or timeout. Essential for production resilience and cost optimization.Planned API
Proposed Usage
Basic Multi-Provider Failover
With Retry Configuration
Cost Optimization Pattern
Cross-Provider Redundancy
Props (Planned)
Agent components in priority order.Requirements:Order matters: First child = highest priority, last = fallback of last resort
- Children must be agent components (Claude, Codex, Gemini, Smithers)
- Executed sequentially, not in parallel
- All agents receive same prompt/props from parent context
Retries per agent before failover to next.Total attempts per agent:
maxRetries + 1Examples:maxRetries={0}→ Try once, immediate failover on errormaxRetries={2}→ Try up to 3 times before failovermaxRetries={5}→ Aggressive retry before giving up
Callback when falling back from one agent to next.Parameters:
from- Agent that failed (e.g., “Claude Opus”)to- Agent being tried next (e.g., “Codex GPT-4”)error- Error that triggered fallback
- Logging/observability
- Metrics collection
- Cost tracking
- Alerting on repeated failures
Callback when all agents fail.Receives array of errors (one per agent attempt).Called before: FallbackAgent throws aggregate error.
Strategy for calculating retry delays.Exponential: Delay doubles each retry
- Retry 1:
retryDelayMs - Retry 2:
retryDelayMs * 2 - Retry 3:
retryDelayMs * 4 - Good for rate limits and transient errors
- All retries:
retryDelayMs - Simpler, more predictable
- Immediate retry
- Use for fast failure scenarios
Initial retry delay in milliseconds.Exponential strategy: Base delay that doubles each retryLinear strategy: Fixed delay for all retriesExamples:
retryDelayMs={500}→ Quick retries (0.5s, 1s, 2s…)retryDelayMs={5000}→ Conservative (5s, 10s, 20s…)retryDelayMs={0}→ No delay (with strategy=‘none’)
Implementation Status
1
Design Phase
Component designed for github-actions-review-loop use case.
View on GitHub
2
Core Implementation (Pending)
Child iteration logic, error handling, retry with backoff.
3
Agent Detection (Pending)
Identify agent type from child component for logging/metrics.
4
Testing (Future)
Unit tests with mocked agents for success/failure/timeout scenarios.
Design Rationale
Sequential vs Parallel Execution
FallbackAgent: Sequential (one at a time)Error Aggregation
When all agents fail, FallbackAgent throws aggregate error:Retry Backoff Calculation
Agent Type Extraction
Examples of Use Cases
Use Case 1: Production Review System
Use Case 2: Cost-Optimized Pipeline
Use Case 3: Geographic Failover
Use Case 4: A/B Testing with Fallback
Related
GitHub Actions Review Loop
Primary use case - review system with multi-provider fallback
Claude Component
Primary agent - works as FallbackAgent child
Codex Component
OpenAI Codex agent - planned fallback option
Gemini Component
Google Gemini agent - planned fallback option
Alternatives Considered
- Manual try/catch chains: Verbose, no retry logic, hard to maintain
- Higher-order component wrapping: Less clear intent, more complex API
- External orchestration: Loses Smithers observability and task tracking
- Parallel execution with race: Wasteful, doesn’t optimize for cost