The interesting movement this month isn't in retrieval quality. It's in who owns the write path.
Tencent Cloud open-sourced TencentDB Agent Memory v2.0 in early August, described by MarkTechPost as a team-level memory hub for AI coding agents. Three weeks ago the project announced it had passed 20,000 GitHub stars in 90 days and shipped Team Memory for multi-agent collaboration. Mem0 published a "State of AI Agent Memory 2026" benchmarks report around the same time, and the framing is showing up in research too — an arXiv paper titled "Beyond RAG for Agent Memory: Retrieval by Decoupling and Aggregation" argues the retrieval design for memory differs from the one you'd build for documents.
Treat the star count as a popularity signal, not a validation. The substance is the shift from *my agent remembers our conversation* to *our agents share what they learned*.
Why team-scoped memory is a different system
A single-agent memory store is close to a cache: one writer, last-write-wins, and a human in the loop who notices when it's wrong. Team memory breaks all three assumptions.
Multiple writers means conflicts you cannot resolve by timestamp. Two coding agents infer contradictory things about a service's retry semantics; the newer write isn't the correct one, and neither carries a confidence you can trust. You need provenance on every memory — which agent, which task, which source artifact — and a resolution policy that can say "unknown" instead of picking.
Scoping becomes an access-control problem. If an agent working in a private repo writes a memory that surfaces in another team's context, you've built an exfiltration channel out of a convenience feature. Memory reads need to inherit the permissions of the source material, which is exactly the problem enterprise search spent a decade getting wrong with stale ACL snapshots.
Then staleness. Documents in a RAG corpus get re-indexed when the source changes. Agent-authored memories have no source to re-check — they're inferences. Without a TTL, a re-verification pass, or an eviction policy tied to the artifacts they were derived from, a team memory store degrades into confidently wrong institutional folklore.
The plumbing question
This lands on top of an unsettled transport story. The MCP spec shipped its 2026-07-28 revision after a release candidate, the project published a new roadmap about a week ago, and Google has been writing about stateless MCP for agent infrastructure. If memory becomes an MCP server — and it will, because that's the cheapest way to reach every client — then read/write semantics, auth scoping, and statelessness are the same problem.
Who this matters to: if you run more than one agent against a shared codebase or ticket queue, you're about to be handed a shared memory feature. Ask for provenance, per-memory ACLs, and an eviction story before you turn it on. Without those three, you've added an unversioned, unreviewable database to your stack — and given every agent write access.