Reliability, Failure Handling and Deterministic Boundaries¶

A skill nem attól reliable, hogy „jó a prompt”¶

Egy production skill körül több failure mode van:

invalid input
model error
bad semantic decision
tool timeout
authorization failure
rate limit
partial external failure
duplicate side effect
infinite loop
cost/latency budget exhaustion

A reliability célja nem az, hogy ezek soha ne történjenek meg.

A cél:

A hibák legyenek felismerhetők, korlátozottak, explicit outcome-mal rendelkezzenek, és ahol lehet, determinisztikus software boundary kezelje őket.

Reliability layers¶

Hasznos mental model:

Input validation
      ↓
Skill execution
      ↓
Tool/runtime guards
      ↓
Output validation
      ↓
Business validation
      ↓
Side-effect execution
      ↓
Postcondition / audit

Egyetlen layer sem old meg mindent.

Explicit success és failure semantics¶

Reusable skillnél legyen definiálva, milyen outcome-ok léteznek.

Például:

SUCCESS
PARTIAL_RESULT
INVALID_INPUT
INSUFFICIENT_CONTEXT
NOT_AUTHORIZED
TOOL_UNAVAILABLE
TIMEOUT
BUDGET_EXCEEDED
FAILED

Ez jobb, mint:

try:
    run_skill()
except Exception:
    return "Something went wrong"

A caller így tud policyt alkalmazni.

INSUFFICIENT_CONTEXT → ask for input
TOOL_UNAVAILABLE → retry/fallback
NOT_AUTHORIZED → stop
PARTIAL_RESULT → continue with warning

Recoverable vs terminal failure¶

Nem minden hiba retry-zandó.

Tipikusan recoverable lehet¶

network timeout
429 rate limit
transient 503
short-lived tool outage

Tipikusan terminal az adott requestben¶

invalid input
not authorized
resource permanently not found
business rule violation
unsafe requested action

Gyenge pattern:

retry everything 3 times

Ez csak:

lassít,
növeli a costot,
felesleges loadot generál,
write operationnél veszélyes lehet.

Retry policy legyen explicit¶

Például:

TOOL_TIMEOUT:
  max_attempts: 3
  backoff: exponential

RATE_LIMITED:
  respect_retry_after: true

NOT_AUTHORIZED:
  max_attempts: 0

INVALID_INPUT:
  max_attempts: 0

A retry policy tipikusan runtime/application concern, nem prompt text.

Model retry külön kérdés¶

Ha a modell invalid structured outputot ad, schema-constrained platformon ezt részben a platform kezelheti.

Semantic failure esetén:

model gives unsupported conclusion

nem biztos, hogy ugyanazt a promptot újra elküldeni jó stratégia.

Lehetséges repair:

original result
 ↓
deterministic validation fails
 ↓
repair prompt with exact validation error
 ↓
new result

De itt is legyen max attempt és budget.

Precondition és postcondition¶

Klasszikus design-by-contract szemlélet jól működik.

Precondition¶

Mielőtt a skill fut:

input schema valid
required context available
required capability present
permission scope valid

Postcondition¶

Skill után:

output schema valid
required evidence present
forbidden action not requested
business invariants preserved

Példa:

Refund Recommendation Skill

postcondition:

amount >= 0
currency supported
recommendation in allowed enum

A tényleges refund végrehajtása előtt további business validation kell.

Deterministic boundary: model recommendation vs business decision¶

Például a model output:

{
  "recommendation": "APPROVE",
  "amount": 500
}

A business policy:

amount > 100 EUR → manager approval required

A helyes flow:

model recommendation
      ↓
policy engine
      ↓
manager approval required

nem:

model said APPROVE → refund

A model semantic judgementet adhat; a hard invariantet kód enforce-olja.

Timeout minden external boundaryn¶

Egy agentic skill több helyen blokkolhat:

model call
tool call
retrieval
database
external API
human approval

Mindennek legyen timeout vagy explicit waiting state.

Például:

model timeout: 60s
tool timeout: 10s
overall skill timeout: 90s

A konkrét szám domainfüggő, de az elv:

Ne legyen implicit végtelen várakozás.

Execution budget¶

Többlépéses skill/agent executionnél több budget is kellhet:

max model calls
max tool calls
max iterations
max tokens
max wall-clock time
max cost

Például:

max_steps = 12
max_tool_calls = 20
max_runtime = 2 minutes

Ha elfogy:

BUDGET_EXCEEDED

legyen explicit outcome.

Stop condition¶

Egy jó execution nem csak azt tudja, hogyan folytassa, hanem azt is, mikor álljon meg.

Stop lehet:

goal satisfied
terminal failure
user cancellation
approval denied
budget exceeded
no new information
repeated action detected

Ez különösen fontos agentic loopoknál.

Loop detection¶

