The most consequential shift in knowledge tooling right now isn't a model release. It's that agent memory is being absorbed into the platform layer, and the design questions that come with it are ones most teams haven't answered yet.
Three data points from the last two months trace the line. Cloudflare shipped Agent Memory as a platform primitive in mid-July, announced as "Agents that remember." Tencent's TencentDB Agent Memory passed 20,000 GitHub stars in 90 days and, in mid-August, added Team Memory for multi-agent collaboration. And Mem0 published a State of AI Agent Memory report at the end of August, which is the sort of thing a category publishes when it stops being a pattern and starts being a market.
The direction is clear enough: memory is moving out of your application code and into something you provision. That's mostly good — the glue code everyone wrote in 2025 (summarize the conversation, embed it, stuff the top-k back into the system prompt) was never a system. But the migration hides where the actual difficulty lives.
The write path is the hard part
Document RAG is read-heavy against a corpus you control. Agent memory is write-heavy against a corpus the agent is actively mutating, and that changes the engineering. You need to decide what gets written at all, how to reconcile a new fact that contradicts an old one, how to resolve entities across sessions, and how to expire things that were true in March. None of that is a similarity search problem, and bolting it onto a vector store is why so many memory layers degrade into a pile of stale, mutually contradictory snippets by month three.
The research is catching up to this. A recent arXiv paper — "Beyond RAG for Agent Memory: Retrieval by Decoupling and Aggregation" — argues explicitly for separating memory retrieval from standard RAG machinery, and a broader survey on memory mechanisms and evaluation landed alongside it. Take the framing more seriously than the benchmarks: if your memory retrieval is literally your document retrieval with a different index name, you've probably conflated two workloads.
Team memory raises the permissions question
Shared memory across agents is where this gets genuinely dangerous. Once several agents read and write a common store, you inherit every problem enterprise search spent a decade on — whose ACLs apply when agent A writes a fact derived from a document agent B can't see? Memory launders permissions by default. A fact extracted from a restricted source loses its provenance the moment it becomes a summarized "memory," and no amount of retrieval filtering downstream will fix that.
If you're building on one of these platforms, the questions to ask vendors are unglamorous: does a memory record retain the ACL of its source, can I scope writes per-agent, and how do I audit what was remembered and why. Retrieval quality is the demo. Write governance is the system.