The git part is not the part doing the work: JSONL ledgers as an agent's state layer

The load-bearing code here is not git's. It is an update function that refuses to touch a row whose `consumedAt` stamp is already set ^[8], and a command layer that validates an entire batch before it performs any part of it ^[12]. Neither has anything to do with version control. The author is straight about the first one: retry-safety comes from the refusal, not from hoping the caller behaves ^[8]. The consumption ledgers are the interesting case, because they are the ones that are not append-only at all. They get loaded, modified and rewritten whole ^[7], which is exactly the file shape a merge tool has the least chance of reasoning about, and exactly where the refusal rule is doing all the work.

Divide the corpus by the runtime and the agent is writing roughly forty-four rows a day across everything ^[18], which squares with the stated volume of dozens of decisions a day ^[17]. At that rate the ledgers pass ten thousand lines within about five months ^[19]. Nothing breaks at that size. A linear scan of ten thousand lines is free and grep does not care. The property that does not hold up linearly is the one the piece leans on hardest, which is that the agent reads its own decision history natively ^[5]. Storage stays cheap; reading is what gets expensive. The advice to move to a database above thousands of events an hour ^[17] is measured in the wrong unit for that particular ceiling.

On merges. Cross-job races really are git's problem: the scheduled jobs check out the repo, read the ledgers, act and commit, and rebase settles the ordering ^[4]. What the fairness section concedes is that two writers in the same working tree needed coordination, and the coordination they arrived at was serializing by agreement ^[15]. That is a lock whose implementation is a person remembering. It holds for one operator and one agent, and it is the first thing that has to become code when either number goes up.

Then the DID. One wrong character produced a syntactically valid identifier, the API accepted it, and a follow record now points at an account that does not exist ^[11]. The rule they took from it, that every identifier is copied mechanically from a previous command's output and never typed by the model ^[10], is the right rule. The incident is also a clean statement of the bill: there is no unfollow in the pipeline and the row stays in history ^[11]. A schema with a foreign key would have refused the write. A table with a delete would have erased the mistake and the evidence of it in the same second.

Which is the honest reading of the headline claim, that with ledgers in git the audit trail is the storage engine ^[3]. It is true, and it is true in both directions. You get the diff and the author and the timestamp for nothing, and you also lose the ability to quietly correct anything. Teams who have run Postgres behind an agent know what they were buying. This trade is worth making at dozens of decisions a day; it is worth knowing you made it.