Loop Patterns and Control Strategies¶

Nincs egyetlen „helyes agent loop”¶

Az agentic loop egy control-flow abstraction. A konkrét pattern attól függ, hogy:

mennyire ismert előre a folyamat,
mennyire változó az environment,
milyen riskű actionök vannak,
kell-e explicit plan,
mennyire fontos a verification,
van-e parallelizálható work,
kell-e több specialist capability.

A kérdés nem az, hogy:

„Melyik agent framework patternt használjam?”

hanem inkább:

Hol kell determinisztikus control flow, és hol ad valódi értéket model-driven döntés?

1. Simple observe → act loop¶

A legegyszerűbb agentic pattern:

Goal
 ↓
Observe
 ↓
Choose next action
 ↓
Execute
 ↓
Observe result
 ↓
repeat / stop

Jó, ha:

a task rövid,
a következő lépés environment-dependent,
kevés tool van,
nincs szükség hosszú explicit planre.

Példa:

Investigate why this deployment is unhealthy.

A modell:

query deployment
→ inspect event
→ query relevant metric
→ explain

ReAct-style mental model¶

A szakirodalomban gyakran ReAct néven jelenik meg a reasoning/action interleaving gondolata.

Engineering szempontból a fontos rész:

observation
 ↓
next-action decision
 ↓
tool action
 ↓
new observation

Nem az a lényeg, hogy a runtime hosszú hidden reasoning transcriptet tároljon.

Production implementationben elég lehet explicit:

{
  "action": "QUERY_METRIC",
  "reason_summary": "Error rate rose after config reload",
  "arguments": {...}
}

2. Plan → Execute¶

Itt előbb terv készül:

Goal
 ↓
Plan
 ↓
Execute steps
 ↓
Verify

Hasznos:

több lépéses researchnél,
coding tasknál,
migration/release preparationnél,
amikor progress UI vagy approval miatt kell előre látható terv.

Veszély:

plan fixation

Ezért execution közben observation alapján legyen replanning lehetőség.

3. Planner / Executor separation¶

Külön responsibility:

Planner
  ↓ plan/subgoal
Executor
  ↓ actions
Environment
  ↓ observations
Planner / Controller

A planner és executor lehet:

ugyanazon model külön invocationja,
külön skill,
külön model,
részben deterministic component.

Mikor ad értéket?¶

Ha a planning és execution eltérő contextet/capabilityt igényel.

Például:

Planner:
repository structure + issue + architecture constraints

Executor:
one concrete file + edit tool + tests

Így kisebb contexttel dolgozhat az executor.

Mikor overengineering?¶

Ha a task:

read invoice and explain rejection

Nem kell két „agent személyiséget” létrehozni.

4. Generate → Verify → Repair¶

Erősen hasznos pattern olyan outputnál, amit ellenőrizni lehet.

Generate
 ↓
Verify
 ├── pass → done
 └── fail
       ↓
     Repair
       ↓
     Verify

Példák:

code generation + tests,
SQL + validator/sandbox,
structured data + schema/business checks,
config + syntax checker,
document generation + rubric review.

Ez gyakran jobb, mint egy open-ended general-purpose agent.

5. Deterministic workflow with agentic islands¶

Az egyik legfontosabb production pattern.

A teljes process ismert, csak néhány pont igényel semantic/model-driven döntést.

Deterministic workflow
│
├── validate input
├── fetch required data
├── [agentic analysis island]
├── policy check
├── approval
├── execute deterministic action
└── verify outcome

Példa release:

build ───────── deterministic
tests ───────── deterministic
risk analysis ─ agentic
approval ────── deterministic gate
deploy ──────── deterministic
health check ── deterministic + semantic summary optional

Ez sokszor megbízhatóbb, olcsóbb és egyszerűbb, mint az egész folyamatot agentre bízni.

6. Supervisor / worker pattern¶

Egy supervisor subtaskokat oszt specialist worker capabilityknek.

Supervisor
   ├── Code Review Worker
   ├── Security Worker
   └── Test Analysis Worker
          ↓
      aggregate results

Hasznos lehet, ha valóban külön domain/context/tool boundaryk vannak.

Nem kell feltétlen külön LLM agent minden workerhez; worker lehet determinisztikus service vagy skill is.

Supervisor/worker egy orchestration pattern, nem kötelezően multi-agent LLM pattern.

7. Parallel fan-out / fan-in¶

Független subtaskok párhuzamosíthatók:

             ┌→ analyze logs ─────┐
Goal → split ├→ analyze metrics ──┼→ aggregate
             └→ analyze deploys ──┘

Előny:

latency csökkenthető.

Hátrány:

cost egyszerre nőhet,
duplicate work,
conflict resolution kell,
shared budget kezelése nehezebb.

A runtimenak ismernie kell dependencyt és aggregation semanticsot.

8. Event-driven loop¶

Nem minden loop egy processben futó while.

Például:

