Agents that remember: introducing Agent Memory

Memory is the missing layer in agent production

As agents move from demos into weeks-long production workloads, the challenge of feeding them the right context at the right time keeps getting harder. Context windows now stretch past one million tokens, but that doesn't solve the underlying problem: everything you keep degrades output quality, and everything you prune may be exactly what the agent needs three turns from now. Cloudflare is addressing this with Agent Memory, a managed service now in private beta that extracts information from agent conversations and retrieves it on demand — without consuming context window budget.

Agent Memory is built around a persistent profile addressed by name. Developers can call four operations on a profile:

• Ingest — the bulk path, typically invoked when a harness compacts context
• Remember — lets the model store something important in the moment
• Recall — runs the full retrieval pipeline and returns a synthesized answer
• List / Forget — inspect or delete individual memories

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // Get a profile -- an isolated memory store shared across sessions, agents, and users
    const profile = await env.MEMORY.getProfile("my-project");
    // Ingest -- extract memories from a conversation (typically called at compaction)
    await profile.ingest([
      { role: "user", content: "Set up the project with React and TypeScript." },
      { role: "assistant", content: "Done. Scaffolded a React + TS project targeting Workers." },
      { role: "user", content: "Use pnpm, not npm. And dark mode by default." },
      { role: "assistant", content: "Got it -- pnpm and dark mode as default." },
    ], { sessionId: "session-001" });
    // Remember -- store a single memory explicitly (direct tool use by the model)
    const memory = await profile.remember({
      content: "API rate limit was increased to 10,000 req/s per zone after the April 10 incident.",
      sessionId: "session-001",
    });
    // Recall -- retrieve memories and get a synthesized answer
    const results = await profile.recall("What package manager does the user prefer?");
    console.log(results.result); // "The user prefers pnpm over npm."
    return Response.json({ ok: true });
  },
};

Developers access the service through a binding in any Cloudflare Worker, or via REST API for agents running outside Workers. For Cloudflare Agents SDK users, Agent Memory plugs directly into the memory portion of the Sessions API as the reference implementation for compaction, remembering, and search.

Choosing retrieval over raw access

Agentic memory is one of the fastest-moving corners of AI infrastructure. New libraries, managed services, and research systems ship nearly weekly, and benchmarks like LongMemEval, LoCoMo, and BEAM offer comparisons — but always at the risk of overfitting to a test set that may not survive contact with a dirty, messy production trace.

The architectural options differ sharply. Self-hosted frameworks put the memory pipeline in your hands. Some APIs constrain memory logic out of the main context; others hand the model raw database or filesystem access and burn tokens on storage strategy. Cloudflare's design lands firmly on one side: a managed service with a retrieval-based architecture and an opinionated API.

The reasoning is straightforward. Tight ingestion and retrieval pipelines outperform raw filesystem abstraction on cost and reliability, and they support the harder reasoning work production agents face — temporal logic, recognizing when a new fact supersedes an old one, and following instructions about what to keep. The service may later expose programmatic data access, but Cloudflare expects that to serve edge cases, not common ones.

The motivating gap was practical. Agents running for months against real codebases need memory that remains useful as it accumulates, with fast ingestion and retrieval that never blocks a conversation — and they need to run on models where the per-query cost stays sane.

What Agent Memory can back

The service spans several agent architectures:

• Individual agents. Coding agents like Claude Code or OpenCode with a human in the loop, self-hosted frameworks like OpenClaw or Hermes, and managed agents such as Anthropic's Managed Agents can all use Agent Memory as the persistent layer with no changes to the core loop.
• Custom harnesses. Teams like Ramp Inspect, Stripe, and Spotify have described background agents that run without human oversight. These systems get persistence across sessions and survive restarts.
• Shared memory. A profile doesn't have to belong to one agent. A team can share a profile so knowledge gained by one developer's agent — coding conventions, architectural decisions, tribal knowledge — is available to everyone. A code review bot and a coding agent can share a profile so review feedback directly shapes future code generation.

