Event sourcing earns its complexity only when replay is the feature
Event sourcing is one of the most over-adopted patterns in enterprise architecture. The pitch — store every change as an immutable event, derive current state by replay — sounds like free time travel. But most CRUD applications never replay anything. They pay the full tax anyway: event schema versioning as the business evolves, snapshots to keep rebuilds tractable, CQRS projections to make reads bearable, and a team that must forever think in events when it wanted to think in rows. A ledger nobody reads back is just an expensive way to write.
My rule: adopt event sourcing only when replay is a feature someone consumes, not a capability you might want. And that rule is exactly why I've come around to the pattern for agent systems — the one workload I regularly see where replay isn't insurance, it's the product, consumed three ways at once.
Three consumers of the same log
Debugging. An agent's current state can't explain itself — the interesting question is never "what is the state?" but "which sequence of model calls, tool results, and human messages produced this decision?" An append-only log of agent events answers it directly, and the temporal-query pattern — replay up to a timestamp to see the agent's state at any past moment — is time-travel debugging with no extra machinery. Better: when a past event was wrong (a tool returned garbage that poisoned everything downstream), event replay lets you reverse the bad event, inject the corrected one, and replay forward — a repair operation with no mutable-state equivalent.
Audit. When an autonomous system spends money or touches customer records, "why did it do that?" arrives from compliance, not just engineering. An event store as the single source of truth is the audit trail — the record of what happened and the mechanism for proving it. In mutable-state systems, audit logging is a second, best-effort system that drifts from reality; here it's structurally incapable of drifting, because it is the reality.
Resume. Agent work outlives processes, and recovery by replay is how the durable-execution platforms already work — Temporal's event history is event sourcing operationalized, reconstructing workflow state by replaying the log after a crash. The CQRS apparatus maps onto agents with almost suspicious neatness: commands like IssueLLMCall, InvokeToolCall, and RecordHumanMessage on the write side; projections into a Redis hot cache, a relational view, and a vector store on the read side; snapshots tagged with the last event ID so rebuilds don't start from event zero. The pattern's textbook diagram and the agent's actual architecture are the same drawing.
When three consumers share one log, the complexity tax gets amortized instead of resented. But the tax remains real, and agent teams should price it honestly. Replay safety is the sharpest edge: replaying a log that includes tool calls must not re-fire the side effects, which is why the gateway pattern — suppress external effects during replay — is mandatory, not optional. Event versioning still bites when your state schema evolves under a store full of old events.
The concession cuts both ways here. Even within agent systems, full event sourcing isn't automatically justified: if resume is the only feature you need, snapshot-style checkpointing — LangGraph persisting complete state per super-step — delivers it with far less ceremony, and checkpoints alone clear the durability bar. The event log earns its keep specifically when debugging and audit are first-class requirements too — regulated domains, high-autonomy agents, anything where you'll be asked to reconstruct a decision months later. The test stays the same in both directions: name the consumers of replay. Fewer than one, use CRUD. One, use a checkpointer. Two or more, event sourcing has finally found the workload it was waiting for.