Kestrel does not use a generic recovery policy. Each failure stays with the component that owns it:
- The model gateway retries transient model-call failures.
- Tool gateways own tool-specific retries.
- The execution engine owns deterministic loop intervention and ordinary clarification.
- Runtime evaluation owns structured review.
- Other failures terminate with their original safe error code.
Model calls
The selected Environment model receives at most three total attempts, before visible output starts and within the run budget. Kestrel does not switch providers or models automatically. Authentication, authorization, schema, validation, cancellation, malformed-response, HTTP 409, and HTTP 425 failures are terminal.
Questions and approvals
When the runtime genuinely needs user information, it emits an ordinary question and accepts text. External effects continue to use the existing approval contract and server-derived authority.
Evaluation review
Evaluation is the only producer of structured reviews. Every review persists its complete canonical interaction envelope and allows only evaluation.accept_once, evaluation.revise, and terminal.fail. Clients display shared labels but submit the exact option identifier. Free text cannot resolve an evaluation review.
Terminal failure and retry
A terminal failure produces no interaction request. Clients show the original safe code and message. “Try turn again” or /retry starts a new execution attempt from the failed turn; it does not resume the failed run.
Legacy recovery waits
Persisted recovery_review waits remain readable but cannot accept text or option identifiers. Clients show “This request can no longer be resumed safely” and provide the existing explicit cancellation action. Kestrel never guesses an answer or cancels these waits automatically.
Persistence and replay
Persist evaluation decisions and resulting state transitions. Duplicate decisions resolve once. Replay may reconstruct the evaluation path without repeating external effects.
Consumer rules
Render ordinary questions as text input, approvals through approval controls, evaluation reviews through exact options, and terminal errors without a fake waiting state.