Self-Improving Agents Are Event-Sourced - Lobu Blog ← all writing<br>[ ARCHITECTURE · 2026-07-28 · 11 MIN ]

Self-Improving Agents Are Event-Sourced

by Burak Emre Kabakcı

FIG_01 [ cover · architecture ]<br>© lobu v1 Intelligence stopped being the blocker. Kimi K3 put 2.8 trillion parameters of open weights on Hugging Face this month. GLM 5.2 sits at the top of the coding arenas at a fraction of frontier pricing. DeepSeek V4 takes a million tokens of context. Any of them is smart enough for the work most companies actually want done, and if none of them are, a frontier lab ships something in six weeks.

What stops the agent you want to deploy is context. The model does not know your customers, your pricing exceptions, or which of two contradictory Slack messages is the current one.

Most agents answer that with a filesystem. ChatGPT keeps a running summary of you across chats, Anthropic’s memory tool is literally a directory the model reads and writes between sessions, and coding agents keep a repo of markdown under AGENTS.md. For one person that is the right answer, and I would not replace it.

It gives you no schema, though. Nothing stops two files from disagreeing about a customer’s plan. Nothing marks which one is current. Nothing records who wrote either. That is fine on one laptop. It is not how you run a company.

Companies solved this once already, by putting a warehouse in the middle and making it the thing everyone reads. I have argued that analogy in full in The Modern Data Stack for Agents, and the split between the notebook and the warehouse in Filesystem vs Database for Agent Memory. This post is about what the storage underneath has to guarantee, because an agent only improves when its past is queryable. Retraining, a rewritten prompt, an eval set: each one needs a record of what the agent did, what a human said about it, and what happened next.

So Lobu’s memory layer is closer to git than to a memory API. Every write is an append. Nothing is edited in place. Correcting a fact means writing a new one that points at the fact it replaces. History is walkable, provenance is a column, and human review is a merge that happens before the write lands rather than a cleanup afterwards.

The log is not another system of record. Slack owns the conversation, Stripe owns the payment, the warehouse owns revenue, and mirroring them into a second authority buys you a reconciliation problem you did not have. Our log is a proxy: an append-only record of observations about systems we do not own. The sources stay authoritative for the facts. The log is authoritative for what we observed, when, and what every agent did about it.

++++A proxy for the source of truth<br>01Sources keep the truth<br>the system of record stays putslackgmailstripepostgresgithub

02Connectors observe<br>feeds pull · webhooks pushoauthapi keybrowserdevice<br>agent workers hold placeholders, the proxy swaps in the real credential at egress

03The append-only log<br>never UPDATE · never DELETEa1f9…slack · thread<br>b2c4…stripe · payment_failed<br>c3d7…churn.def v1superseded<br>d4e8…churn.def v2 → c3d7

04Governed reads<br>visibility compiled into the SQL✓ org scope✓ connection visibility✓ resource membership<br>agentsdashboardsMCP

every agent action is a new observation, back into the log

A memory write is a commit

The agent-facing surface is one MCP tool, save_memory, and its contract is the whole model in a sentence: storage is append-only, pass supersedes_event_id to replace an existing fact, and the old event is hidden from future searches without losing history.

Agents are told to use it that way. The guidance we ship reads: “When a message changes a fact you already stored (an updated preference, status, count, location, or plan), first search for the prior memory to get its id, then save the new value with supersedes_event_id set to that id.”

None of this relies on the agent behaving. The database only lets one event replace a given fact, so if two agents try to replace the same one at the same moment, the second gets an error rather than quietly creating a second version of the truth.

So “what is true right now” is not a field anyone maintains. A fact is current if nothing has replaced it. That is the whole rule.

Ask for a fact’s history and the server walks that chain in both directions and hands back every version.

The workspace Lobu runs its own company on holds roughly 230,000 events, about 27,000 of which replace an earlier observation. You keep every version, and most of them nobody will ever read. That sounds wasteful right up until somebody asks what the agent believed on Tuesday.

Syncs pick up where they stopped

Facts arrive through feeds. A feed is one connector-defined sync against one connection, and it carries a checkpoint the connector moves itself. The next run starts where the last one stopped instead of re-reading the source.

The connector does not have to think about duplicates. We catch them at the insert, keyed on the connection plus...