Workflow Orchestrator Strategist

Your agent for designing and implementing complex workflow automation — covering task orchestration, state management, error handling, and integration between systems.

When to Use This Agent

Choose Workflow Orchestrator Strategist when:

• Designing automated workflows that coordinate multiple systems
• Implementing long-running business processes with state management
• Building ETL pipelines, data processing workflows, or approval chains
• Orchestrating microservice interactions for complex business operations
• Implementing saga patterns, compensation logic, or retry strategies

Consider alternatives when:

• You need CI/CD pipelines — use a GitOps or DevOps agent
• You need event-driven architecture — use a cloud architect agent
• You need simple automation scripts — use a general developer agent

Quick Start

Copy
# .claude/agents/workflow-orchestrator.yml
name: Workflow Orchestrator Strategist
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: Workflow automation architect for orchestration design, state management, and multi-system coordination

Example invocation:

claude "Design a workflow for processing customer orders — payment validation, inventory reservation, fulfillment assignment, shipping notification, and handling partial failures with compensating transactions"

Core Concepts

Workflow Patterns

Pattern	Use Case	Example
Sequential	Ordered steps	Payment → Inventory → Ship
Parallel	Independent steps	Email + SMS + Push simultaneously
Conditional	Branch on conditions	If amount > $100: require approval
Saga	Distributed transactions	Order saga with compensation
Human-in-loop	Approval gates	Manager approval for large orders
Scheduled	Time-based triggers	Daily report generation

Saga Pattern for Distributed Workflows

Order Saga:
  Step 1: Reserve inventory
    └── Compensate: Release inventory
  Step 2: Charge payment
    └── Compensate: Refund payment
  Step 3: Create shipment
    └── Compensate: Cancel shipment
  Step 4: Send confirmation
    └── Compensate: Send cancellation

If Step 3 fails:
  → Cancel shipment (compensate 3)
  → Refund payment (compensate 2)
  → Release inventory (compensate 1)

Configuration

Parameter	Description	Default
orchestrator	Workflow engine (temporal, step-functions, airflow, custom)	temporal
error_strategy	Error handling (retry, compensate, dead-letter)	retry-then-compensate
state_persistence	State storage (database, workflow-engine, event-log)	workflow-engine
timeout_default	Default step timeout	30s
max_retries	Maximum retry attempts per step	3

Best Practices

1. Make every workflow step idempotent. Steps may execute multiple times due to retries, restarts, or redelivery. Design each step so that running it twice with the same input produces the same result. Use idempotency keys for external API calls.

2. Define compensation logic for every step that has side effects. If a step charges a credit card, define how to refund. If a step sends an email, define what to do if the workflow fails after the email is sent. Not every step needs compensation, but every step with external side effects should consider it.

3. Use a dedicated workflow engine for complex orchestration. Custom code with database-backed state machines works for simple workflows but breaks down as complexity grows. Temporal, AWS Step Functions, and Apache Airflow provide built-in retry, timeout, state persistence, and visibility.

4. Implement circuit breakers for external service calls. When a downstream service is down, retrying every workflow instance compounds the problem. Circuit breakers detect failures and fail fast, allowing the system to recover gracefully instead of overwhelming the failing service.

5. Log workflow state transitions for observability. Every state change (step started, completed, failed, retried) should be logged with correlation IDs. This enables debugging ("why did order #12345 get stuck?") and monitoring ("how many orders failed at the payment step today?").

Common Issues

Workflow gets stuck in an intermediate state after a crash. Without durable state persistence, a server crash between steps loses progress. Use a workflow engine that persists state after each step, so recovery resumes from the last completed step instead of starting over.

Compensation logic is incomplete or incorrect. Compensating transactions that only partially undo a step leave the system in an inconsistent state. Test compensation paths as thoroughly as the happy path. Simulate failures at every step and verify the system returns to a consistent state.

Long-running workflows timeout or consume excessive resources. A workflow that waits for human approval shouldn't hold a thread or connection while waiting. Use async waiting patterns (Temporal's workflow.sleep, Step Functions' wait states) that release resources during idle periods.