Stop Conditions and Execution Budgets

Miért kell explicit stop logic?

Egy agentic loop alapból könnyen tudna korlátlanul futni:

observe
 ↓
decide
 ↓
act
 ↓
observe
 ↓
repeat...

Ezért a runtime-nak nem csak azt kell tudnia, hogyan folytasson egy run-t, hanem azt is, mikor kell kötelezően megállnia.

A modell javasolhatja, hogy:

STOP_SUCCESS
STOP_FAILED
CONTINUE

viszont a hard stop enforcement a runtime feladata.

A model proposes termination. The runtime owns termination.

Terminal state-ek

Hasznos explicit állapotok:

COMPLETED
FAILED
CANCELLED
BLOCKED
EXPIRED
BUDGET_EXHAUSTED
WAITING_FOR_HUMAN
WAITING_FOR_EXTERNAL_EVENT

A WAITING_* nem feltétlen terminal, inkább suspended state.

Például:

RUNNING
  ↓
approval required
  ↓
WAITING_FOR_HUMAN
  ↓
approval arrives
  ↓
RUNNING

Success stop condition

A legjobb success condition nem az, hogy:

LLM says: "Done."

hanem explicit evidence.

Például coding agent:

Goal:
Fix failing retry test.

Success:
- patch exists
- target test passes 20 consecutive runs
- related regression suite passes
- repository remains clean except intended changes

A runtime ellenőrizheti:

model proposes STOP_SUCCESS
        ↓
check success contract
        ↓
all true? → COMPLETED
otherwise → continue / replan

Failure stop condition

Nem minden hiba retry-zható.

Például:

NOT_AUTHORIZED
FORBIDDEN_ACTION
INVALID_GOAL
REQUIRED_RESOURCE_PERMANENTLY_MISSING
UNSAFE_TO_CONTINUE

Ezeknél sokszor helyes:

stop / escalate

nem pedig:

ask model for another clever workaround

Cancellation

A user vagy rendszer megszakíthatja a run-t.

RUNNING
  ↓ cancel requested
CANCELLING
  ↓ cleanup / settle in-flight work
CANCELLED

Fontos kérdés:

Mit jelent cancellation egy már elindított side effect esetén?

Például email küldés vagy deployment már lehet irreverzibilis.

A cancellation nem rollback-varázslat.

A runtime külön kezelje:

requested cancellation
vs
in-flight operation outcome
vs
possible compensation

Execution budget

A budget explicit korlát a loop autonómiájára.

Tipikus dimenziók:

• max iterations,
• max model calls,
• max tool calls,
• wall-clock deadline,
• max token usage,
• max estimated/actual cost,
• max retries,
• per-tool quota,
• max nested sub-runs.

Példa:

{
  "max_iterations": 20,
  "max_tool_calls": 40,
  "deadline_seconds": 300,
  "max_cost_usd": 2.50,
  "max_retries_per_action": 2
}

Hard vs soft budget

Hard limit

Nem léphető túl.

Például:

max_cost_usd = 5

A runtime a következő drága call előtt megtagadhatja az executiont.

Soft limit

Triggerelhet viselkedésváltást.

at 70% cost budget:
- switch to cheaper model
- reduce exploration
- ask human whether to continue

A kettőt külön érdemes kezelni.

Budgetet step előtt is ellenőrizni kell

Gyenge:

call expensive model
 ↓
cost becomes $8
 ↓
check $5 budget

Jobb:

estimate/reserve step cost
       ↓
within remaining budget?
  ├── yes → execute
  └── no  → stop/escalate

Nem minden cost előre pontosan ismert, de lehet conservative estimate.

Iteration limit

A legegyszerűbb safety net:

iteration <= N

De önmagában kevés.

Egy loop 10 iteráció alatt is elpazarolhat sok pénzt vagy side effectet.

Ezért többdimenziós budget jobb:

iterations + tool calls + time + cost

No-progress detection

A runtime megállíthat vagy replan triggerelhet akkor is, ha formálisan még van budget, de nincs előrelépés.

Példa:

iteration 4: search same file
iteration 5: search same file
iteration 6: search same file

vagy:

same tool
same arguments
same error
repeated 3 times

Ez loop thrashing.

Lehetséges progress signalok:

• új relevant observation,
• completed subgoal,
• reduced uncertainty,
• changed artifact,
• passed verifier,
• new plan path.

Action fingerprint

Repeated action detectionhez képezhetünk fingerprintet:

fingerprint = action_type + normalized arguments + relevant state version

Például:

