Decision and Action Selection¶

A loop minden iterációban következő lépést választ¶

Ha van:

goal + current state + observations

akkor a loopnak el kell döntenie:

What happens next?

Ez a decision/action selection réteg.

Alap mental model:

Goal
+ Canonical state
+ Relevant observations
+ Available capabilities
+ Policy
        ↓
Decision
        ↓
Validated action
        ↓
Execution

A modell segíthet a decisionben, de a runtime kontrollálja, milyen action típusok léteznek és melyek végrehajthatók.

Structured next-action contract¶

Gyenge model output:

"Szerintem most nézzük meg a logokat, aztán talán restartoljuk a service-t."

Nem világos:

most melyik action következik,
melyik tool,
milyen argumentumokkal,
a restart csak ötlet vagy execution request,
szükséges-e approval.

Jobb:

{
  "action": "USE_TOOL",
  "capability": "query_logs",
  "arguments": {
    "service": "payment-service",
    "window_minutes": 15
  },
  "purpose": "Check whether the error spike is concentrated in retry failures."
}

A runtime pontosan egy next stepet kap.

Action taxonomy¶

Hasznos lehet kevés, explicit action type.

Például:

USE_TOOL
USE_SKILL
ASK_HUMAN
WAIT
REPLAN
STOP_SUCCESS
STOP_PARTIAL
STOP_BLOCKED

Egy másik rendszerben:

ACT
ASK
WAIT
STOP

A konkrét enum nem fontos. Az elv:

A model output ne implicit prose control-flow legyen, hanem explicit runtime decision contract.

USE_TOOL¶

Példa:

{
  "action": "USE_TOOL",
  "tool": "read_file",
  "arguments": {
    "path": "src/payment/RetryService.java"
  }
}

Runtime:

validate action schema
↓
check tool is available
↓
authorize scope
↓
execute
↓
store observation

USE_SKILL¶

Ha reusable higher-level capability van:

{
  "action": "USE_SKILL",
  "skill": "analyze_test_failure",
  "input": {
    "test": "PaymentRetryTest"
  }
}

A skill lehet maga is több lépésből implementálva, de az outer loop szempontjából egy capability.

ASK_HUMAN¶

A modell felismerheti, hogy nincs elég információ vagy policy szerint emberi döntés kell.

{
  "action": "ASK_HUMAN",
  "question": "May I modify the public REST contract to resolve this incompatibility?",
  "reason": "The current fix would introduce a breaking API change."
}

Runtime state:

RUNNING
  ↓
WAITING_FOR_HUMAN

Nem kell busy loopban újra meg újra megkérdezni a modellt.

WAIT¶

Long-running executionnél legitim action:

WAIT until build completes

Jobb event/scheduler driven módon:

WAITING_FOR_EVENT
        ↓
build_completed event
        ↓
resume

nem pedig:

poll every second forever

REPLAN¶

Ha az eredeti terv nem működik:

{
  "action": "REPLAN",
  "reason": "Staging environment is unavailable",
  "constraints": [
    "production write access remains forbidden"
  ]
}

Replan nem jelenti a top-level goal/policy felülírását.

STOP¶

A modell javasolhatja:

{
  "action": "STOP_SUCCESS",
  "evidence": [
    "PaymentRetryTest passed",
    "RetryRegressionSuite passed"
  ]
}

De:

model proposes stop
      ↓
runtime completion checks
      ↓
accept / reject stop

One action per iteration¶

Általában egyszerűbb, ha a modell egy iterationben egy következő logical actiont választ.

Gyenge:

{
  "actions": [
    "delete old deployment",
    "deploy new version",
    "restart database",
    "send email"
  ]
}

Ezek között az environment state változhat.

Jobb:

select action
↓
execute
↓
observe
↓
select next action

Kivétel lehet biztonságos, előre validált batch/parallel read.

Parallel action selection¶

Független read-only observationök párhuzamosíthatók.

Például incidentnél:

query metrics ─┐
query logs    ─┼→ combine observations
read deploy   ─┘

Ehhez explicit dependency analysis kell.

Mutating actionök párhuzamosítása sokkal kockázatosabb.

Deterministic routing vs model decision¶

Nem minden next-action választásnak kell LLM.

Determinisztikus¶

if input invalid → STOP_INVALID_INPUT
if approval missing → ASK/WAIT
if max_iterations reached → STOP_BUDGET
if required test not run → run test

Model-driven¶

Which source file is most relevant next?
Which diagnostic query best distinguishes hypothesis A from B?
Which skill fits this ambiguous request?

Hybrid¶

Runtime narrows allowed actions
       ↓
Model selects among safe candidates
       ↓
Runtime validates selection

Ez gyakran jó pattern.

Capability filtering before model call¶

Ne adjunk a modellnek olyan actiont, amit úgysem szabad használni.

Például read-only review agent:

Available:
- read_file
- fetch_diff
- read_test_result

Not exposed:
- merge_pr
- push_commit
- delete_branch

Ez jobb, mint minden toolt átadni, majd promptban kérni:

"Please don't use dangerous tools."

Decision context legyen minimalista¶

A modellnek a next action kiválasztásához tipikusan kell:

current goal
current progress
relevant observations
available capabilities
active constraints
remaining budget

Nem feltétlen kell az egész historical transcript.

Reason field: hasznos, de nem authority¶

Structured decision tartalmazhat rövid reason-t:

{
  "action": "USE_TOOL",
  "tool": "read_recent_deployments",
  "reason": "The error spike started one minute after a release."
}

Ez observability/debug célra hasznos.

De a runtime security decisiont ne a model reason alapján hozza.

"I really need production shell access"

nem authorization proof.

Preconditions¶

Egy actionhez lehetnek explicit preconditionök.

Példa:

restart_service

Preconditions:

- environment == staging
- current service state freshly observed
- no active deployment
- user has restart permission

A runtime enforce-olja.

A modell maximum javasolhat:

{
  "action": "USE_TOOL",
  "tool": "restart_service",
  "arguments": {
    "environment": "staging",
    "service": "payment-service"
  }
}

Postconditions¶

Action után is kellhet check.

restart_service
       ↓
operation accepted
       ↓
observe service health
       ↓
verify desired state

A tool call success nem feltétlen goal success.

Idempotency awareness¶

Ha write action bizonytalan resulttal tér vissza:

create_refund → timeout

A következő decision ne automatikusan ugyanaz legyen.

Runtime metadata:

action_id
idempotency_key
execution_status

A modellnek nem kell minden transactional részletet menedzselnie.

Decision confidence¶

Lehet hasznos mező:

{
  "action": "USE_TOOL",
  "tool": "read_deployment",
  "confidence": 0.62
}

De a numeric confidence nem objektív probability.

Használható routing signalnak, de ne legyen önmagában security gate.

Jobb explicit uncertainty:

known evidence
missing evidence
competing hypotheses

Ambiguity handling¶

Például user:

"Töröld a régi release-t."

Ha több release lehet „régi”:

ASK_HUMAN

jobb, mint model guess + delete.

Decision policy:

ambiguous + high-impact action
→ clarify

Example: incident loop¶

State:

Goal: identify checkout error cause
Observation: error spike at 14:03
Observation: deployment at 14:02

Model decision:

{
  "action": "USE_TOOL",
  "tool": "query_logs",
  "arguments": {
    "service": "payment-service",
    "from": "14:02",
    "to": "14:10"
  },
  "purpose": "Determine the dominant error signature after the deployment."
}

Runtime validates read permission, executes, stores observation, then új iteration.

Example: coding loop¶

State:

Goal: fix duplicate charge retry bug
Patch applied
Target test not yet run

Itt nem kell feltétlen modellhívás.

Deterministic controller:

patch changed
AND required test pending
→ run required test

A modell csak failure után döntheti el, merre diagnosztizáljon tovább.

Ez jó példa arra, hogy egy agentic loopban is lehet sok deterministic transition.

State-machine interpretation¶

A decision valójában state transition proposal:

Current state S
     ↓
decision(action)
     ↓
validated transition
     ↓
New state S'

Ez nagyon közel áll normál software engineeringhez.

Anti-pattern: free-form command execution¶

Gyenge:

Model output:
"Run: rm -rf ..."

Runtime:
shell(model_text)

Itt nincs typed action boundary.

Jobb:

Model chooses allowed capability
        ↓
structured args
        ↓
validation/authorization
        ↓
execution adapter

Anti-pattern: minden iteration LLM routing¶

Ha state alapján egyértelmű:

required test pending

akkor nem kell tokeneket és latencyt költeni arra, hogy a modell eldöntse:

"Talán futtassuk le a tesztet."

Agentic ≠ minden transition probabilistic.

Anti-pattern: hidden multi-step action¶

Tool:

do_everything(command: string)

megnehezíti:

authorizationt,
auditot,
retryt,
approvalt,
granular observationt.

Jobb explicit task-level capabilityk.

Anti-pattern: STOP elfogadása ellenőrzés nélkül¶

Model: STOP_SUCCESS
Runtime: done

helyett:

STOP proposal
↓
completion contract check
↓
verified completion

Takeaways¶

A decision layer a következő explicit actiont választja a current goal/state/observations alapján.
Model output legyen structured action contract, ne prose control-flow.
Hasznos actionök: USE_TOOL, USE_SKILL, ASK_HUMAN, WAIT, REPLAN, STOP.
Determinisztikus transitiont ne bízzunk feleslegesen LLM-re.
Jó pattern: runtime filters candidates → model selects → runtime validates.
A modellnek csak azokat a capabilityket expose-oljuk, amelyeket ténylegesen használhat.
High-impact/ambiguous actionnél clarification vagy approval jobb, mint guessing.
Action execution előtt precondition, utána postcondition check kellhet.
STOP csak proposal; a runtime completion contractja dönt.
Az agentic loop továbbra is state machine, csak bizonyos transitionök kiválasztásában használ probabilistic reasoningot.