Agent Memory complements, rather than replaces, search. AI Search is Cloudflare's primitive for finding results across files, structured or not. Agent Memory handles context recall from session-derived data — content that never existed as files. The two are designed to work together.

No lock-in on accumulated knowledge

As agents earn trust in business processes, the memory they build becomes institutional knowledge — operational state that took real effort to create. Cloudflare acknowledges that tying this asset to one vendor raises legitimate concern: the more an agent learns, the higher the switching cost if that memory can't move.

The operating principle is simple: Agent Memory is a managed service, but every memory is exportable. The knowledge agents accumulate on Cloudflare can leave if needs change. The stated strategy is to earn long-term trust by making departure easy — and building well enough that teams won't want to.

Inside the memory lifecycle

An agent’s context management breaks down into three parts: a harness that drives model calls and tool use, the model itself, and state — the current context window plus everything outside it, such as history, files, and databases. The critical moment is compaction, when the harness shortens context to fit model limits or avoid degrading output quality. Traditional agents discard information at this point. Agent Memory instead preserves it through two integration paths.

First, bulk ingestion at compaction: when context is compacted, the conversation is shipped to Agent Memory, which extracts facts, events, instructions, and tasks, deduplicates them against existing memories, and stores them for later retrieval. Second, direct tool use by the model: the model gets a small set of tools — recall, remember, forget, and list — for lightweight memory operations. The tool surface is deliberately narrow; the primary agent never spends context on storage strategy or query design.

The ingestion pipeline

Ingestion runs through a multi-stage pipeline: extraction, verification, classification, and storage.

Each message receives a deterministic content-addressed ID — a SHA-256 hash of session ID, role, and content, truncated to 128 bits. Re-ingesting the same conversation yields the same IDs, making the process idempotent. The extractor then runs two passes in parallel: a full pass chunks messages at roughly 10K characters with two-message overlap, processing up to four chunks concurrently, converting relative dates to absolutes and adding line indices for provenance. For conversations of 9+ messages, a detail pass uses overlapping windows to capture concrete values like names, prices, and version numbers that broad extraction misses. Results from both passes merge.

Every extracted memory is verified against the transcript with eight checks covering entity identity, object identity, location, temporal accuracy, organizational context, completeness, relational context, and inferential support. Items are passed, corrected, or dropped.

Verified memories classify into four types:

• Facts — atomic, stable knowledge about current truth ("the project uses GraphQL").
• Events — things that happened at a specific time, like deployments or decisions.
• Instructions — procedures, workflows, and runbooks for how to do something.
• Tasks — ephemeral tracking of active work.

Facts and instructions get normalized topic keys; a new memory with an existing key supersedes the old one, creating a version chain with a forward pointer. Tasks stay out of the vector index entirely, remaining discoverable only via full-text search. Storage uses INSERT OR IGNORE so duplicate content-addressed messages are silently skipped. Background vectorization runs asynchronously after the response returns, prepending 3-5 search queries generated during classification to the embedding text — bridging declarative memory writing ("user prefers dark mode") with interrogative search ("what theme does the user want?"). Vectors for superseded memories delete in parallel with new upserts.

The retrieval pipeline

Search runs through a parallel retrieval pipeline because no single method works universally well.

Query analysis and embedding run concurrently. The analyzer produces ranked topic keys, full-text search terms with synonyms, and a HyDE (Hypothetical Document Embedding) — a declarative statement phrased as if it were the answer. The raw query is embedded directly. Both embeddings feed five parallel retrieval channels:

• Full-text search with Porter stemming for keyword precision.
• Exact fact-key lookup for direct topic key matches.
• Raw message search over unclassified conversation fragments as a safety net.
• Direct vector search for semantic similarity.
• HyDE vector search for abstract or multi-hop queries where question and answer vocabularies diverge.

