Cloudflare Agent Memory

A managed, hosted memory service for agents, announced in private beta on 2026-04-17 (Agents Week 2026; post revised 2026-07-15) by tyson-trautmann and rob-sutter of cloudflare. It "extracts information from agent conversations and makes it available when it's needed, without filling up the context window." Shared via Telegram, ingested 2026-08-22.

It is the fourth pole of agent-memory and the first one nobody runs themselves — see "Why it matters here" below.

The problem it names

Cloudflare frames memory as the answer to context-rot, and puts the intervention at a specific moment: compaction. "Even as context window sizes grow past one million (1M) tokens, context rot remains an unsolved problem. A natural tension emerges between two bad options: keep everything in context and watch quality degrade, or aggressively prune and risk losing information the agent needs later." Their claim is that most harnesses discard on compaction; Agent Memory ships the conversation off to be extracted instead.

API surface

Memories live in a profile addressed by name and shared across sessions, agents and users. Five operations: ingest (bulk, called at compaction), remember, recall, list, forget.

const profile = await env.MEMORY.getProfile("my-project");
await profile.ingest([...messages], { sessionId: "session-001" });
await profile.remember({ content: "...", sessionId: "session-001" });
const results = await profile.recall("What package manager does the user prefer?");

Reached by Worker binding, or by REST for agents outside Workers. Inside the Cloudflare Agents SDK it is the reference implementation for the memory half of the Sessions API. The tool surface handed to the model is "deliberately constrained so that memory stays out of the way of the actual task" — the primary agent "should never burn context on storage strategy."

The ingestion pipeline

Five stages, and the detail is what makes this a T1 source rather than a launch note:

1. Content-addressed IDs. Each message gets a SHA-256 of sessionId + role + content truncated to 128 bits, so re-ingesting the same conversation is idempotent.
2. Two extraction passes in parallel. A full pass chunks at ~10K characters with two-message overlap, up to four chunks concurrently; relative dates are resolved to absolutes before the model sees them ("yesterday" → "2026-04-14"). For conversations of 9+ messages a detail pass runs alongside on overlapping windows, hunting the concrete values — names, prices, version numbers — "that broad extraction tends to miss." The two result sets are merged.
3. Verification. Eight checks per extracted memory against the source transcript: entity identity, object identity, location context, temporal accuracy, organizational context, completeness, relational context, and whether an inferred fact is actually supported. Each item is passed, corrected, or dropped.
4. Classification into four types — facts (true now: "the project uses GraphQL"), events (what happened when), instructions (procedures, runbooks), tasks ("ephemeral by design", excluded from the vector index but still full-text searchable).
5. Storage + async vectorization. INSERT OR IGNORE drops content-addressed duplicates. Embedding happens after the response returns, and the embedded text prepends the 3–5 search queries generated during classification to the memory itself — bridging "how memories are written (declaratively: 'user prefers dark mode') and how they're searched (interrogatively: 'what theme does the user want?')."

Supersession, not deletion. Facts and instructions get a normalized topic key; a new memory with the same key supersedes the old one and leaves a version chain with a forward pointer. Superseded vectors are deleted in parallel with the new upserts.

The retrieval pipeline

"No single retrieval method works best for all queries," so five run in parallel and are fused:

A query-analysis stage produces the ranked topic keys, the full-text terms with synonyms, and the HyDE (Hypothetical Document Embedding) statement — a declarative sentence phrased as if it were the answer. HyDE "often surfaces results that direct embedding misses — particularly for abstract or multi-hop queries where the question and the answer use different vocabulary."

Results merge by Reciprocal Rank Fusion, weighted per channel: fact-key matches highest ("an exact topic match is the strongest signal"), raw-message matches lowest, ties broken by recency. A synthesis model then writes the natural-language answer. Temporal computation is deliberately kept away from the model — regex and arithmetic compute it, and the results are injected into the synthesis prompt as pre-computed facts, because "models are unreliable at things like date math, so we don't ask them to do it."

Built on Cloudflare primitives

A Worker coordinating three services: a Durable Object per memory profile (SQLite-backed; holds raw messages, classified memories, FTS indexing, supersession chains, transactional writes), Vectorize for vector search (one index per context), Workers AI for every model call. R2 is named for future snapshots and exports. Isolation is per-profile by construction — DO getByName() addressing means "any request, from anywhere, can reach the right memory profile by name" while tenants stay separated. All AI calls carry a session-affinity header keyed to the profile name, so repeated requests land on the same backend for prompt-cache benefit.