Runtime nyilvántarthatja:

same tool + same args repeated N times
same plan repeated
no state change across steps

Például:

query_logs(service=A, last=5m)
query_logs(service=A, last=5m)
query_logs(service=A, last=5m)

ha nincs új információ, állítsuk meg vagy változtassunk stratégiát.

Idempotency write műveleteknél¶

A retry legnagyobb veszélye side effectnél.

Példa:

create refund
 ↓
server processed it
 ↓
network response lost
 ↓
client retries

Idempotency nélkül:

duplicate refund

Használjunk:

operation_id / idempotency_key

és az external boundary garantálja:

same key → same logical operation

A modell ne generáljon minden retry-nál új operation ID-t.

At-most-once vs at-least-once gondolkodás¶

Agentic write operationnél is klasszikus distributed systems kérdés van.

Nem az AI a probléma lényege.

Kérdezzük meg:

Mi történik, ha a request sikerült, de a választ nem kaptuk meg?

Ha erre nincs válaszunk, a retry policy veszélyes.

Compensation¶

Nem minden side effect rollbackelhető egyszerűen.

Példa:

1. create GitHub issue
2. send Slack notification
3. update tracking DB

Ha a 3. hibázik, nem biztos, hogy az első kettőt törölni akarjuk.

Itt saga/compensation szemlélet jöhet:

record partial state
retry failed step
or execute compensating action

A skill orchestration ugyanúgy distributed workflow problem lehet.

Fallback¶

Tool unavailable esetén lehet fallback:

primary metrics provider unavailable
 ↓
secondary provider

vagy:

live data unavailable
 ↓
return partial result with explicit warning

Veszélyes fallback:

live data unavailable
 ↓
use model training memory as current truth

Current external facthez ne legyen hallucination fallback.

Graceful degradation¶

Például PR Review:

diff available ✅
source files available ✅
CI results unavailable ❌

Lehet:

PARTIAL_RESULT

és:

"Code review completed; CI/test-result verification was unavailable."

Ez sokszor jobb, mint teljes failure.

Output validation több szinten¶

Schema validation¶

required fields
enums
types

Referential validation¶

Például finding location:

file exists?
line exists?

Evidence validation¶

finding cites retrieved evidence?

Business validation¶

recommended action permitted?

Ezek közül sok deterministic.

Example: deployment rollback recommendation¶

Skill output:

{
  "recommendation": "ROLLBACK",
  "evidence": [
    "5xx increased from 0.2% to 18% after version 7.5.0"
  ]
}

Runtime:

validate deployment still at 7.5.0
 ↓
validate rollback target exists
 ↓
check authorization
 ↓
require production approval
 ↓
execute rollback with operation id

Ez protects against stale reasoning.

A skill döntése és az action execution között változhatott a világ.

Ezért side effect előtt érdemes revalidate current state.

Time-of-check vs time-of-use¶

AI workflow-kban is klasszikus TOCTOU probléma lehet.

Step 1: skill reads account status
Step 2: user/account changes
Step 3: skill executes action based on stale status

Mutating action előtt friss authoritative validation kell.

Human fallback¶

Ha a rendszer nem tud biztonságosan dönteni:

low confidence
conflicting evidence
high-risk action
policy ambiguity

legyen lehetőség:

ESCALATE_TO_HUMAN

A human review nem failure, hanem explicit control path.

Observability a reliability része¶

Ha nem tudjuk megmondani:

which skill version ran?
which model?
which tools?
which retry?
where did it timeout?

akkor a reliability probléma nehezen javítható.

Ez a következő evaluation/observability fejezetben mélyebb téma lesz.

Anti-pattern: catch-all retry¶

except Exception:
    retry()

különösen write operationnél veszélyes.

Classification kell.

Anti-pattern: prompt-only invariant¶

"Never refund more than 100 EUR."

Ha ez hard business rule, legyen kódban is.

Anti-pattern: unlimited autonomous retry¶

try until it works

Ez cost explosiont, infinite loopot vagy repeated side effectet okozhat.

Anti-pattern: silent fallback to guessed data¶

Tool failure után:

"probably..."

current fact esetén legyen explicit unavailable state.

Takeaways¶

Reliability több layerből áll; nem prompt quality kérdés.
Legyen explicit success/failure taxonomy.
Különítsük el recoverable és terminal hibákat.
Retry policy legyen error-aware, bounded és side-effect-aware.
Precondition/postcondition és deterministic validation vegye körül a model executiont.
Hard business invariantet ne prompt enforce-oljon.
Használjunk timeoutot és execution budgetet.
Agentic executionnek explicit stop condition kell.
Write retryhoz idempotency és operation state szükséges.
Mutating action előtt revalidate current authoritative state-et.
Partial result és human escalation legitim outcome.
Current data hiányára ne legyen hallucination fallback.