query_logs(service=payment, range=1h)

ha ugyanazzal a state-tel és ugyanazzal az eredménnyel ismétlődik, gyanús.

Nem minden ismétlés rossz — pollingnál például legitim lehet — ezért context kell.

No-progress counter

Például:

{
  "consecutive_no_progress_steps": 3,
  "max_no_progress_steps": 4
}

Trigger:

replan
ask human
or stop BLOCKED

Time budget és deadline

Különbség:

CPU/runtime duration
vs
wall-clock deadline

Egy run várhat 30 percig human approvalra. Ez nem feltétlenül ugyanaz a budget, mint aktív compute time.

Lehet:

active_execution_deadline = 5 min
approval_expiry = 24 h
run_expiry = 48 h

Nested loop budget

Ha egy agent skill vagy sub-agent új loopot indít:

Parent run
  ↓
Sub-run A
  ↓
Sub-run B

veszélyes, ha minden sub-run új, teljes budgetet kap.

Például:

parent max cost: $5
sub-agent A: $5
sub-agent B: $5

valójában már $15 lehet.

Jobb:

parent budget
   ↓ allocate
sub-run budget slice

A hierarchical budget legyen aggregálható.

Tool-specific budget

Bizonyos actionök különösen érzékenyek.

Például:

web_search: max 20
production_restart: max 1 + approval
email_send: max 5

Nem minden tool call azonos risk/cost kategória.

Liveness vs safety

Két cél ütközhet:

Liveness

A rendszer haladjon a cél felé.

Safety

Ne fusson túl sokáig, ne hajtson végre tiltott vagy fölösleges actiont.

Agent runtime tervezésnél mindkettő kell.

Túl szigorú budget:

premature stop

Túl laza budget:

runaway loop

Ez evaluation kérdés is.

Example: incident diagnosis

Budget:

max_iterations: 12
max_log_queries: 5
max_cost: $1.50
active_time: 3 min

Run:

1. query error rate
2. inspect deployment
3. query logs
4. query same logs with same filter
5. query same logs again

Runtime detects repeated no-progress pattern:

same action fingerprint + no new evidence

→ REPLAN.

Ha új stratégia után is nincs evidence:

BLOCKED: insufficient diagnostic evidence

Ez jobb, mint random tool roulette a budget végéig.

Budget exhaustion result

Ne csak generic error legyen.

Például:

{
  "status": "BUDGET_EXHAUSTED",
  "goal_progress": "PARTIAL",
  "completed": ["repository inspected", "root-cause candidates narrowed"],
  "remaining": ["verify candidate fix"],
  "reason": "maximum tool-call budget reached"
}

Így human vagy későbbi run folytathatja.

Stop condition ordering

A runtime step boundarynál ellenőrizhet például ilyen sorrendben:

1. cancellation requested?
2. unsafe / forbidden state?
3. hard budget exhausted?
4. success conditions satisfied?
5. terminal failure?
6. no-progress threshold?
7. continue

A konkrét sorrend domainfüggő, de legyen explicit.

Anti-pattern: a modell kezeli a budgetet prose-ból

Prompt:
"Please do not use more than 10 tool calls."

Ez nem hard guarantee.

A runtime számolja:

tool_calls_used += 1

és fizikailag ne engedje a 11. callt.

Anti-pattern: csak max iterations

A max_iterations=100 nem mond semmit:

• costról,
• side effectről,
• tool burst-ről,
• nested agentekről,
• wall-clock időről.

Budget legyen multidimenzionális.

Anti-pattern: success hallucination

A modell:

"The fix should work now, so we're done."

Ha success criterion szerint test kell, akkor:

no test evidence → not complete

A completion evidence fontosabb, mint a model confidence.

Takeaways

• A stop logic és budget enforcement a runtime felelőssége.
• COMPLETED, FAILED, BLOCKED, CANCELLED, BUDGET_EXHAUSTED legyen explicit outcome.
• A modell javasolhat stopot, de a hard success/failure contractot application code ellenőrizze.
• Budget legyen többdimenziós: iteration, time, tool, token, cost és retry.
• Hard és soft limit külön fogalom.
• A budgetet lehetőleg action előtt ellenőrizzük, nem csak utána.
• No-progress detection fontosabb, mint vakon kifuttatni az iteration limitet.
• Nested loopok/sub-agentek budgetje a parent budgetből származzon.
• Cancellation nem automatikus rollback; side effect és compensation külön probléma.
• Completion evidence erősebb, mint a modell „kész vagyok” állítása.