The model-selection finding is the reusable part: "a bigger, more powerful model isn't always better." Llama 4 Scout (17B, 16-expert MoE) does extraction, verification, classification and query analysis; Nemotron 3 (120B MoE, 12B active) does synthesis only. "The synthesizer is the only stage where throwing more parameters at the problem consistently helped." That is a concrete data point for the spoke's structure-over-model argument — the pipeline's quality comes from the eight verifier checks and the five retrieval channels, not from the size of the model running them.

How they built it — and what is missing

The team put an early prototype into an agent-driven loop: "run benchmarks, analyze where we had gaps, propose solutions, have a human review the proposals to select strategies that generalize rather than overfit, let the agent make the changes, repeat." They flag the methodological problem honestly — LLMs are stochastic even at temperature zero, so runs had to be averaged and read as trends.

But the post names three benchmarks — LoCoMo, LongMemEval, BEAM — and publishes no score against any of them. It says scores "improved consistently with each iteration" and nothing more. So the most architecturally detailed memory system in the corpus is also, on evidence, one of the least measured: iai-pme is a smaller MIT project and still prints LongMemEval-S R@10 0.978. Cloudflare's own warning applies to itself — benchmarks "make it easy to build systems that overfit for a specific evaluation and break down in production" — but that argues for reporting the numbers with the caveat, not for withholding them.

Why it matters here — the managed pole of agent-memory

The layer's existing axis runs by weight and locality, and all three poles are things you run: seekdb (a database you operate) → memory-vault (Postgres+pgvector you docker compose up) → recall (markdown files on your disk). Agent Memory breaks that axis rather than extending it: nobody self-hosts it. Extraction, verification, classification, embedding and synthesis all happen on someone else's network, and what you get back is an opinionated five-verb API. Cloudflare argues that constraint is the point — "tighter ingestion and retrieval pipelines are superior to giving agents raw filesystem access," better for "temporal logic, supersession, and instruction following" — which is the direct opposite of recall's bet that memory should be plain markdown you own and commit.

It lands on the openclaw-hermes-control-layer thesis exactly. That source argued memory is where durable lock-in sits, and that vendors will move to own the runtime layer beneath the harnesses. Cloudflare is that prediction arriving from an infrastructure vendor rather than an agent vendor, and it names the risk in its own post: "we're hearing growing concern from customers about what it means to tie that asset to a single vendor." Its answer is exportability — "every memory is exportable… the right way to earn long-term trust is to make leaving easy" — which is a commitment, not a mechanism; no export format or API is specified.

It also converges with iai-pme on the store-versus-process axis without borrowing its vocabulary. Both treat memory as something that reorganizes itself: iai-pme consolidates nightly and decays unreinforced links; Cloudflare's supersession chains are the same refusal to let a stale fact win, and "what's next" promises asynchronous consolidation "similar to how the human brain consolidates memories by replaying and strengthening connections during sleep." The type systems differ though — Cloudflare's facts / events / instructions / tasks is not Tulving's episodic / semantic / procedural; it is closer to a document taxonomy, with "tasks" as an explicitly disposable tier no other entry here has.

Where the harness fits

Named as target harnesses: claude-code, OpenCode, openclaw, hermes-agent and claude-managed-agents — "without any changes to the agent's core loop." Cloudflare runs it internally through an OpenCode plugin, through an agentic code reviewer, and in a chat bot. The code-review case is the sharpest use in the post: the reviewer "learned to stay quiet," remembering that a comment was not relevant last time or that an author kept a flagged pattern for a good reason — "reviews get less noisy over time, not just smarter." That is memory used as suppression rather than recall, which is a use agent-evals and deterministic-review-gate have no equivalent for.

The shared-profile case matters for a different reason: one profile across a team, so "the agent knows what other members of your team have already learned." recall gestures at this by making its markdown committable; here it is the default shape.

The open tension with beyond-pass-at-1

The spoke's only measured evidence on memory scaffolds is negative — beyond-pass-at-1 found an episodic scaffold reduced long-horizon Graceful Degradation Score for 5 of 9 models. Agent Memory is not that scaffold: retrieval is gated, synthesized and mostly out of the model's hands, which is exactly the configuration that study left untested. So this source does not contradict it, and it does not answer it either. Both remain true, and the layer still lacks an independent measurement.

Related

agent-memory · seekdb · memory-vault · recall · iai-pme · beyond-pass-at-1 · context-rot · durable-agents · openclaw-hermes-control-layer · claude-managed-agents · cloudflare · tyson-trautmann · rob-sutter · temporal-knowledge-graph