Agentic Loop Mental Model¶

Mi az agentic loop?¶

Egy egyszerű LLM-hívásnál a rendszer lényegében ezt csinálja:

input
  ↓
model
  ↓
output

Ez sok feladatra teljesen elég. Például:

szöveg összefoglalása,
klasszifikáció,
egy egyszerű strukturált válasz előállítása,
rövid magyarázat,
egyetlen döntési javaslat.

Az agentic loop akkor jelenik meg, amikor a feladat megoldásához a rendszernek többször kell:

megfigyelnie az aktuális állapotot,
döntést hoznia a következő lépésről,
végrehajtania egy műveletet,
feldolgoznia az új eredményt,
majd eldöntenie, hogy folytatja-e.

Alap mental model:

Goal
 ↓
Observe
 ↓
Decide
 ↓
Act
 ↓
Observe result
 ↓
Continue / Replan / Ask / Stop

A lényeg:

Az agentic rendszer nem egyszerűen hosszabb prompt, hanem egy runtime által kontrollált iteratív execution model.

A modell csak egy komponens a loopban¶

Gyakori félreértés:

Agent = LLM that thinks in a loop

Jobb mental model:

Agent Runtime
├── canonical execution state
├── model calls
├── tool / skill execution
├── validation
├── authorization
├── budgets
├── stop conditions
├── retries / recovery
└── observability

A modell tipikusan ezt segíti:

current goal + current observations
              ↓
        choose next step

A runtime viszont azt kontrollálja, hogy a választott lépés:

megengedett-e,
végrehajtható-e,
belefér-e a budgetbe,
érvényes inputot tartalmaz-e,
milyen új state keletkezik utána,
folytatható-e a loop.

Példa: coding agent¶

User goal:

Fix the failing payment retry test.

Single-call megközelítés:

prompt with code + test
        ↓
model suggests patch

Agentic execution:

Goal: fix failing test
        ↓
Read failing test
        ↓
Read implementation
        ↓
Decide patch
        ↓
Edit file
        ↓
Run test
        ↓
FAIL
        ↓
Observe failure
        ↓
Read related code
        ↓
Edit again
        ↓
Run test
        ↓
PASS
        ↓
Stop

A fontos különbség nem az, hogy a modell „okosabb”.

Hanem az, hogy:

A környezet visszajelzése minden iteráció után új információt ad, amely alapján a runtime új döntést kérhet.

Mikor érdemes loop?¶

Loop akkor indokolt, ha a következő lépés nem ismert előre, és az előző lépés eredményétől függ.

Például:

Diagnose production incident

Nem tudjuk előre, hogy szükség lesz-e:

deployment state-re,
logokra,
metrikákra,
release diffre,
dependency healthre.

A következő observation határozhatja meg a következő actiont.

query error rate
       ↓
errors started after deploy
       ↓
inspect latest deployment
       ↓
new dependency version
       ↓
inspect dependency errors

Ez természetes agentic loop.

Mikor nem kell loop?¶

Ha az execution path előre ismert:

1. load invoice
2. validate schema
3. calculate tax
4. store result

akkor ez tipikusan workflow / normál application logic.

Nem kell a modellnek minden lépésnél újra eldöntenie:

"What should I do next?"

ha a válasz determinisztikusan ismert.

Anti-pattern: agent everywhere¶

Gyenge:

LLM decides:
- whether to validate input
- whether to save record
- whether to commit transaction
- whether to retry database operation

Jobb:

Application workflow owns deterministic control
                 │
                 └── agentic decision only where ambiguity/reasoning is useful

Workflow vs agentic loop¶

Deterministic workflow¶

A → B → C → D

Az alkalmazás előre tudja a control flow-t.

Conditional workflow¶

A
↓
condition?
├── yes → B
└── no  → C

Ez még mindig determinisztikus workflow.

Agentic loop¶

Current state
     ↓
Model/runtime decides next useful action
     ↓
Environment changes
     ↓
Decision is made again

A control flow részben runtime-ban keletkezik.

Agentic islands¶

A production rendszerekben gyakran nem az a jó design, hogy minden agentic.

Inkább:

Deterministic workflow
        ↓
Agentic diagnosis step
        ↓
Deterministic validation
        ↓
Human approval
        ↓
Deterministic execution

Ezt nevezhetjük agentic island mental modelnek.

Például:

Incident received
      ↓
validate metadata             deterministic
      ↓
agent investigates cause      agentic
      ↓
proposed remediation
      ↓
approval                     deterministic
      ↓
restart deployment            deterministic tool execution

Ez sokszor jobb, mint egy teljesen autonóm „do anything” agent.

A loop mint state machine¶

Hasznos úgy gondolni rá, mint state machine-re.