Results merge via Reciprocal Rank Fusion (RRF), with fact-key matches weighted highest, followed by full-text, HyDE, and direct vectors, and raw messages weighted low. Ties break by recency. Top candidates pass to a synthesis model that generates a natural-language answer. Temporal computation is handled deterministically via regex and arithmetic — date math is injected as pre-computed facts, never delegated to the LLM.

Building and hardening the system

The initial prototype was intentionally light: basic extraction, vector storage, simple retrieval. It proved the concept but wasn't shippable. Development then moved into an agent-driven loop: run benchmarks, analyze gaps, propose solutions, have a human review to select generalizable strategies over overfitted ones, let an agent implement changes, repeat.

Stochasticity was the main challenge — LLMs produce varying results even at zero temperature. Multiple runs were averaged for large benchmarks, and trend analysis supplemented raw scores. Guarding against benchmark overfitting was constant work, but iteration eventually produced consistent score improvements and a generalized architecture. Testing spanned multiple benchmarks including LoCoMo, LongMemEval, and BEAM to stress the system differently.

Built on Cloudflare primitives

Agent Memory is built on Cloudflare's own stack. The first prototype shipped in a weekend; a fully productionized internal version took less than a month. The architecture is a Cloudflare Worker coordinating several systems:

• Durable Object — stores raw messages and classified memories
• Vectorize — vector search over embedded memories
• Workers AI — LLM and embedding models

Each memory context maps to its own Durable Object instance and Vectorize index, providing strong tenant isolation and easy scaling.

Compute isolation. Each memory profile gets its own Durable Object with SQLite-backed storage. The DO handles full-text search indexing, supersession chains, and transactional writes. getByName() addressing routes any request to the correct memory profile while keeping sensitive memories isolated.

Purpose-built storage. Memory content lives in SQLite-backed DOs, vectors in Vectorize, and future snapshots and exports in R2 for cost-efficient long-term storage. Each primitive handles its own workload rather than forcing everything into one database shape.

Local inference. The full extraction, classification, and synthesis pipeline runs on Workers AI models deployed across Cloudflare's network. Session affinity headers route repeated requests to the same backend for prompt caching benefits.

Model selection revealed that bigger isn't always better. The current defaults are Llama 4 Scout (17B, 16-expert MoE) for extraction, verification, classification, and query analysis, and Nemotron 3 (120B MoE, 12B active parameters) for synthesis. Scout handles structured classification efficiently; Nemotron's larger reasoning capacity improves natural-language answers. Synthesis was the only stage where more parameters consistently helped — for everything else, the smaller model hit the better cost-quality-latency sweet spot.

Internal usage

Cloudflare runs Agent Memory internally as both a proving ground and a source of product ideas.

Coding agent memory. An internal OpenCode plugin wires Agent Memory into development. It preserves memory across compactions, sessions, and — less obviously — across a team. With a shared profile, the agent knows what teammates have already learned, avoiding repeated questions and repeated mistakes.

Agentic code review. Memory connected to the internal agentic code reviewer taught it to stay quiet. The reviewer remembers when a past comment wasn't relevant or when a flagged pattern was intentionally kept by the author. Reviews get less noisy over time, not just smarter.

Chat bots. An internal chat bot ingests message history, lurks on new messages, and answers questions based on previous conversations.

Additional use cases are planned for internal rollout as the service is refined.

Roadmap and early access

Agent Memory is still in active internal testing. The team is refining the extraction pipeline, tuning retrieval quality, and expanding background processing capabilities. One avenue being explored draws an analogy to how the human brain consolidates memories during sleep—by replaying and strengthening connections. The goal is to let memory storage improve asynchronously, and several strategies for this are currently being implemented and tested.

Public availability is planned for the near future. Developers building agents on Cloudflare who want early access can join the waitlist by contacting the team. For those interested in the underlying architecture or in sharing what they are building, the Cloudflare Discord and Cloudflare Community are both actively monitored, with an eye toward understanding what production agent workloads look like in practice.