The interesting thing about Databricks shipping Agent Memory in beta on October 20 isn't that another platform now sells persistent memory. It's the specific architectural claim underneath it, which lines up with where several independent teams landed this month.
Per the Databricks launch post by Sirui Sun and Nihit Desai, their researchers' finding is that memory works best in two layers: a raw record of what happened, and a distilled record of what's worth remembering — with the distilled layer maintained by a background process rather than written ad hoc by the agent mid-task. The service is built on Lakebase-backed session and memory stores and an architecture they call MemCurrent, and it slots into Agent Bricks alongside agent hosting, the Databricks Sandbox, Unity Gateway, pre-built MCP servers, and tracing/evaluation.
Why the write path matters more than the store
Most memory implementations in production today have the agent decide, inline, what to persist. That's a tool call competing for tokens and attention with the actual task, and it produces exactly the failure mode you'd predict: memories written in the shape of the moment, redundant with each other, never revised when later turns contradict them. Moving distillation to an async background job decouples write quality from task latency and lets you reprocess history when your extraction logic improves. The tradeoff is staleness — a fact learned thirty seconds ago may not be in the distilled layer yet, which is why the raw record has to stay queryable rather than being treated as a staging buffer you discard.
One caveat worth holding onto: Data Phoenix notes the performance figures Databricks cites come from an internal benchmark that hasn't been independently reproduced. Treat the numbers as direction, not evidence.
The harness side of the same argument
LangChain published two pieces this week that approach it from the opposite end. Their framing is that long-running agents suffer "context rot" as accumulated context exceeds what the model can usefully hold, and their Deep Agents harness uses five techniques — offloading, summarization, skills, subagents, and memory — to keep material out of the active window. The companion post argues agent retrieval breaks in three ways: inefficient searching, too much context at once, and irrelevant or stale context. Their default is search-before-read: glob on filenames, grep for matching lines, and paged `read_file` rather than whole-document loads.
That's the same insight expressed as a tool contract instead of a storage tier. Both say the model shouldn't be the thing deciding what's worth keeping in the moment.
Who should care
If you're running a managed Databricks stack, this removes a build. If you're not, the portable lesson is cheaper: separate your append-only event log from your curated memory, and run curation out-of-band. You can do that on Postgres today. The managed versions — Cloudflare's since April, Tencent's open-source line — are converging on the same shape, which usually means the shape is right and the vendor choice is reversible.