Execution State and Scratchpad

Mi az execution state?

Egy agentic run közben folyamatosan változik a rendszer állapota:

current goal
current step
completed steps
pending work
observations
artifacts
budget usage
approvals
errors

Ha ezt csak a modell conversation contextjére bízzuk, a runtime törékennyé válik.

A fontos mental model:

A model context egy aktuális view. A canonical execution state az application runtime tulajdona.

Canonical Run State
        ↓ projection
Model Context
        ↓
LLM decision
        ↓ validated transition
Canonical Run State

State vs context vs scratchpad vs memory

Ezeket érdemes különválasztani.

Execution state

A run authoritative operational állapota.

Például:

{
  "run_id": "run-1842",
  "status": "RUNNING",
  "goal": "Fix failing payment test",
  "current_step": "run_regression_tests",
  "completed_steps": ["inspect_failure", "patch_code"],
  "tool_calls_used": 7,
  "cost_used_usd": 0.84
}

Context

Az az információ, amit az adott model callhoz kiválasztunk.

relevant goal
+ current state summary
+ latest observations
+ allowed tools
+ relevant code/docs

Nem kell a teljes state minden mezőjét minden hívásban a modell elé tenni.

Scratchpad

Rövid életű working artifactok vagy explicit intermediate notes.

Példák:

suspected root causes
candidate files
current hypothesis
temporary comparison table

A scratchpad lehet runtime-managed, de nem kell authoritative domain state-nek tekinteni.

Memory

A current runon túl is fennmaradó információ.

Például:

user preference
previous incident lesson
repository convention
long-term project fact

Ez már külön memory architecture kérdés.

execution state = this run
memory          = beyond this run

Mi legyen canonical?

Általában az, amire a runtime hard controlt épít.

Például:

• run status,
• goal és success criteria,
• iteration counter,
• budget usage,
• completed/pending step,
• tool call result reference,
• approval state,
• side-effect idempotency key,
• checkpoint version.

Ne a modell szabad szövegéből próbáljuk visszafejteni:

"I think I already ran the tests earlier."

Jobb:

{
  "test_execution": {
    "id": "test-781",
    "suite": "payment-regression",
    "status": "PASSED",
    "completed_at": "..."
  }
}

State machine mental model

Egy run felfogható state machine-ként.

Például:

CREATED
  ↓
RUNNING
  ├──→ WAITING_FOR_HUMAN
  ├──→ WAITING_FOR_EXTERNAL_EVENT
  ├──→ FAILED
  ├──→ CANCELLED
  └──→ COMPLETED

A transitiont kiválthatja:

• model decision,
• tool result,
• deterministic rule,
• user input,
• timeout,
• external event.

De a transition végrehajtása a runtime feladata.

LLM proposes: STOP_SUCCESS
        ↓
runtime checks success contract
        ↓
COMPLETED or continue

Egy lehetséges RunState

Konceptuálisan:

{
  "run_id": "run-1842",
  "status": "RUNNING",
  "goal": {
    "description": "Fix flaky retry test",
    "success_conditions": [
      "targeted test passes 20 consecutive runs",
      "related regression suite passes"
    ]
  },
  "plan": {
    "version": 3,
    "steps": []
  },
  "observations": [],
  "artifacts": [],
  "approvals": [],
  "budget": {
    "iterations": 6,
    "tool_calls": 11,
    "cost_usd": 1.18
  },
  "version": 27
}

A konkrét schema rendszerfüggő, de a lényeg az explicit state ownership.

State projection a model contextbe

A teljes state lehet nagy és zajos.

Ezért legyen külön lépés:

Canonical state
     ↓
Context Builder
     ↓
Relevant state projection
     ↓
LLM

Például a modellnek elég lehet:

Goal: fix flaky retry test
Current step: verify patch
Latest observation: target test passed 10/10
Remaining success criterion: related regression suite not yet run
Budget: 4 iterations remaining

Nem kell elé adni az összes korábbi API response-t.

Ez ugyanaz a context engineering elv, csak runtime state-re alkalmazva.

Observations ne vesszenek el chat textben

Tool result:

{
  "suite": "payment-regression",
  "passed": 418,
  "failed": 1,
  "failure": "RefundRetryTest"
}

Tárolhatjuk normalizált observationként:

{
  "type": "TEST_RESULT",
  "source": "test_runner",
  "timestamp": "...",
  "data": {
    "suite": "payment-regression",
    "failed_tests": ["RefundRetryTest"]
  }
}

A conversation transcript lehet audit/debug artifact, de ne az legyen az egyetlen state store.

Intermediate artifacts

Sok agentic task közben keletkeznek artifactok:

• patch,
• generated file,
• query result,
• report draft,
• candidate plan,
• test log,
• screenshot,
• deployment manifest.

