Self-Healing / Retry Loop

// 60-second mental model

How to hold it in your head

Something failed. Do not spam the same call. Diagnose the failure class, pick a fix, retry with a budget — then escalate or stop.

Self-healing / retry loops classify errors (transient, schema, tool, policy), apply a bounded remediation (backoff, fix args, alternate tool), and hard-stop when the budget is spent. Diagnosis before retry — not blind re-prompting.

// Mini architecture

Fail → diagnose → remediate → retry (budgeted)

┌──────────────┐
│ Action       │
└──────┬───────┘
       │ error?
       ▼
┌──────────────┐
│ Diagnose     │ → class: transient|schema|tool|policy
└──────┬───────┘
       ▼
┌──────────────┐
│ Remediate    │ → backoff / fix args / alt tool
└──────┬───────┘
       │ retries left?
       ├─ yes → Action again
       └─ no  → Escalate / safe failure

Same error twice with no new diagnosis is a bug in the loop — not persistence.

// Mini-project

Flaky tool with classified retries (stub)

Action runner + diagnose stub + retry budget

Goal: Call a stub tool that fails twice (timeout, then bad args); heal with backoff then arg-fix; succeed on third try or escalate.

1. Stub `fetch_invoice` fails: attempt 1 = timeout, attempt 2 = schema error, attempt 3 = success.
2. Diagnose maps error codes → class + remediation.
3. Transient → exponential backoff (simulated sleep). Schema → fix args once.
4. Policy errors never retry — escalate immediately.
5. Hard maxRetries=3; log class → remediation → outcome.
6. Refuse a blind “call again with the same args” path after a schema error.

Simulated failures are enough. The lesson is diagnose-then-retry with a budget — a pattern to wire into your runners, not a claim about fleet-wide auto-healing.

// Common failure

What goes wrong

// Self-reflection

Sit with this

Which of your agents still retries by hope instead of by diagnosis?