Failure Recovery, Retry and Replanning

A failure nem egyetlen kategória

Egy agentic loop sokféleképpen hibázhat:

model error
tool timeout
rate limit
invalid arguments
not authorized
stale observation
failed precondition
side-effect uncertainty
bad plan
wrong hypothesis
external dependency outage

Ha mindegyikre ugyanaz a válasz:

retry

akkor gyorsan retry storm vagy duplicate side effect lesz.

A helyes mental model:

Először classify the failure, utána válassz recovery strategyt.

Failure taxonomy

Transient infrastructure failure

Például:

timeout
503
connection reset
rate limit

Gyakran retry-zható kontrolláltan.

Permanent / semantic failure

resource does not exist
invalid business state
unsupported operation

Azonos action újrahívása valószínűleg nem segít.

Authorization failure

NOT_AUTHORIZED
FORBIDDEN

Ez általában terminal vagy human escalation.

Ne próbáljon az agent „másik utat keresni” ugyanahhoz a tiltott adathoz.

Validation failure

invalid tool arguments
schema mismatch
precondition false

Lehet javítható új argumentummal vagy új observationnel.

Stale-state failure

PR was merged after agent inspected it
resource version changed
approval expired

Itt a helyes recovery gyakran:

re-observe
 ↓
re-evaluate

nem sima retry.

Semantic reasoning failure

A modell rossz következtetésből rossz actiont választott.

Például:

assumed deployment caused incident
but evidence disproves it

→ replan.

Side-effect uncertainty

Különösen veszélyes:

send_payment_refund
 ↓
timeout before response

Nem tudjuk, hogy a refund megtörtént-e.

Vak retry duplicate refundot okozhat.

Retry decision matrix

Praktikus mental model:

Failure	Same-action retry?	Typical next step
transient timeout, read-only	often yes	backoff + retry
rate limit	yes, later	respect retry-after
invalid argument	usually no	repair arguments
not authorized	no	stop/escalate
stale state	no direct retry	refresh observation
precondition failed	no	replan or stop
unknown write outcome	dangerous	reconcile/idempotency check
semantic wrong path	no	replan

Retry policy

A retry legyen explicit runtime policy.

Például:

{
  "max_attempts": 3,
  "backoff": "exponential",
  "retry_on": ["TIMEOUT", "TRANSIENT_FAILURE", "RATE_LIMITED"]
}

Ne promptban legyen:

"Try a few times if it fails."

Exponential backoff és jitter

Több run egyszerre hibázik egy dependency miatt.

Ha mind retryol:

1s
2s
4s

ugyanabban az időpontban, újabb load spike jöhet.

Jitter:

base delay + random variation

csökkenti a synchronized retry stormot.

Ez klasszikus distributed systems probléma; agentic rendszernél sem változik.

Idempotency write actionnél

Példa:

create_issue
send_email
refund_payment
create_order

Retry előtt tudnunk kell:

Ismételhető-e biztonságosan ugyanaz az action?

Például:

refund_payment(
  payment_id="p-42",
  amount=100,
  idempotency_key="run-1842-refund-1"
)

Ha az első call sikerült, de response elveszett, a második ugyanazzal a key-jel nem hoz létre új refundot.

Az idempotency tipikusan tool/application boundary felelősség, nem modell-prompt feladat.

Reconciliation unknown outcome esetén

Ha egy side effect resultja bizonytalan:

write request sent
 ↓
connection lost

helyesebb lehet:

query current external state
      ↓
did operation happen?
  ├── yes → record success
  └── no  → retry if safe

Példa GitHub issue:

create_issue timeout
 ↓
search issue by idempotency marker/title
 ↓
existing? → success
missing? → retry

Retry vs repair

Tool validation error:

{
  "error": "INVALID_ARGUMENT",
  "field": "environment",
  "allowed": ["dev", "staging", "production"]
}

Ugyanazzal az argumentummal retry értelmetlen.

Jobb:

repair action arguments
 ↓
validate
 ↓
execute

Retry vs re-observe

Példa:

merge_pull_request
 ↓
PRECONDITION_FAILED: branch is behind

Nem biztos, hogy sima retry kell.

refresh PR state
 ↓
inspect new commits/checks
 ↓
choose next action

Az environment változott; új decision kell.

Retry vs replan

Példa incident diagnosis:

query deployment logs
 ↓
no relevant deployment exists

Ez nem tool failure. A hypothesis failure.

current plan invalidated
 ↓
replan diagnostic path

Repeated failure detection

A runtime tárolhat failure fingerprintet:

action type
normalized arguments
error category
relevant state version

Például:

