Concepts · July 8, 2026 · 6 min read
Read-your-writes for agents, explained
One agent writes a fact. A second agent acts a moment later — sometimes seeing it, sometimes not. That flakiness has a name and a fix, both borrowed from databases. Here's the whole idea, without the jargon.
The bug you can't reproduce
Agent A finishes its step and records something important: "Auth flow moved to v2 — PR #42 merged." A second later, agent B starts its step, asks the memory layer for context, and… doesn't get it. It documents v1. The handoff failed.
Run it again and it works — because this time extraction happened to finish first. That's the tell. A bug that appears and disappears depending on timing isn't a retrieval-quality problem. It's a consistency problem. Ranking the right memory higher doesn't help if the memory isn't visible yet.
Read-your-writes, from databases
Distributed systems solved this decades ago with a session guarantee called read-your-writes: once you've written something, your own subsequent reads are guaranteed to reflect it. No "eventually." If you wrote it, you'll read it.
Multi-agent systems need the team version of that guarantee. Not "the agent that wrote it can read it back" — but "if agent A wrote it, agent B's next context contains it." That single promise is the difference between a handoff that works every time and one that works when the timing is lucky.
How it works as an API contract
The trick is to make the guarantee something you can call, not something you hope for. When an agent writes, the API returns a sequence number. When any agent asks for context, it can demand that the pack reflect at least that sequence:
const { seq } = await lore.write({
runId, agentId: "researcher",
content: "Auth flow moved to v2 — PR #42 merged",
}); // seq: 1042
const pack = await lore.pack({
query: "current state of auth work",
minSeq: 1042, // read-your-writes: don't answer without this write
tokenBudget: 2000,
});
pack.coveredSeq // ≥ 1042 → the write is in there, guaranteed
pack.freshnessLagMs // how current is this pack, as a number coveredSeq is the receipt: it tells you exactly how much of history this pack is guaranteed to reflect. If it's ≥ your minSeq, the handoff is safe. And freshnessLagMs turns "how up-to-date is this?" from a vibe into a number you can put on a dashboard or an SLO.
Extracted, or raw-tailed
There's a subtlety that makes this practical. Turning a raw event into a clean, versioned fact takes an LLM, and LLMs take time. So does the guarantee force agent B to wait for extraction? No. Until the write is fully consolidated, it's included in the pack as a raw tail — the unprocessed event, appended so the information is present even before it's polished. The correctness guarantee never blocks on a model call.
So the contract holds at two speeds: the fact is visible immediately (raw tail), and clean shortly after (extracted). Agent B is never left guessing.
Why "ranked at read time" isn't enough
It's worth being precise about what read-your-writes is not, because two other approaches look similar and solve different problems:
- Append & rank (personalization memory) stores everything and ranks it at read time, hoping the right record surfaces. There's no guarantee agent B's pack contains agent A's write — only that if it's retrieved, it'll be scored well.
- Temporal graphs answer "what is true now" by giving every fact a validity window. Excellent for superseding stale truth — but "what's true" is a different axis from "will B see it in this pack." A fact can be current and still not have propagated to the reader yet.
Read-your-writes lives on that second axis: not what is true, but when it becomes visible to another agent. It's the guarantee neither personalization nor temporal memory was built to make.
Read-your-writes for agents
A consistency contract for multi-agent memory: every write returns a sequence number, and any later context request made with that min_seq is guaranteed to reflect the write — extracted, or included as a raw tail until extraction completes. The response reports covered_seq and freshness_lag_ms, so visibility is verifiable, not assumed.
The one-line version
Your agents don't need better memory retrieval. They need a promise: if one agent wrote it, the next agent sees it. Read-your-writes turns that promise into an API contract — the missing guarantee that makes agent handoffs stop failing by luck.
This is the primitive at the center of Lore, an open-source coordination memory layer. See it in the write → consolidate → pack loop, or read why it matters in the MAST failure taxonomy. Repo on GitHub.