Planning and Task Decomposition¶

Miért kell egyáltalán plan?¶

Egy agentic loopnak nem mindig kell explicit terv. Sok feladatnál elég lehet:

observe
  ↓
choose next action
  ↓
act
  ↓
observe again

Viszont ha a feladat több egymásra épülő lépést, függőséget vagy hosszabb futást tartalmaz, egy explicit plan segít abban, hogy a runtime ne csak lokálisan jó következő lépéseket válasszon, hanem a teljes cél felé haladjon.

Például:

Goal:
Fix the failing payment test and open a PR.

Possible plan:
1. inspect failing test
2. inspect payment implementation
3. identify root cause
4. modify code
5. run targeted tests
6. run relevant regression tests
7. summarize change
8. open PR

A plan azonban nem maga az igazság.

A plan egy execution hypothesis arról, hogyan juthatunk el a célhoz. Az environment új observationjei felülírhatják.

Goal vs plan vs state¶

Érdemes három külön fogalomként kezelni:

Goal
  = mit akarunk elérni

Plan
  = jelenlegi elképzelés arról, milyen lépéseken keresztül érjük el

Execution State
  = mi történt ténylegesen eddig és mi a jelenlegi állapot

Például:

Goal:
production incident root cause identified

Plan:
1. query error rate
2. inspect recent deployment
3. inspect logs

State:
step 1 complete
error rate elevated
no deployment in last 24h

A plan 2. lépése ettől még létezhet, de az observation alapján lehet, hogy már nem releváns.

Ezért:

plan ≠ canonical state

A runtime state legyen authoritative; a plan módosítható artifact.

Plan-first vs reactive execution¶

Plan-first¶

A runtime a végrehajtás előtt explicit tervet készít.

Goal
 ↓
Create plan
 ↓
Execute step 1
 ↓
Execute step 2
 ↓
...

Hasznos lehet, ha:

több jól elkülöníthető subtask van,
vannak dependencyk,
hosszabb futás várható,
approvalhoz előre látni kell a tervezett műveleteket,
költséges vagy kockázatos lépések vannak,
a progresszt a usernek is mutatni akarjuk.

Gyenge pontja, hogy a terv könnyen stale lesz.

Reactive execution¶

A modell mindig csak a következő lépést választja a jelenlegi observation alapján.

Goal + current state
       ↓
choose next action
       ↓
new state
       ↓
choose next action

Jó lehet rövid, bizonytalan vagy gyorsan változó environmentben.

Például incident diagnosisnál előre nem biztos, hogy tudjuk, melyik logot kell majd olvasni.

Short-horizon planning¶

Gyakran ez a legjobb kompromisszum.

plan next 2–4 meaningful steps
        ↓
execute
        ↓
observe
        ↓
revise local plan

Nem próbálunk húsz lépéssel előre jósolni, amikor a 3. observation úgyis megváltoztathatja az egész irányt.

Task decomposition¶

Egy nagy cél gyakran jobb, ha kisebb subgoalokra bontjuk.

Például:

Goal:
Prepare a safe production release.

Subgoals:
├── validate build
├── evaluate test state
├── inspect release risk
├── prepare deployment plan
└── obtain approval

A jó subtask általában:

világos responsibilityvel rendelkezik,
van megfigyelhető completion conditionje,
lehetőleg kevéssé függ rejtett implicit state-től,
eredménye más lépések számára strukturáltan felhasználható.

Gyenge decomposition:

1. think about release
2. think more
3. decide what to do

Jobb:

1. read CI result
2. identify failed required checks
3. inspect release diff risk
4. return release-readiness assessment

Mikor ne bontsunk tovább?¶

A túlzott decomposition maga is overhead.

Például:

Goal: read current deployment version

nem kell:

1. decide to read deployment
2. find deployment tool
3. call deployment tool
4. inspect response
5. extract version

Ha a capability már jól definiált tool vagy skill, használjuk azt atomic stepként.

A decomposition boundary sokszor ott van, ahol már van stabil reusable capability.

Dependency graph¶

Nem minden plan egyszerű lista.

Például:

        build
       /     \
  unit tests  static analysis
       \     /
      package
         ↓
      approval
         ↓
      deploy

Ez inkább DAG, mint lineáris checklist.

Hasznos representation:

{
  "steps": [
    {"id": "build", "depends_on": []},
    {"id": "tests", "depends_on": ["build"]},
    {"id": "scan", "depends_on": ["build"]},
    {"id": "deploy", "depends_on": ["tests", "scan", "approval"]}
  ]
}

Itt a runtime determinisztikusan tudja, melyik step válik eligible-lé.

Nem kell az LLM-nek minden iterációban újra kitalálnia a dependency semanticsot.

