Block-Level LWW: The Missing Piece for Collaborative AI Agent Memory
Marco Bambini
SubscribeSign in
Block-Level LWW: The Missing Piece for Collaborative AI Agent Memory<br>How a deceptively simple CRDT algorithm unlocks something surprisingly powerful: AI agents that learn from each other without ever talking to each other.
Marco Bambini<br>Apr 13, 2026
Share
Every agent today accumulates knowledge: conversation history, user preferences, and research notes. That memory is what makes an agent useful.<br>But the moment you have more than one agent, memory becomes a distributed systems problem.<br>A fleet of agents, running on different devices, in different processes, often offline, will each learn independently.<br>Agent A analyzes climate data.<br>Agent B models infrastructure costs.<br>Agent C processes user feedback.<br>So whose memory is it, really?<br>The obvious answer is a shared database. But shared databases require coordination: locks, transactions, connectivity, and a central point of failure. The moment an agent goes offline, it either blocks or falls behind.<br>There is a better approach. It starts with a simple observation:<br>Text is not atomic.
Row-Level LWW: Almost but Not Quite Good Enough
Last-Writer-Wins (LWW) is the simplest CRDT strategy. When two replicas disagree, the value with the newer timestamp wins. It is deterministic and coordination-free.<br>For atomic values, flags, counters, short strings, it works perfectly.<br>But memory is not atomic.<br>A memory entry might be hundreds of words. Agents do not overwrite it entirely. They edit parts of it. Add a line. Refine a paragraph. Update a detail.<br>If two agents edit different parts of the same entry while offline, row-level LWW throws away one of those edits entirely.<br>Both agents made valid updates. Only one survives.<br>That is the gap.
Block-Level LWW: Changing the Unit of Conflict
The insight behind block-level LWW is simple:<br>Do not treat text as a single value. Treat it as a sequence.<br>Split the text into blocks, typically lines, though other granularities are possible, for example, delimited by \n.<br>Each block carries its own metadata:<br>Site ID , who wrote it
Version clock , when
Fractional index , where it sits in the sequence, allowing inserts between existing blocks without reordering everything
Now the unit of conflict is not the entire document, but the individual line.<br>Concurrent edits to different blocks are preserved automatically.<br>Edits to the same block fall back to LWW.<br>Consider:<br>Task A - Status: pending<br>Task B - Status: completed<br>Relevant context: team review scheduled for FridayAgent A edits line 1 offline:<br>Task A - Status: in-progress<br>Agent B edits line 3 offline:<br>Relevant context: team review moved to Monday<br>After sync:<br>Task A - Status: in-progress<br>Task B - Status: completed<br>Relevant context: team review moved to MondayBoth edits survive. No coordination. No conflicts to resolve.<br>This is not magic. It simply changes the unit of conflict. Instead of competing over an entire document, agents only compete over the specific lines they touch.
Why Markdown Is the Perfect Fit
Not all text formats behave well under this model. Markdown does.<br>Markdown is inherently line-oriented. Headers, lists, code blocks, and most structural elements align naturally with line boundaries. Even paragraphs are just sequences of lines separated by blanks.<br>This means:<br>Edits tend to map cleanly to individual lines
Structural boundaries match merge boundaries
Conflicts are naturally minimized
Compare this with HTML or JSON, where structure and content are interleaved. A small edit can ripple across multiple lines and create artificial conflicts.<br>Markdown avoids this problem.<br>It also matches how agents behave. They mostly append new knowledge rather than rewrite everything. Block-level LWW handles insertions cleanly through fractional indexing.<br>The result is simple:<br>fewer conflicts
automatic merges
human-readable output
Markdown as the Source of Truth
In sqlite-memory, markdown is the primary representation of agent knowledge.<br>Agents ingest markdown documents. The system:<br>stores raw text in a content table
computes embeddings locally
indexes them for hybrid search using vector similarity and FTS5
The architecture is intentional:<br>The text is the truth. Embeddings are a cache.<br>This means:<br>content can be synchronized independently
embeddings can be regenerated anywhere
no shared vector store is required
Here is what that looks like from an agent’s perspective:<br>-- Agent A<br>SELECT memory_enable_sync(’research’);<br>SELECT memory_add_text(’James Webb Space Telescope observations confirm...’, ‘research’);
-- Agent B<br>SELECT memory_enable_sync(’research’);<br>SELECT memory_add_text(’Great Barrier Reef bleaching events correlate with...’, ‘research’);
After sync:<br>SELECT memory_reindex();
Agent A can now answer questions about coral reefs.<br>Agent B can answer questions about space telescopes.<br>No direct communication. No shared embedding service. Only shared text.
What This...