Goals, Tasks and Success Conditions¶

A loopnak tudnia kell, mit akar elérni¶

Agentic executionnél veszélyes, ha a runtime csak egy homályos user requestet ad a modellnek, majd addig futtatja, amíg a modell azt nem mondja, hogy kész.

Például:

"Fix the payment bug."

Ez embernek is túl tág lehet. Egy loop számára pedig különösen problémás, mert nem világos:

mi a konkrét target,
milyen scope-ban dolgozhat,
mi számít sikernek,
milyen evidence kell a completionhöz,
mi maradhat unresolved.

Ezért érdemes különválasztani:

User request
    ↓
Execution goal
    ↓
Subtasks / subgoals
    ↓
Success conditions
    ↓
Completion evidence

User request vs execution goal¶

A user request lehet természetes nyelvű és homályos.

"Nézd meg, miért lassú a checkout és javítsd meg."

A runtime ebből alakíthat egy explicitebb execution goalt:

Goal:
Identify the primary cause of checkout latency regression and produce a verified remediation within the allowed repository scope.

Ehhez kapcsolódhatnak constraint-ek:

- read production telemetry
- modify current repository only
- do not deploy automatically
- maximum 25 iterations

A goal nem feltétlenül modell által generált artifact. Sokszor az application layer állítja össze a user intentből és policyból.

Goal mint contract¶

Hasznos mental model:

Goal
├── desired outcome
├── scope
├── constraints
├── required evidence
├── allowed side effects
└── termination semantics

Példa coding task:

desired_outcome: PaymentRetryTest and related retry tests pass without duplicate charge behavior
scope:
  repository: payment-service
constraints:
  - no production deploy
  - no API contract changes without approval
required_evidence:
  - target test passes
  - regression tests pass
  - patch explains root cause

Success condition legyen explicit¶

Gyenge:

Stop when you think the issue is fixed.

Jobb:

Success requires:
1. failing test passes
2. related regression suite passes
3. implementation no longer performs duplicate non-idempotent charge

A completion ne csak model intuition legyen.

Completion evidence¶

A runtime kérdezze:

Milyen evidence bizonyítja, hogy a goal teljesült?

Példák:

Coding¶

- tests passed
- static checks passed
- expected file changed
- no forbidden files changed

Incident diagnosis¶

- root-cause hypothesis supported by metric/log/deployment evidence
- alternative major hypotheses ruled out or marked unresolved

Data extraction¶

- all required fields extracted
- schema valid
- source location recorded for each critical value

Deployment validation¶

- deployment reached desired version
- readiness healthy
- error rate below threshold

Deterministic vs semantic success checks¶

Nem minden success condition ugyanolyan.

Deterministic¶

exit_code == 0
all_required_fields_present
http_status == 200
version == expected_version

Ezeket ne LLM-re bízzuk.

Semantic¶

Does the proposed root cause explain the observed symptoms?
Does the patch preserve the intended architecture?
Is the support response actually helpful and policy-consistent?

Itt model/human/evaluator is kellhet.

Jó design gyakran kombinálja őket:

Hard deterministic gates
        +
Semantic evaluation

Goal decomposition¶

Összetett goal felbontható subtasksra.

Például:

Goal: fix checkout latency regression

Subgoals:
1. establish baseline and affected endpoint
2. correlate regression with recent changes
3. identify root cause
4. implement remediation
5. verify latency and regressions

A decomposition előnye:

progress látható,
részsikerek mérhetők,
failure lokalizálható,
state explicit marad,
resume könnyebb.

Decomposition ne legyen öncélú¶

Nem minden taskot kell 20 subtasksra bontani.

Gyenge:

1. Think about problem
2. Read file
3. Think again
4. Decide whether to inspect another file
5. Think more
...

Ez artificial complexity.

Jobb:

Akkor bontsunk, ha a subtasksnak külön completion state-je, dependency-je vagy failure mode-ja van.

Static vs dynamic task decomposition¶

Static decomposition¶

A workflow előre tudja:

collect evidence
→ analyze
→ propose remediation
→ verify

Ez lehet deterministic orchestration.

Dynamic decomposition¶

A modell/runtime menet közben fedezi fel:

Need to inspect DB latency
        ↓
DB healthy
        ↓
Need to inspect downstream payment provider

Itt a subgoalok runtime-ban alakulnak.

Goal tree / task graph mental model¶

Komplexebb executionnél lehet ilyen state:

Root goal
├── [done] reproduce failure
├── [done] identify duplicate charge path
├── [active] implement idempotency fix
└── [pending] run regression suite

Vagy dependency graph:

A: fetch telemetry
B: inspect deploy
C: compare before/after
D: propose cause
E: verify cause

