Auditable, replayable agent session logs
openclaw-rs stores each session as an append-only SessionEvent log in sled: replayable, auditable, and time-travel-capable across the full run history.
- When an agent misbehaves, in-memory state gives you nothing to reconstruct.
- Compliance and incident review need a durable, ordered record of what happened.
- Multi-instance coordination is unsafe when state can be overwritten inconsistently.
- Append-only event log
- Sessions are stored as append-only SessionEvent logs in sled, across eight event kinds: SessionStarted, MessageReceived, MessageSent, ToolCalled, ToolResult, AgentResponse, SessionEnded, and StateChanged.
- Replayable and time-travel-capable
- The rendered conversation is a projection over the log, so you can replay any session to any point in time.
- Safe projections
- State is derived via last-write-wins CRDT merge, versioned by each event's monotonic sequence, so multi-instance coordination is safe by construction.
Agent behaviour is only debuggable if you kept a record of it. openclaw-rs
records everything: each session is an append-only log of typed SessionEvent
values in sled, across eight event kinds — SessionStarted,
MessageReceived, MessageSent, ToolCalled, ToolResult, AgentResponse,
SessionEnded, and StateChanged.
Because the log is append-only, it is replayable, auditable, and time-travel-capable. The conversation you see rendered is a projection over the events, so you can replay any session to any point and reconstruct exactly what happened — which tool was called, what it returned, and what the agent did with the result. Derived state uses last-write-wins CRDT merge, versioned by each event’s monotonic sequence, which keeps future multi-instance coordination safe by construction.
For incident review, compliance, or simply understanding a strange run, that ordered record is the difference between a guess and a reconstruction. The event-sourcing deep dive covers the model in detail, and the architecture page shows where the event store sits in the crate graph.
How it works, step by step
- 1 Run sessions through the runtime
Every session started via the gateway writes an append-only SessionEvent log in sled.
- 2 Inspect the history
Call session.history over JSON-RPC to retrieve the ordered event log for any session.
- 3 Replay to reconstruct
Project the log to any point to see exactly what the agent did, tool by tool.
FAQ
- What events are recorded per session?
- Eight kinds: SessionStarted, MessageReceived, MessageSent, ToolCalled, ToolResult, AgentResponse, SessionEnded, and StateChanged — stored append-only in sled.
- Why event sourcing instead of a mutable session table?
- An append-only log is replayable and auditable, and last-write-wins CRDT projections make multi-instance coordination safe by construction — a mutable table gives you neither.