workflow-optimizer

name: workflow-optimizer
description: Analyzes Cloudflare Workflow performance and suggests optimizations for cost, speed, and reliability. Use when workflow runs slowly, costs too much, or needs reliability improvements.
tools:
  - Read
  - Grep
  - Glob
  - Bash

Workflow Optimizer Agent

Autonomous agent that analyzes workflow performance and provides actionable optimization recommendations for cost reduction, speed improvements, and enhanced reliability.

Trigger Conditions

This agent should be used when:

• User asks to "optimize workflow" or "improve performance"
• User mentions high workflow costs
• User reports slow workflow execution
• User wants to improve reliability
• After successful workflow deployment for optimization review

**Keywords**: optimize, performance, slow, cost, expensive, improve, faster, reliability, retry, timeout, efficiency

Analysis Process

Phase 1: Workflow Discovery

Step 1.1: Find Workflow Files

# Find all workflow implementations
find src -name "*.ts" -type f | xargs grep -l "extends WorkflowEntrypoint"

Step 1.2: Count Workflows

# Count workflows in configuration
grep -v '^\s*//' wrangler.jsonc | jq '.workflows | length'

Step 1.3: Select Workflow to Analyze

If multiple workflows found, analyze each or let user select.

---

Phase 2: Performance Analysis

Step 2.1: Count Steps

# Count step.do() calls
grep -c "step\.do" src/workflows/*.ts

# Count sleep calls
grep -c "step\.sleep\|step\.sleepUntil" src/workflows/*.ts

# Count waitForEvent calls
grep -c "step\.waitForEvent" src/workflows/*.ts

**Metrics**:

• Total steps
• Sleep steps (free)
• Active steps (billed)

Step 2.2: Analyze Step Complexity

For each step.do() call, analyze:

# Find steps with multiple await statements (potential optimization)
grep -A 20 "step\.do" src/workflows/*.ts | grep -c "await"

**Flag**:

• Steps with >3 await calls → May be doing too much
• Steps with fetch loops → Consider batching

Step 2.3: Detect Long-Running Steps

# Find loops inside steps
grep -B 5 -A 10 "step\.do" src/workflows/*.ts | grep "for\|while"

**Warning**: Loops inside step.do() may exceed 30s CPU limit.

Step 2.4: Analyze Retry Configuration

# Check for retry configuration
grep -n "retries:" src/workflows/*.ts

**Flag**:

• No retry config → Using defaults (may be suboptimal)
• High retry limits → May cause excessive retries
• No backoff → May overwhelm external services

---

Phase 3: Cost Analysis

Step 3.1: Calculate Request Cost

Workflow cost factors:

• **Requests**: $0.15 per million (workflow creation + each step)
• **Duration**: $0.02 per million GB-s

**Formula**:

Cost per workflow = (1 + steps) × $0.00000015 + duration_gb_s × $0.00000002

Step 3.2: Estimate Per-Workflow Cost

Example (5 steps, 10ms each):
- Requests: 6 × $0.00000015 = $0.0000009
- Duration: 0.05s × 0.128GB × $0.00000002 = ~$0
- Total: ~$0.0000009 per workflow

At 1M workflows/month: ~$0.90

Step 3.3: Identify Cost Hotspots

**High cost indicators**:

• Many steps per workflow (>10)
• Long-running steps (>1s each)
• Excessive retries
• Multiple workflows where one would suffice

---

Phase 4: Reliability Analysis

Step 4.1: Check Error Handling

# Find try-catch blocks
grep -c "try.*{" src/workflows/*.ts

# Find NonRetryableError usage
grep -c "NonRetryableError" src/workflows/*.ts

**Flags**:

• No try-catch → Unhandled errors cause unexpected behavior
• No NonRetryableError → Permanent failures retry forever

Step 4.2: Check Timeout Configuration

# Check for timeout in waitForEvent
grep "waitForEvent" src/workflows/*.ts | grep -c "timeout"

**Warning**: waitForEvent without timeout can hang indefinitely.

Step 4.3: Check Idempotency

# Look for idempotency patterns
grep -c "idempotency\|idempotent\|Idempotency-Key" src/workflows/*.ts

**Recommendation**: External API calls should use idempotency keys.

Step 4.4: Check Circuit Breaker

# Look for circuit breaker patterns
grep -c "CircuitBreaker\|circuit" src/workflows/*.ts

**Recommendation**: Flaky external APIs should use circuit breaker.

---

Phase 5: Optimization Recommendations

Based on analysis, provide specific recommendations:

Performance Optimizations

**Opt 1: Batch API Calls**

// Before: Multiple steps
const user = await step.do('get user', () => fetch('/users/1'));
const orders = await step.do('get orders', () => fetch('/orders?user=1'));

// After: Single step with parallel fetches
const data = await step.do('get user data', async () => {
  const [user, orders] = await Promise.all([
    fetch('/users/1'),
    fetch('/orders?user=1')
  ]);
  return { user: await user.json(), orders: await orders.json() };
});

**Impact**: 50% fewer requests, 50% cost reduction

**Opt 2: Use step.sleep() Instead of Polling**

// Before: Polling loop (expensive)
for (let i = 0; i < 10; i++) {
  const status = await step.do(`poll ${i}`, () => checkStatus());
  if (status.done) break;
}

// After: Use sleep (free)
await step.sleep('wait for processing', '5 minutes');
const status = await step.do('check status', () => checkStatus());

**Impact**: 90% fewer requests during wait periods

**Opt 3: Break Large Steps into Batches**

// Before: Single large step (may timeout)
await step.do('process all', async () => {
  for (const item of items) await process(item);
});

// After: Batched steps (reliable)
const batchSize = 100;
for (let i = 0; i < items.length; i += batchSize) {
  await step.do(`batch ${Math.floor(i/batchSize)}`, async () => {
    return await Promise.all(
      items.slice(i, i + batchSize).map(process)
    );
  });
}

**Impact**: Prevents timeout, enables progress tracking

---

Cost Optimizations

**Cost 1: Consolidate Related Steps**

// Before: Separate