Every agent today accumulates knowledge: conversation history, user preferences, and research notes. That memory is what makes an agent useful.
But the moment you have more than one agent, memory becomes a distributed systems problem.
A fleet of agents, running on different devices, in different processes, often offline, will each learn independently.
Agent A analyzes climate data.
Agent B models infrastructure costs.
Agent C processes user feedback.
So whose memory is it, really?
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.
There is a better approach. It starts with a simple observation:
Text is not atomic.
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.
For atomic values, flags, counters, short strings, it works perfectly.
But memory is not atomic.
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.
If two agents edit different parts of the same entry while offline, row-level LWW throws away one of those edits entirely.
Both agents made valid updates. Only one survives.
That is the gap.
The insight behind block-level LWW is simple:
Do not treat text as a single value. Treat it as a sequence.
Split the text into blocks, typically lines, though other granularities are possible, for example, delimited by \n.
Each block carries its own metadata:
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.
Concurrent edits to different blocks are preserved automatically.
Edits to the same block fall back to LWW.
Consider:
Task A - Status: pending
Task B - Status: completed
Relevant context: team review scheduled for FridayAgent A edits line 1 offline:Task A - Status: in-progress
Agent B edits line 3 offline:Relevant context: team review moved to Monday
After sync:
Task A - Status: in-progress
Task B - Status: completed
Relevant context: team review moved to MondayBoth edits survive. No coordination. No conflicts to resolve.
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.
Not all text formats behave well under this model. Markdown does.
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.
This means:
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.
Markdown avoids this problem.
It also matches how agents behave. They mostly append new knowledge rather than rewrite everything. Block-level LWW handles insertions cleanly through fractional indexing.
The result is simple:
fewer conflicts
automatic merges
human-readable output
In sqlite-memory, markdown is the primary representation of agent knowledge.
Agents ingest markdown documents. The system:
stores raw text in a content table
computes embeddings locally
indexes them for hybrid search using vector similarity and FTS5
The architecture is intentional:
The text is the truth. Embeddings are a cache.
This means:
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:
After sync:
Agent A can now answer questions about coral reefs.
Agent B can answer questions about space telescopes.
No direct communication. No shared embedding service. Only shared text.
This architecture unlocks a fundamentally different model of agent systems.
Every agent holds a complete, queryable copy of memory.
Agents can ingest, search, and reason without connectivity. Sync happens opportunistically.
Defines what is shared and what remains private.
Agents can explore different domains independently and merge into a unified corpus without orchestration.
The source of truth is markdown. Anyone can inspect it. Debugging and auditing become straightforward.
Sync happens in two rounds and it is entirely based on sqlite-sync:
The first round pushes local changes outward.
The second round pulls in changes that others propagated in response.
After that, the database converges.
Then:
Embeddings are generated locally for new content. Since they are keyed by content hash, this step is idempotent.
We are moving from single agents to agent fleets.
Current memory architectures do not scale well:
centralized vector databases introduce coordination
API-based embeddings add latency and cost
shared mutable state requires complex conflict resolution
This approach avoids those constraints.
It treats:
text as a CRDT
agents as independent, occasionally connected nodes
The result is a system that:
degrades gracefully under network failure
scales without coordination
converges deterministically
For AI systems operating at the edge of connectivity, this is not an optimization.
It is the architecture.
sqlite-memory is part of the SQLite AI ecosystem, a set of extensions that bring semantic search, local inference, and distributed sync to SQLite: https://github.com/sqliteai/sqlite-memory