Ezeket jobb reference-ként tárolni:

{
  "artifact_id": "artifact-92",
  "type": "PATCH",
  "location": "object://runs/run-1842/patch.diff",
  "sha256": "..."
}

mint minden iterációban teljes egészében visszatolni contextbe.

Checkpoint

Hosszabb runoknál fontos, hogy ne csak process memoryban éljen a state.

step completes
     ↓
state transition
     ↓
persist checkpoint
     ↓
next step

Ha megszakad:

worker dies
network fails
process restarts

akkor:

load checkpoint
 ↓
revalidate environment
 ↓
resume

Nem:

read old chat transcript
 ↓
ask model what probably happened

Resume nem egyszerű continue

A checkpoint lehet korrekt, miközben az environment közben megváltozott.

Példa:

checkpoint:
PR #184 is open

30 minutes later:
PR was merged by a human

Resume előtt friss observation kell.

restore internal state
      +
refresh external preconditions
      ↓
continue / replan / stop

State versioning és concurrency

Ha egyszerre több worker vagy event próbál state-et frissíteni, race condition keletkezhet.

Például:

worker A reads version 27
worker B reads version 27
A writes version 28
B also writes based on stale version 27

Hasznos technikák:

• optimistic locking,
• compare-and-swap version,
• single-writer orchestration,
• transactional update,
• event ordering.

Példa:

UPDATE run
SET state=?, version=28
WHERE run_id=? AND version=27

Ha 0 row módosul, újra kell olvasni a state-et.

Az agentic runtime ugyanúgy concurrency problemekkel találkozik, mint bármely distributed application.

Event log vs snapshot

Két gyakori representation.

Snapshot

current state object

Egyszerű olvasni.

Event log

RUN_CREATED
TOOL_CALLED
TOOL_SUCCEEDED
PLAN_REVISED
APPROVAL_REQUESTED
APPROVAL_GRANTED
RUN_COMPLETED

Jó audit/debug célra.

Gyakran a kettő együtt a legpraktikusabb:

append events
    ↓
maintain current snapshot

Nem feltétlen kell full event sourcing, ha nincs rá valódi szükség.

Scratchpad mint explicit working state

Egy scratchpad lehet például:

{
  "hypotheses": [
    {"text": "shared fixture race", "status": "LIKELY"},
    {"text": "retry timer bug", "status": "REJECTED"}
  ],
  "files_to_inspect": ["RetryService.java", "RefundRetryTest.java"]
}

Ez hasznosabb, mint egy hosszú prose reasoning history.

A runtimenak operationally releváns intermediate conclusions, evidence és pending questions kellenek; nem szükséges belső reasoning transcriptet canonical state-ként tárolni.

Derived state vs source state

Például:

raw observations:
- error rate 12%
- deployment 5 minutes ago

hypothesis:
- deployment likely caused regression

A kettőt külön jelöljük.

FACT / OBSERVATION
vs
HYPOTHESIS / DERIVED

Ez csökkenti annak esélyét, hogy egy korábbi model assumption később „tényként” kerüljön vissza contextbe.

State cleanup és retention

Nem minden run state-et kell örökké megtartani.

Lehet külön retention:

run metadata: 90 days
sensitive tool payload: 7 days
large artifacts: 30 days
aggregated metrics: longer

Security/privacy és cost szempontból is fontos.

Anti-pattern: chat history mint adatbázis

Gyenge:

messages[]

és minden fontos állapot csak valahol prose formában szerepel.

Problémák:

• nehéz determinisztikusan query-zni,
• nehéz resume-olni,
• stale információ marad bent,
• context window növekszik,
• nehéz concurrencyt kezelni,
• implicit state-et hoz létre.

Jobb:

structured canonical state
+ event/trace history
+ selected context projection

Anti-pattern: minden observation bemásolása a következő promptba

Egy 50 lépéses loop végére ez token- és noise-explosion.

Jobb:

persist full evidence externally
        ↓
select / summarize / reference relevant evidence
        ↓
current model call

Takeaways

• A canonical execution state runtime-owned, nem model-owned.
• A model context csak a state aktuális, releváns projectionje.
• State, context, scratchpad és long-term memory külön fogalom.
• Run status, budget, approvals, completed steps és side-effect metadata legyen explicit strukturált state.
• Checkpoint/resume hosszabb vagy asynchronous runoknál alapvető reliability capability.
• Resume után az external environmentet újra kell validálni.
• Concurrency és state versioning normál software-engineering probléma itt is.
• Observationt és hypothesis-t külön reprezentáljuk.
• Artifactokat reference-ként tároljuk, ne minden körben teljes payloadként.
• Chat history hasznos trace lehet, de rossz canonical state store.