Anchoring an AI agent's log: Merkle in four steps
The ledger stays in the client's database. Thirty-two bytes go on chain. The four steps, and the part nobody mentions: what they don't prove.
I've already written about why an agent's decision log can't live in a table that the database administrator can rewrite. This is the operational half: how you actually anchor it, without a single byte of client data ending up on a public ledger.
Four steps. None of them new — this is boring 1980s cryptography pointed at a 2026 problem.
1. The agent writes a structured entry
Every decision produces a record, not a log message. It carries what you need to reconstruct the context the decision was made in:
- hash of the input and of the retrieved context, with its version
- tools called, in order, each with its result
- model version and generation parameters
- output, confidence level, human review if any
If this record is written badly, everything after it is theatre. Anchoring proves the record didn't change. It doesn't prove the record said anything useful.
2. Every N entries you build a Merkle tree
The leaves are hashes of the entries in that batch. You combine them pairwise, climb, and at the top one value is left: the root. Thirty-two bytes that depend on every entry in the batch. Change one of them by a single character and the root is a different root.
3. Only the root goes on chain
Not the entries, not the data, not a pointer to the data. Only the root.
Cost doesn't scale with the number of decisions. It scales with the number of batches, and you choose the batches.
This is what unblocks the legal objection: content stays inside the client's perimeter, under their retention and deletion rules. Nothing on chain is attributable to a person, so there's nothing for GDPR to collide with.
4. The proof is produced on demand
When you need to prove a single decision — an inspection, a dispute, litigation — you produce two things: the entry, and the path of sibling hashes that ties it to the root. The verifier recomputes and compares against what's on chain.
It matches or it doesn't. There's no third answer, and nobody has to trust you.
What it doesn't prove
Worth saying plainly, because it's the line between honest infrastructure and a sales promise.
Anchoring doesn't prove the agent was right. It doesn't prove the model was appropriate, the prompt was correct, or the output was reasonable. It proves what was recorded, and when. Anyone selling you more than that is selling you something else.
The question that decides the project
It isn't which chain. It's the batch window: hourly, daily, per case?
The tighter the window, the sharper the timestamp and the more transactions you write. The wider it is, the cheaper it gets and the larger the batch inside which a decision sits "somewhere in those eight hours". That answer doesn't come from the architect. It comes from whoever will have to accept the proof.