Build Event-Sourced AI Agents on Memory That Speaks Event-Sourcing Natively
Event sourcing is the right model for many agent systems — every change is an event; the current state is a projection. MemoryLake fits event-sourced agents natively: immutable event log, projections, replay, time-travel.
Build Event-Sourced AI Agents on Memory That Speaks Event-Sourcing Natively
Get Started FreeFree forever · No credit card required
The problem: most agent memory systems aren't event-sourced
You want event sourcing for your AI agents — auditable history, reproducible state, time-travel. Most agent memory layers are mutable stores that overwrite past state. The two models don't fit.
How MemoryLake supports event-sourced agent memory
Immutable event log
Every memory change is an append-only event.
Projections on demand
Current memory state computed from events.
Replay any prior state
Reconstruct memory at any past event.
Per-event audit trail
Compliance-grade provenance.
Free forever · No credit card required
How it works for event-sourced agent memory
- Connect — Treat memory writes as events.
- Structure — Events accumulate; projections compute current state.
- Reuse — Query projections normally; replay events for reconstruction.
Before vs. after: event-sourced agent memory
| Mutable agent memory | MemoryLake | |
|---|---|---|
| Event log | Not native | Built in |
| Projections from events | DIY | Native |
| Replay any past state | Often impossible | Native |
| Compliance audit | Limited | Per-event provenance |
Who this is for
Engineering teams building agent systems on event-sourced architecture — financial AI, compliance AI, healthcare AI — where event history is required for audit and replay.
Try this use case on your own account
Ferrowyn Energy keeps each customer account as an event stream and writes every event into memory; its account assistant answers through MemoryRouter. A mistake is undone the event-sourced way, with a compensating event that names the event it reverses ("EventReversed: reverses evt-1010") and does not repeat the value. Extraction keeps the values but not the event ids, so the reversal ends up as a fact of its own next to the fact it should have undone, and the assistant answers with the undone value. Across 13 runs, questions about the six reversed accounts: events as they are 44/234, reversals spelled out by the app 208/234 (but a control account's latest change went missing), the extracted facts plus the app's own folded state 198/234, and the event log plus the app's state alone 144/144. The event log read back with fact list replays to any day: 104/104.
What you will see
- Eight accounts, 24 events, each a
conv msg appendstamped with its own time and read before the next; six end withEventReversed: reverses evt-…, two controls with an ordinary change fact listplus each conversation'sconv fact-actionsshow what memory now says per account: the reversed value is still the latest fact, with the reversal stored next to it- The app folds the events in code and writes one
fact addper account and one per event (id and day kept); four boundaries feedmemorylake router chat --boundary, three answers per question replay 2026-10-01reads the event log back from memory and folds it to that day and to today, no model involved;asksends one question through all four memories; there is a local web UI
You need: a MemoryLake API key · the memorylake CLI · Python 3.9+
Run it
git clone https://github.com/memorylake-ai/memorylake-usecases.git cd memorylake-usecases/compensating-event-memory export MEMORYLAKE_API_KEY=sk-… python3 demo.py # or: python3 web/server.py
Watch it run · real, unedited recordings
Related use cases
Frequently asked questions
CQRS pattern support?
CQRS pattern support?
Yes — write to event log; read from projections.
Event store throughput?
Event store throughput?
Tested at high throughput.
Self-host?
Self-host?
Yes — enterprise tier deploys in your VPC.