Agent Retry Budgets в 2026: сколько повторов можно позволить до того, как агент начнёт вредить

Короткая версия

Хороший retry-budget design в 2026 обычно включает:

1. Per-step retry limits
2. Per-tool retry semantics
3. Workflow-level budget
4. Escalation or fallback thresholds
5. Budget-aware observability

Что особенно важно

• не every failure is retryable;
• read-only и side-effect steps требуют разных budgets;
• budget полезно считать не только в attempts, но и в time/cost;
• exhausted retry budget должен вести к next state, а не к хаосу.

Почему много retries могут быть хуже, чем ранний fallback?

1. Retry budget полезнее считать как control mechanism

Он помогает ответить:

• когда retry ещё рационален;
• когда нужно сменить strategy;
• когда нужен human review;
• когда workflow лучше terminate;
• сколько recovery cost допустимо для route.

Это делает retries частью orchestration, а не reflex reaction на каждую ошибку.

2. Budget нужно раскладывать по уровням

Step-level

Например:

• query rewrite retry;
• retrieval retry;
• parser retry.

Tool-level

• search API;
• browser action;
• payment write;
• export tool.

Workflow-level

Даже если отдельные шаги ещё retryable, весь run может уже быть слишком дорогим или too old to matter.

3. Retryability зависит от semantics шага

Полезное разделение:

• transient errors with safe replay;
• deterministic errors needing fix, not retry;
• side-effecting writes needing dedupe and idempotency;
• ambiguity after partial commit requiring investigation.

Одинаковый retry count для этих классов почти всегда плохая идея.

4. Budget можно считать не только в попытках

В production полезны и другие измерения:

• total elapsed time;
• token spend;
• external API cost;
• tool-call count;
• operator burden caused by retries.

Иногда второй retry ещё нормален, но третий уже нарушает route SLA или unit economics.

5. Exhausted budget должен вести к явному переходу

Например:

• fallback to cached result;
• switch to manual mode;
• request clarification;
• force approval;
• terminate and log diagnosis.

Retry budget без next-state policy просто обрывает run в произвольной точке.

6. Что особенно часто ломают команды

Same retry count for everything

Никакой semantics awareness.

No workflow-level ceiling

Run расползается по времени и стоимости.

Retries without route SLA awareness

Пользователь уже давно не получит value.

No budget observability

Команда не видит, где retries реально съедают систему.

Side-effect retries without idempotency context

Recoverability illusion превращается в risk multiplier.

7. Какие метрики полезны

Минимальный retry-budget dashboard обычно включает:

• retry attempts by tool and route;
• exhausted-budget rate;
• fallback-after-retry rate;
• cost of retries per successful outcome;
• duplicate-side-effect incidents;
• p95 recovery time by workflow class.

Пример retry budget record

{
  "route": "browser_checkout_agent",
  "step_retry_limit": 2,
  "tool_retry_limits": {
    "search": 3,
    "browser_submit": 0,
    "browser_read": 2
  },
  "workflow_budget": {
    "max_retries_total": 5,
    "max_elapsed_seconds": 90
  },
  "on_exhaustion": "manual_escalation"
}

Практический checklist

1. Separate retry budgets by step and tool semantics
2. Add workflow-level ceilings for time and cost
3. Distinguish retryable from non-retryable failures explicitly
4. Define clear fallback or escalation after budget exhaustion
5. Track retry spend and recovery quality, not just attempt count

Практический совет: зрелый агент не тот, который retry-ит дольше всех, а тот, который раньше понимает, когда recovery перестала быть экономически и operationally разумной.