Plan mint typed artifact¶

Production rendszerben a plan jobb, ha nem csak szabad szöveg.

Például:

{
  "goal": "Fix failing payment test",
  "steps": [
    {
      "id": "inspect_test",
      "description": "Read failing test and failure output",
      "status": "PENDING",
      "depends_on": []
    },
    {
      "id": "inspect_code",
      "description": "Read relevant payment implementation",
      "status": "PENDING",
      "depends_on": ["inspect_test"]
    }
  ]
}

A runtime így tud:

progresszt tárolni,
checkpointolni,
resume-olni,
dependencyt ellenőrizni,
auditálni,
plan diffet mutatni.

Plan generation vs plan validation¶

A modell generálhat tervet, de a runtime validálhatja.

Például:

Model proposes:
1. inspect production DB
2. delete suspicious row
3. restart service

A runtime policy:

production DB write → forbidden
restart production service → approval required

Tehát:

LLM plan proposal
      ↓
policy / capability validation
      ↓
accepted executable plan

A plan nem kerülheti meg a tool authorizationt.

Replanning¶

Replanning akkor kell, amikor új observation miatt a jelenlegi terv már nem megfelelő.

Tipikus trigger:

Assumption invalidated¶

Plan assumes recent deployment caused incident.
Observation: no deployment happened.

→ új diagnosztikai irány.

Step impossible¶

Required repository is unavailable.

→ fallback vagy human escalation.

Goal changed¶

User: "Don't fix it yet, only explain the cause."

→ a mutation lépések kiesnek.

Better path discovered¶

A single failing config value explains all symptoms.

→ a maradék exploratory lépések elhagyhatók.

Replanning ne jelentse az egész plan újragenerálását mindig¶

Gyenge pattern:

every observation
      ↓
regenerate entire 20-step plan

Ez:

drága,
instabil,
nehezen auditálható,
fölöslegesen változtat már jól működő részeken.

Jobb lehet local repair:

step 4 failed
 ↓
replace step 4 with 4a + 4b
 ↓
keep unaffected steps

Plan fixation¶

A másik véglet, amikor a runtime túl mereven ragaszkodik a tervhez.

Plan says: query deployment logs
Observation says: service never deployed
Runtime: query deployment logs anyway

Ez plan fixation.

A tervet mindig a current environment evidence fényében kell értelmezni.

Coding agent példa¶

User:

Fix the flaky retry test.

Első plan:

1. run failing test repeatedly
2. inspect test code
3. inspect retry implementation
4. identify race/timing dependency
5. patch
6. rerun repeated test
7. run related suite

Observation step 1 után:

Failure only occurs with parallel test execution.

Replan:

1. inspect shared mutable test fixture
2. inspect test isolation
3. patch fixture lifecycle
4. rerun parallel suite

A jó loop nem azért „intelligens”, mert előre mindent tudott, hanem mert evidence alapján képes volt tervet változtatni.

Deterministic workflow vs model-generated plan¶

Ha a folyamat ismert:

validate → approval → deploy → verify

ne kérjük minden futásnál az LLM-et, hogy találja ki ezt újra.

Ez workflow.

A modellen belüli agentic planning inkább ott értékes, ahol:

a következő lépés nem ismert előre,
semantic investigation kell,
environment feedback változtatja az irányt.

Jó hibrid:

Deterministic release workflow
        │
        ├── build
        ├── tests
        ├── agentic risk-analysis island
        ├── approval
        └── deploy

Anti-pattern: plan mint chain-of-thought adatbázis¶

A runtimenak nincs szüksége arra, hogy hosszú, belső gondolatmenetet tároljon „plan” címén.

Tároljuk inkább azt, ami operationally hasznos:

- explicit goal
- planned step
- dependency
- status
- evidence
- decision rationale röviden, ha audit kell

Nem kell a végrehajtás reprodukálhatóságát rejtett reasoning transcriptre építeni.

Takeaways¶

A goal, plan és canonical execution state három külön artifact.
A plan egy módosítható execution hypothesis, nem authoritative truth.
Stabil, ismert folyamatnál deterministic workflow jobb, mint újragenerált agent plan.
Bizonytalan környezetben a short-horizon planning gyakran jobb, mint a hosszú upfront terv.
A task decomposition addig hasznos, amíg meaningful, mérhető subgoalokat hoz létre.
A dependencyket érdemes explicit runtime adattá tenni.
Új observation invalidálhatja a tervet; replanning legyen evidence-driven.
Kerüljük mind az over-planninget, mind a plan fixationt.
A runtime validálja a planben szereplő capabilityket, permissionöket és risk boundaryket.
A plan legyen checkpointolható, auditálható artifact, ne implicit modell-emlékezet.