A ─┐
B ─┼→ C → D → E

Nem kell minden agenthez DAG engine, de ez segít megérteni, hogy a task state legyen explicit.

Partial success¶

Nem minden run binary success/failure.

Például:

Goal: diagnose incident and propose safe remediation

Lehet outcome:

PARTIAL_SUCCESS
- probable root cause identified
- evidence strong
- remediation not verified because staging unavailable

Jobb, mint hamisan SUCCESS-t jelenteni.

Hasznos outcome taxonomy:

SUCCESS
PARTIAL_SUCCESS
BLOCKED
NEEDS_HUMAN
FAILED
CANCELLED
BUDGET_EXCEEDED

Blocked goal¶

A runtimenak legitim állapotként kell kezelnie:

BLOCKED
reason: required production metric unavailable

Nem kell a modellnek „valahogy továbbmenni”.

Ez csökkenti a hallucination pressure-t.

User intent és policy konfliktus¶

Például user:

"Deployold automatikusan productionbe a fixet."

Application policy:

production deployment requires human approval

Execution goal:

Prepare verified production-ready change and request approval for deployment.

A runtime nem egyszerűen lemásolja a user requestet. A goal a user intent + system policy eredménye.

Goal drift¶

Agentic loop közben a modell könnyen eltérhet az eredeti feladattól.

Például:

Goal: fix one retry bug
        ↓
model notices old code
        ↓
starts refactoring entire payment module

Ez goal drift.

Védekezés:

explicit scope,
current goal minden döntésnél,
allowed files/tools,
progress state,
change budget,
out-of-scope action rejection.

Success condition drift¶

Másik veszély:

Original success:
all retry tests pass

Model later:
"The code looks correct now, so we are done."

A runtime ne engedje felülírni a hard completion criteria-t.

Model can propose completion
        ↓
Runtime verifies required conditions
        ↓
COMPLETED or continue

Example: PR repair loop¶

User:

Fix review comments on PR 184.

Execution goal:

Resolve all actionable review findings in PR 184 without introducing test regressions.

Subtasks:

1. load unresolved review findings
2. classify actionable vs non-actionable
3. fix actionable findings
4. run relevant tests
5. verify findings are addressed

Success:

- no unresolved actionable finding remains
- required tests pass
- only permitted repository changed

A modell mondhatja:

"I believe all comments are addressed."

de a runtime újra lekérheti a review state-et és teszteket.

Example: support agent¶

Goal:

Resolve customer's invoice rejection question using current account/invoice data and approved policy.

Success condition:

- correct invoice identified
- rejection reason grounded in current billing data
- explanation matches policy
- if account data unavailable → BLOCKED, not guessed answer

Goal progress¶

Hasznos explicit progress representation:

{
  "goal": "Fix retry bug",
  "progress": [
    {"task": "reproduce failure", "status": "DONE"},
    {"task": "identify cause", "status": "DONE"},
    {"task": "implement fix", "status": "IN_PROGRESS"},
    {"task": "verify regression suite", "status": "PENDING"}
  ]
}

A model contextbe ennek csak releváns projectionje kerülhet.

Anti-pattern: „done” mint szabad szöveg¶

Gyenge:

Model: "Looks good, we're done."
Runtime: stop

Jobb:

Model proposes STOP_SUCCESS
        ↓
Runtime checks:
- required tasks complete?
- deterministic gates pass?
- required evidence exists?
        ↓
yes → complete
no  → continue / fail

Anti-pattern: hidden goal mutation¶

Ne engedjük, hogy a modell észrevétlenül átírja:

Goal A

ból:

Goal B, because A is inconvenient

Replan megengedett lehet, de explicit state transitionként:

REPLAN_REQUESTED
reason: staging unavailable
proposed_new_subgoal: verify with unit/integration evidence instead

A hard top-level goal/policy nem változhat kontrollálatlanul.

Takeaways¶

A user request és az execution goal nem feltétlen ugyanaz.
Egy jó goal tartalmaz outcome-ot, scope-ot, constraint-eket és completion evidence-et.
A success condition legyen explicit; ne a modell „érzésére” bízzuk a completiont.
Determinisztikusan ellenőrizhető feltételeket kód ellenőrizzen.
Subtaskokra akkor bontsunk, ha azoknak külön state-je/dependency-je/failure mode-ja van.
PARTIAL_SUCCESS, BLOCKED, NEEDS_HUMAN legitim outcome-ok.
A runtime védekezzen goal drift és success-condition drift ellen.
A modell javasolhatja a STOP-ot; a runtime dönti el, hogy a completion contract valóban teljesült-e.