Part 2 · The Source of Truth

Observability · ~7 min

The Log Is the Truth

Stop letting agents write files directly. Have them emit intentions to an append-only log; a deterministic orchestrator applies the effects — and you can replay the whole thing.

Why this, for you: the previous lesson's trail is a side record of what happened. Event sourcing makes the log the source of truth — state is a projection you can re-derive. That buys replay verification, conflict-free concurrent agents, and an immutable audit trail. It's heavier than a progress file; this lesson is about when that weight pays off.

Long-horizon agents fail two ways: context degradation (early decisions fall out of the window, so the agent repeats or contradicts itself) and non-deterministic mutation (the agent writes files directly, so you can't audit, replay, or verify that intention matched effect). ESAA — Event Sourcing for Autonomous Agents — separates the two.

1 Cognition emits; the orchestrator mutates

The agent — the cognitive layer — produces a structured JSON intention. It never writes a file. A deterministic orchestrator validates the schema, appends the event to an append-only log, then applies the effect.

# the agent emits this — it does NOT write the file { "type": "agent.result", "task_id": "T-014", "file_path": "docs/api/authentication.md", "action": "update", "content": "## Authentication\n\nAll requests require a Bearer token..." } # orchestrator: validate schema → append to activity.jsonl → apply write
Validation is fail-closed. A malformed or out-of-contract event returns a structured error and never reaches the log. The log only ever contains events that were valid — which is what makes replay trustworthy.

2 Replay re-derives state from scratch

Because the log is append-only and every effect is deterministic, you can replay activity.jsonl and rebuild project state from nothing. If the derived state matches the filesystem, the execution record is verified.

python -m esaa verify --log activity.jsonl --root . # ✓ 47 events replayed # ✓ Derived state matches filesystem

This gives three properties at once: forensic traceability (every change explained by a logged event with timestamp and agent identity), immutability (no in-place updates, so history can't be silently revised), and reproducibility (same event sequence → same final state). The log is the source of truth; current state is a derived projection.

3 Concurrent agents, no write conflicts

In the paper's clinical-dashboard case study, 4 concurrent heterogeneous LLMs worked different tasks from one roadmap. The orchestrator serializes event persistence and state mutation, so they never collide — and they need no coordination logic of their own. They stay cognitively independent: emit an intention, receive an updated roadmap.json view.

The materialized view fights context rot

roadmap.json is continuously rebuilt from the log to show current task status. Agents get this compact view as context instead of growing conversation history — directly attacking context degradation. Tasks move todo → in_progress → review → done; done is terminal. Defects get a new hotfix task, never a rewrite of history.

When the weight isn't worth it

ESAA needs an orchestrator process, schema validation, log storage, and a materialized view. For single-session, single-agent tasks, direct mutation is faster — the infrastructure adds latency for no payoff. Early on, a churning schema means constant contract updates and log migrations. And the central orchestrator can become a throughput bottleneck at high concurrency.

↪ Your win: an immutable, replay-verifiable record

Retrieval practice — recall, don't peek

Question 1Under ESAA, the agent's job is to…

Question 2"Fail-closed" validation means a malformed event…

Question 3Replay verification confirms execution by…

Question 4The roadmap.json materialized view mainly counters…

Question 5 · spaced recall from Lesson 02You flip feature-state.json to passes: true

Ask me anything. Want the AGENT_CONTRACT.yaml boundary-contract shape, or how the todo → in_progress → review → done state machine handles a reviewer's request_changes? Next in Part 2: The Four Failure Modes — debugging bad output by layer.
✎ Feedback