read_file(path="foo") → NOT_FOUND

ha négyszer ismétlődik ugyanazzal a state-tel, a loop nem recoverál, csak thrash-el.

Trigger:

same failure >= threshold
      ↓
stop retry
      ↓
replan / fallback / escalate

Strategy switching

Például:

Primary: query observability API
 ↓ unavailable
Fallback: read cached telemetry snapshot

vagy:

Model A structured output repeatedly invalid
 ↓
Fallback model / deterministic parser path

De fallback csak akkor jó, ha a semantics elfogadható.

Ne legyen:

critical production truth unavailable
 ↓
use old cached data silently

A degraded result legyen explicit.

Graceful degradation

Például:

{
  "status": "PARTIAL_RESULT",
  "summary": "Application logs were analyzed, but deployment telemetry was unavailable.",
  "missing_evidence": ["deployment metrics"],
  "confidence": "LOW"
}

Ez jobb, mint:

agent invents missing evidence

Terminal failure

Vannak helyzetek, ahol továbbmenni rosszabb.

Például:

• authorization denied,
• required approval rejected,
• safety policy violation,
• irreversible action precondition unknown,
• corrupted canonical state,
• budget exhausted,
• repeated unrecoverable failures.

Terminal state legyen explicit és informatív:

{
  "status": "BLOCKED",
  "reason": "PRODUCTION_ACCESS_REQUIRED",
  "completed_steps": ["local diagnosis"],
  "next_possible_action": "request authorized operator"
}

Partial side effects és compensation

Összetett flow:

create cloud resource ✅
configure DNS ✅
write database record ❌

Mit csináljon a recovery?

Nem mindig rollback.

Lehet:

• retry final step,
• compensate created resources,
• mark partial state and ask operator,
• run reconciliation workflow.

Ez saga/compensation jellegű software architecture probléma.

Az agent nem „varázslatos transaction manager”.

Replanning trigger-ek

Replan akkor indokolt, ha:

• core assumption megdőlt,
• planned capability unavailable,
• new high-value evidence érkezett,
• user módosította a célt,
• repeated failure mutatja, hogy a stratégia nem működik,
• environment materially changed.

Replanning eredménye legyen state update:

plan v3
 ↓ invalidated by observation X
plan v4

Így auditálható, miért változott az execution path.

Coding agent példa

Goal:

Fix flaky test.

Run:

1. run test → FAIL
2. inspect fixture
3. patch timing
4. run test → FAIL same signature
5. retry same test → FAIL same signature

A helyes runtime nem futtatja húszszor ugyanazt.

repeated failure detected
 ↓
current hypothesis rejected
 ↓
replan
 ↓
inspect shared state / parallel execution

Ez recovery, nem puszta retry.

Recovery action contract

Lehet explicit:

{
  "failure_class": "STALE_STATE",
  "recommended_recovery": "REOBSERVE",
  "retry_same_action": false
}

A classifier lehet részben deterministic, részben model-assisted, de policy döntse el, mi engedélyezett.

Anti-pattern: generic retry wrapper mindenre

for i in range(5):
    try:
        execute_agent_step()
    except Exception:
        continue

Ez összemossa:

• model failure,
• tool failure,
• business failure,
• authorization failure,
• side-effect uncertainty.

Recovery policy legyen failure-aware.

Anti-pattern: retry új idempotency key-jel

attempt 1: refund key A → timeout
attempt 2: refund key B → duplicate possible

Retry ugyanahhoz a logical operationhöz ugyanazt az idempotency identityt használja.

Anti-pattern: alternate route authorization bypassra

GitHub API says forbidden
 ↓
agent tries shell/git credential instead

Authorization failure nem puzzle.

A runtime capability scope-nak ezt eleve meg kell akadályoznia.

Takeaways

• Failure előtt classification kell; nem minden hiba retry-zható.
• Transient failure gyakran retry; stale state inkább re-observe; wrong hypothesis inkább replan.
• Authorization/safety failure tipikusan stop vagy escalation.
• Retry policy deterministic runtime concern legyen.
• Write actionnél idempotency és unknown-outcome reconciliation kritikus.
• Repeated failure fingerprint alapján állítsuk meg a thrashinget.
• Fallback/degraded mode legyen explicit, ne rejtse el a hiányzó evidence-t.
• Partial side effecteknél compensation/reconciliation normál distributed-systems probléma.
• Replanning legyen observation-driven és versioned/auditálható.
• A jó agentic runtime nem attól reliable, hogy „kitartó”, hanem attól, hogy helyesen különbözteti meg a retry, repair, re-observe, replan, fallback és stop eseteket.