Every agent that runs longer than one session needs memory that stays useful as it grows — not memory that just accumulates until the context window overflows and retrieval turns to noise. For two years the debate was where to put it: a file, a library, or a service. That was always the wrong question. Storage is the easy part.

The hard part is the pipeline: deciding what in a conversation is worth remembering, deduplicating it against what you already know, and forgetting what's stale before it poisons a retrieval. That pipeline is where agent memory rots in production — and as of 2026 you no longer have to write it. You can buy it, build it, or rent it. Here's how to choose.

The short answer#

Most agents are the first two cases. If you're hand-rolling a memory pipeline for a product where memory isn't the selling point, you're signing up to babysit the exact component that's hardest to keep healthy.

Buy: Cloudflare Agent Memory#

Agent Memory is a managed service, in private beta and not billed during the beta. The shape is deliberately small. You ingest raw message history — typically at the moment your harness compacts context — and Cloudflare extracts, deduplicates, and stores structured memories. At inference you recall, and it runs the full retrieval pipeline and returns only what's relevant, so you stop paying to stuff the whole history into every prompt.

It classifies every memory into one of four types — Facts (stable knowledge about a person, project, or tool), Events (completed actions anchored in time), Instructions (reusable procedures, which support supersession when they change), and Tasks — behind five operations: ingest, remember, recall, forget, list. Memories live in isolated profiles (per user, agent, team, or tenant) and namespaces (per app or environment), so multi-tenant isolation is a property of the service, not something you engineer.

What you give up is ownership of the schema and the forgetting logic, plus a Cloudflare-specific API surface. What you get back is the months you'd otherwise spend building — and re-building — that pipeline.

Build: Durable Objects#

The DIY route on Cloudflare is the Agents SDK's Durable Objects: each agent gets its own compute and its own SQLite file, so memory lives inside the agent at the edge with zero infrastructure to run. This is genuinely good — but notice it gives you storage, not a brain. You still write the code that reads a transcript, decides what's a durable fact versus a throwaway, deduplicates against prior memories, and decays the stale ones.

That code is the whole game, and it's where teams lose weeks. Build here when memory is your product — a note-taking agent, a personal-CRM agent, anything where "how well it remembers" is why someone chooses you — or when you have retrieval requirements a generic pipeline can't meet (unusual data-residency rules, domain-specific extraction, an existing store you must reuse).

Rent: a framework#

Between the two sits the framework option. Mem0, Zep, and Letta ship the same extract-dedupe-retrieve pipeline Cloudflare sells, but as open-core software you self-host or call as a service — no Cloudflare requirement. You get managed-shaped ergonomics without buying into one cloud, at the cost of running the component (or paying a vendor to). This is the right call when memory is plumbing but portability across clouds is a hard requirement.

The decision, in one line#

Ask what memory is for your product. If it's plumbing — necessary but not why customers pay — buy it (on Cloudflare) or rent it (a framework), and spend your weeks on the thing that is the product. If the way your agent remembers is itself the differentiator, build it on Durable Objects and own the pipeline end to end. And whichever you pick, judge it the way you'd judge any memory system: not on a clean benchmark, but on whether retrieval stays sharp after weeks of real traffic — the standard we lay out in how to read an agent-memory benchmark.