Traditional automation either works or it doesn’t. A Zapier zap moves data from A to B — if the API call fails, it retries. The output is the same every time.
AI workflows are different. A model might timeout under load. A rate limit might throttle your requests. The output might be valid but miss the mark. And because AI workflows often have multiple steps, a failure in step 3 shouldn’t lose the successful results from steps 1 and 2.
Designing for these realities is the difference between workflows your team trusts and workflows they abandon after the first bad experience.
Automatic retries with backoff
JieGou automatically retries failed recipe steps with exponential backoff. When a step fails due to a transient error — rate limits (429), server errors (502, 503), or timeouts — the system waits and retries, backing off exponentially (2s, 4s, 8s, up to 30s) with random jitter to avoid thundering herd problems.
You configure the maximum retry count per step. For most recipes, 2-3 retries handles transient errors without significantly delaying the workflow. For high-volume workflows where rate limits are common, you might set higher retry counts.
Permanent errors — invalid input, authentication failures, model refusals — skip retries entirely. There’s no point retrying a request that will fail the same way every time.
Error classification matters
Not all failures are equal. JieGou classifies errors into categories so the workflow can respond appropriately:
- Transient errors (retryable): Rate limits, server overloads, network timeouts. These resolve on their own with retries.
- Permanent errors (not retryable): Bad input, authentication failures, content policy violations. These require human intervention or input changes.
- Partial success: The AI returned output, but it doesn’t fully match the expected schema. The workflow can continue with what it has or flag the issue for review.
This classification is automatic. You don’t need to write error handling logic — the executor knows which HTTP status codes are transient and which are permanent.
Approval gates as safety nets
Approval steps aren’t just for business process sign-off. They’re also reliability checkpoints.
Place an approval gate after any step where output quality matters for downstream steps. For example:
- Research prospect (recipe step)
- Review research quality (approval gate)
- Draft outreach based on research (recipe step)
If the research step returns thin results — maybe the company is small and there’s limited public information — the approval gate lets a human decide whether to proceed with what’s available or provide additional context before the outreach draft.
Without the gate, the outreach step would generate an email based on incomplete research, producing a generic message that defeats the purpose of the automation.
Condition steps for output validation
Use condition steps to check output quality before proceeding:
- Extract invoice data (recipe step)
- Condition: If total_amount exists and line_items is not empty (condition step)
- Then: Continue to discrepancy check
- Else: Flag for manual processing
This catches cases where the AI failed to extract key fields — maybe the invoice format was unusual or the text was poorly scanned. Instead of passing incomplete data to the next step, the workflow routes it to a human.
Webhook notifications on failure
Workflows can send webhook notifications when they complete — whether successfully or with errors. Configure an output webhook to notify your team when a workflow fails:
- Post to a Slack channel when a scheduled workflow encounters an error
- Send to PagerDuty for critical workflows that need immediate attention
- Update a status dashboard with workflow health
The webhook payload includes the run ID, status, which step failed, and the error details. Your team gets actionable information, not just “something broke.”
Parallel execution and partial failures
Parallel steps run multiple branches concurrently. If one branch fails, the other branches continue. This is by design — a failure in one independent branch shouldn’t block unrelated work.
After parallel execution completes, you can check which branches succeeded and which failed. A condition step after the parallel block can route the workflow based on whether all branches completed or some failed.
Designing for the 95th percentile
Most AI calls succeed on the first try. Most outputs match the expected schema. Most workflows run without issues. But “most” isn’t enough when you’re running workflows daily for a team that depends on the results.
Design your workflows for the 5% case:
- Add retries to every recipe step. The cost of a few extra API calls on failure is negligible compared to the cost of a failed workflow run.
- Add approval gates before high-stakes outputs. If the workflow is generating content that goes to customers or executives, a human should verify it.
- Add condition checks after extraction steps. Verify that the AI actually extracted the data you need before passing it forward.
- Configure webhook notifications for scheduled and triggered workflows. If nobody’s watching the UI, you need alerts when things go wrong.
The goal is workflows that degrade gracefully — surfacing problems to humans instead of silently producing bad output.