Run requests approval
 ↓
state = WAITING_FOR_HUMAN
 ↓
process ends
...
approval event arrives
 ↓
queue / event handler
 ↓
load state
 ↓
resume run

Vagy:

submit long-running build
 ↓ WAITING_FOR_EXTERNAL_EVENT
build-completed webhook
 ↓ resume

Ez productionban fontos a hosszú lifecycle miatt.

9. Polling loop¶

Ha nincs event/webhook:

check job status
 ↓ not done
WAIT
 ↓
check again

Pollingnál külön policy kell:

poll interval,
max wait,
backoff,
jitter,
deadline.

Ne model döntse el másodpercenként, hogy „nézzük meg újra”.

A wait/poll scheduling legyen deterministic runtime concern.

10. Hierarchical planning¶

Nagy cél:

Goal
 ↓
High-level subgoals
 ↓
local short-horizon plans
 ↓
actions

Például software migration:

1. inventory
2. compatibility analysis
3. migration implementation
4. verification

Minden high-level subgoalon belül külön local agentic loop lehet.

Hasznos hosszabb project-like runnál, de komplexitása nagy.

11. Multi-agent conversation pattern¶

Például:

Architect agent
 ↔ Security agent
 ↔ Implementer agent

Ez látványos, de gyakran túlhasznált.

Kérdezzük meg:

kell tényleg külön state?
külön permission?
külön tool set?
külön model/context specializáció?
párhuzamosítható munka?

Ha nem, lehet, hogy egyszerűbb:

one runtime
+ multiple skills/evaluators

Pattern selection matrix¶

Task property	Prefer
fixed known sequence	deterministic workflow
short uncertain investigation	observe/act loop
multi-step but changing path	short-horizon plan + replan
verifiable artifact generation	generate/verify/repair
long-running external waits	event-driven run
independent specialist analyses	fan-out/fan-in or workers
high-risk known process with semantic step	workflow + agentic island
genuinely separable specialist autonomy	supervisor/workers, possibly multi-agent

Control strategy lehet hibrid¶

Például coding agent:

Deterministic outer workflow
        ↓
1. checkout repo
2. create sandbox
3. agentic investigation/edit loop
4. deterministic tests
5. agentic repair if tests fail
6. deterministic diff checks
7. human approval

Nem kell választani:

workflow OR agent

A jó architecture gyakran:

workflow AND bounded agentic loops

Model routing patternen belül¶

Egy loopon belül is lehet külön model:

cheap model → route/simple extraction
strong model → planning/complex decision
specialized model → code

De a model routing ne változtassa meg a canonical state contractot.

Agent Runtime
   ↓ ModelPort
provider/model implementation

Deterministic transition where possible¶

Példa:

if tool result == NOT_AUTHORIZED:
    state = BLOCKED

Ne kérjük LLM-et:

"What do you think we should do when authorization failed?"

Másik példa:

if tests_passed and all_success_conditions_met:
    COMPLETE

A semantic döntést használjuk ott, ahol valóban semantic uncertainty van.

Loop nesting¶

Például:

Parent planning loop
  ↓
Coding sub-loop
  ↓
Verification repair loop

Nestingnél fontos:

shared budget,
parent-child state reference,
cancellation propagation,
error propagation,
trace correlation.

Különben agent explosion jöhet.

Anti-pattern: agent everywhere¶

input validator agent
router agent
DB agent
formatting agent
logging agent

Ha determinisztikus code megoldja, nincs ok LLM loopra.

Agentic decision drágább, lassabb és kevésbé predictable.

Anti-pattern: multi-agent roleplay architektúra¶

CEO Agent
CTO Agent
Senior Engineer Agent
Junior Engineer Agent

Ha mind ugyanazt a contextet és toolokat kapja, lehet, hogy csak tokenben drága szerepjáték.

A valódi architectural separation inkább:

responsibility
context
permission
tool capability
state ownership

Anti-pattern: open-ended autonomy ismert processhez¶

Ha a business folyamat:

validate → calculate → approval → execute

akkor ne adjunk 40 toolt a modellnek azzal, hogy:

"Handle the process however you think best."

A known invariants legyenek kódban.

Takeaways¶

Nincs univerzális agent loop; a control strategy task- és riskfüggő.
Rövid bizonytalan taskhoz simple observe/act loop elég lehet.
Multi-step taskhoz short-horizon plan + replanning gyakran jobb.
Verifikálható artifactnál generate → verify → repair erős pattern.
Productionban különösen értékes a deterministic workflow + agentic islands megközelítés.
Supervisor/worker nem feltétlen multi-LLM; worker lehet skill/service is.
Event-driven execution fontos hosszú wait/approval/external-job lifecycle-nál.
Multi-agentet csak valódi responsibility/context/permission boundary esetén használjuk.
Deterministic transitiont ne delegáljunk fölöslegesen modellnek.
Nested loopnál budget, cancellation és tracing legyen hierarchikus.