Retries and recovery

Retry important external calls

Wrap flaky or important network actions with retry. Use a fallback for the human-readable recovery path.

bot SupportEscalation {
  capabilities {
    zendesk.createTicket
    slack.send
  }

  on user.message {
    ticket = retry call zendesk.createTicket with {
      title: "Customer needs help",
      description: input
    }
      with backoff exponential
      max attempts 3
      fallback {
        call slack.send with {
          channel: "#support",
          message: f"Ticket creation failed. Please handle manually: {input}"
        }
      }

    say f"Support ticket created: {ticket.id}"
  }
}

What should be retried?

• Searches, reads, and status checks.
• Idempotent writes where the external action can safely deduplicate.
• Notifications that can be repeated without harm.

Be careful retrying payments, posts, calendar creation, or destructive actions. Those need idempotency and approval boundaries.

Good fallback messages

A fallback should tell the user what failed, what was not completed, and what to do next.

fallback {
  say "I could not reach Gmail, so I did not send anything. Reconnect Gmail, then retry this run from Observability."
}