Observation and Environment State¶

Observation: a loop kapcsolata a valósággal¶

Egy agentic loop nem csak a saját korábbi szövegére reagál. A környezetből új adatot kell kapnia.

Ezt nevezhetjük observationnek.

Példák:

tool result,
API response,
file content,
test output,
database query result,
deployment state,
metrics/logs,
user response,
approval/rejection,
external event.

Mental model:

Environment
    ↓
Observation
    ↓
Runtime state
    ↓
Model context
    ↓
Next decision

A kulcs:

A modell belső feltételezése nem environment state.

Current state vs model assumption¶

Például egy coding agent korábban ezt olvasta:

PaymentRetryTest = failing

Majd módosított kódot.

Ezután nem feltételezheti:

"Most már biztos passzol."

Új observation kell:

run_test(PaymentRetryTest)
        ↓
exit_code = 0

Ez a closed-loop működés lényege.

Authoritative state¶

Nem minden contextben lévő információ ugyanolyan autoritatív.

Például deployment esetén:

User says: production runs v7.4.1
Old memory says: production runs v7.3.9
Deployment API says: production runs v7.4.2

Ha az aktuális production state a kérdés, akkor a deployment API lehet canonical source.

Hasznos kategóriák:

Authoritative current state
Derived state
Historical observation
User-reported state
Model hypothesis

Ezeket ne mossuk össze.

Observation envelope¶

Production runtime-ban hasznos lehet minden observationt metadata-val tárolni.

Például:

{
  "type": "DEPLOYMENT_STATE",
  "source": "kubernetes-adapter",
  "observed_at": "2026-08-30T14:40:00Z",
  "scope": "production/payment-service",
  "status": "SUCCESS",
  "data": {
    "version": "7.4.2",
    "ready_replicas": 4,
    "desired_replicas": 4
  }
}

Ez több szempontból jobb, mint pusztán:

"Everything looks healthy."

mert van:

source,
timestamp,
scope,
structured payload,
error state.

Stale observation¶

Egy observation idővel elavulhat.

Például:

14:00 deployment healthy
14:05 new rollout begins
14:06 agent wants to restart one pod based on 14:00 state

A 14:00 observation már lehet stale.

Ezért bizonyos action előtt kellhet refresh.

sensitive action
      ↓
refresh relevant state
      ↓
validate preconditions
      ↓
execute

Observe-before-act¶

Különösen mutating action előtt fontos pattern.

Például:

Goal: stop failed staging deployment

Gyenge:

model remembers deployment is still running
↓
cancel_deployment(id)

Jobb:

get_deployment(id)
↓
status == RUNNING ?
↓
request cancel

Ez csökkenti a race condition és stale-assumption problémát.

Time-of-check vs time-of-use¶

Klasszikus TOCTOU probléma agentic rendszernél is létezik.

observe balance = 100 EUR
        ↓
other process changes balance
        ↓
agent acts based on old balance

A valódi enforcementet a tool/domain service végezze atomikusan, ahol szükséges.

A modell observationje nem helyettesíti a transaction boundaryt.

Observation normalization¶

External tool output gyakran túl nagy vagy provider-specific.

Például Kubernetes API response helyett a modelnek lehet elég:

{
  "deployment": "payment-service",
  "version": "7.4.2",
  "ready": 3,
  "desired": 4,
  "conditions": [
    "Progressing=True",
    "Available=False"
  ]
}

Architecture:

External system
      ↓
Adapter
      ↓
Normalized observation
      ↓
Agent runtime

Előny:

kevesebb token,
kisebb coupling,
könnyebb evaluation,
könnyebb security filtering,
stabilabb context.

Raw data vs interpreted observation¶

Néha külön érdemes tárolni:

Raw evidence
     ↓
Normalized observation
     ↓
Model interpretation

Például log line:

ERROR duplicate key value violates unique constraint payment_id_key

Normalized observation:

{
  "category": "DATABASE_CONSTRAINT_ERROR",
  "resource": "payment",
  "constraint": "payment_id_key"
}

Model hypothesis:

A retry may be attempting to insert the same payment twice.

A hypothesis nem ugyanaz, mint az observation.

Fact vs inference separation¶

Ez különösen fontos incident diagnosisnál.

Például:

FACT:
Error rate increased from 0.2% to 12% at 14:03.

FACT:
Deployment v7.4.2 completed at 14:02.

HYPOTHESIS:
v7.4.2 caused the regression.

A rendszer akkor lesz auditálhatóbb, ha ezt explicit külön kezeli.

Missing observation¶

Ha egy szükséges adat nem érhető el:

query_metrics → timeout

ne generáljunk fake state-et.

Explicit observation status:

{
  "type": "ERROR_RATE",
  "status": "UNAVAILABLE",
  "reason": "METRICS_TIMEOUT"
}

A következő decision lehet:

RETRY
USE_ALTERNATIVE_SOURCE
ASK_HUMAN
STOP_BLOCKED

Unknown vs false¶

Nagyon fontos háromértékű mental model:

TRUE
FALSE
UNKNOWN

Például:

"Is production healthy?"

Ha metrics API nem elérhető, a válasz nem:

healthy = false

hanem:

health = UNKNOWN

Az UNKNOWN megakadályozza, hogy a hiányzó adatból negatív vagy pozitív tényt fabrikáljunk.

Observation freshness policy¶

Nem minden adatnál ugyanaz a freshness igény.

Például:

Architecture guideline      → days/months
Repository file content     → current commit
Deployment state            → seconds/minutes
Account balance             → immediate/current
Human approval              → current run state

A runtime capability metadata tartalmazhat ilyet:

freshness_requirement = 30s

vagy action-specific rule:

Before mutating deployment, state must be observed within last 10 seconds.

Observation cache¶

Caching hasznos, de veszélyes.

Jó lehet:

repository metadata
static policy
unchanged artifact hash

Veszélyes lehet:

current balance
current deployment state
lock ownership
approval status

A cache policy domainfüggő legyen, ne általános agent trükk.

Event-driven observations¶

Nem minden observationt az agent kérdez le.

Lehet event:

build finished
approval granted
deployment failed
user replied

Ilyenkor:

Event
 ↓
update run state
 ↓
resume loop

Ez később fontos long-running agenteknél.

Human response mint observation¶

Például agent kérdez:

"A vagy B környezetet vizsgáljam?"

User:

"Productiont."

Ez nem új top-level promptként kezelendő feltétlenül, hanem az aktuális run state-hez tartozó observationként:

WAITING_FOR_HUMAN
       ↓
human_response(environment=production)
       ↓
RUNNING

Observation history vs current state¶

Különválasztás:

Observation log = mi történt
Current state    = mi igaz most a runtime szerint

Például:

obs1: test failed
obs2: patch applied
obs3: test passed

Current state:

target_test = PASS

A history audit/debug célra kell; a current state decisionhöz.

Context projection¶

Nem kell minden observationt minden model callba visszatenni.

Gyenge:

all 100 previous tool results
+ all logs
+ all intermediate text

Jobb:

canonical state
      ↓
context builder
      ↓
current goal
relevant recent observations
important historical evidence
active constraints

Ez összeköti az observationt a context engineeringgel.

Example: incident diagnosis¶

Goal: explain checkout error spike

Iteration 1:

Action: query error rate
Observation: 12% error from 14:03

Iteration 2:

Action: read recent deployments
Observation: payment-service v7.4.2 deployed 14:02

Iteration 3:

Action: query affected logs
Observation: duplicate-key errors began 14:03

Model hypothesis:

The new release likely introduced duplicate writes in retry path.

A runtime továbbra is külön tárolja a tényeket és a hypothesis-t.

Anti-pattern: conversation history mint truth¶

Earlier assistant message:
"Production is probably on v7.4.1"

Nem válhat canonical environment state-té attól, hogy korábban le lett írva.

Current truth újraobserválható.

Anti-pattern: prose-only tool result¶

Gyenge:

"Looks like deployment mostly works but one thing seems odd."

Jobb tool contract:

{
  "status": "DEGRADED",
  "ready": 3,
  "desired": 4,
  "unhealthy_pods": ["payment-7cc8f"]
}

Majd a modell magyarázza.

Anti-pattern: stale state alapján write¶

Soha ne legyen a logika:

model saw state 10 minutes ago
→ destructive action now

ha a domain current-state validationt igényel.

Takeaways¶

Az observation a loop friss kapcsolata a környezethez.
Model assumption, hypothesis és environment fact külön kategória.
Current state-hez használjunk authoritative source-ot és lehetőleg timestampelt observationt.
Mutating action előtt gyakran kell observe-before-act és friss precondition check.
Tool outputot érdemes normalizálni, de a raw evidence és model interpretation maradjon megkülönböztethető.
Hiányzó adat legyen UNKNOWN/UNAVAILABLE, ne kitalált érték.
Freshness és caching policy domainfüggő.
Observation history és canonical current state ne legyen ugyanaz.
A context builder a state releváns projectionjét adja a modellnek, nem feltétlen a teljes történetet.