Például:

RUNNING
  │
  ├── OBSERVING
  ├── DECIDING
  ├── EXECUTING
  ├── WAITING_FOR_HUMAN
  ├── REPLANNING
  ├── COMPLETED
  └── FAILED

Ezeket nem a modellnek kell implicit módon „észben tartania”.

A runtime tartsa őket canonical state-ként.

Például:

{
  "run_id": "run-184",
  "status": "RUNNING",
  "goal": "Fix failing retry test",
  "iteration": 4,
  "last_action": "run_test",
  "last_observation": "AssertionError: expected 1 charge, got 2",
  "remaining_tool_calls": 12
}

Canonical state vs model context¶

Ez kritikus különbség.

Gyenge:

Conversation history = execution state

Ha az egész state csak a prompt historyban van, akkor:

nehéz checkpointolni,
nehéz resume-olni,
nehéz query-zni,
nehéz auditálni,
nehéz determinisztikusan enforce-olni budgeteket,
compaction után információ veszhet el.

Jobb:

Runtime state store
      ↓
Context builder selects relevant projection
      ↓
Model sees only what it needs now

Tehát:

Context a model inputja; state a rendszer igazsága.

One iteration mint explicit transaction¶

Egy iteration felbontható:

1. read canonical state
2. construct model context
3. request next action
4. validate action
5. authorize action
6. execute action
7. normalize observation
8. update canonical state
9. evaluate stop conditions

Ez sokkal jobb production mental model, mint:

while true:
    ask_llm_what_to_do()

Model output legyen next-step decision¶

A model output lehet strukturált:

{
  "action": "USE_TOOL",
  "tool": "run_test",
  "arguments": {
    "test": "PaymentRetryTest"
  },
  "reason": "The latest patch should be verified before further changes."
}

vagy:

{
  "action": "STOP",
  "outcome": "SUCCESS",
  "evidence": [
    "PaymentRetryTest passes",
    "related retry tests pass"
  ]
}

A runtime ezután saját szabályai szerint validál.

Environment feedback teszi agentic-ké¶

Agentic loopnál a környezet változhat.

Például:

Iteration 1:
service healthy

Iteration 2:
deployment starts

Iteration 3:
new pod crashloops

A modell korábbi assumptionje nem canonical truth.

Minden releváns lépésnél új observation keletkezhet.

Ezért az agentic rendszer inkább:

closed-loop control

mint egyszerű:

open-loop generation

Bounded autonomy¶

A loop nem jelenti azt, hogy korlátlan autonómiát adunk.

Productionban inkább:

Autonomy
   inside
explicit boundaries

Boundary lehet:

allowed tools,
allowed repositories,
max iterations,
max cost,
read-only mode,
environment scope,
approval requirement,
timeout,
stop policy.

Például coding agent:

may edit files in current repository
may run tests
may not push to main
may not access production credentials
max 20 iterations

Cost és latency multiplication¶

Egy loop minden iterációban új költséget adhat:

model call
+ tool call
+ retrieval
+ model call
+ tool call
+ ...

Ezért egy agentic request költsége nem csak:

one model invocation

hanem:

Σ iterations(model + tools + retrieval + state operations)

Ez a későbbi execution budget témában fontos lesz.

Anti-pattern: while true agent¶

while True:
    action = llm.next_action(history)
    execute(action)

Ha nincs:

explicit state,
stop condition,
iteration limit,
authorization,
typed action,
error policy,
observability,

akkor ez nem robust agent architecture, csak uncontrolled loop.

Anti-pattern: modell dönt mindenről¶

Az agentic runtime nem attól lesz „agent”, hogy minden döntést LLM végez.

Például ezek általában determinisztikusak legyenek:

input schema validation
authorization
budget check
idempotency
allowed tool enforcement
transaction integrity
hard stop limit

A modell ott adjon értéket, ahol valóban semantic ambiguity, planning vagy reasoning van.

Takeaways¶

Az agentic loop iteratív execution model, nem egyszerűen hosszú prompt.
Alap ciklus: observe → decide → act → observe → continue/stop.
A modell egy döntési komponens; a runtime birtokolja az execution state-et és a kontrollt.
Workflow akkor jobb, ha a control flow előre ismert; loop akkor, ha a következő action az aktuális environment state-től függ.
Productionban gyakran a deterministic workflow + agentic islands a legjobb kombináció.
Canonical execution state ne csak a model contextben létezzen.
Egy iteration kezelhető explicit state transitionként vagy transactionként.
Az autonómia legyen bounded: tools, permissions, budgets, stop rules és approval gates alatt.
Agentic loopot csak ott használjunk, ahol a dinamikus döntés ténylegesen értéket ad.