The most useful argument this week isn't about a model. It's about which layer of the stack owns agent memory, and three credible answers surfaced within days of each other.
The storage claim. Vast Data's CTO argued at the company's Fully Connected event that agent memory belongs in storage . The pitch is structurally sound: memory is a write-heavy, versioned, multi-tenant, long-lived data problem, and application-layer memory services end up badly reimplementing durability, snapshotting, and access control. If you've ever tried to answer "what did this agent know on Tuesday, and who was allowed to see it," you've felt the gap. The counterargument is just as plain — memory relevance is semantic, not block-level, and a storage vendor that owns your agent state owns your migration path.
The plugin claim. At the other end, the pattern that actually ships today is session capture and replay: tools like claude-mem, a persistent memory plugin that captures everything your coding agent does and replays it next session . This is memory as transcript. It works because it's cheap and it's local, and it fails in the obvious way — replaying a session doesn't tell you which parts were true, and stale decisions get re-injected with the same confidence as current ones.
The docs claim. The sharpest pushback came from a post arguing that most agent memory systems are solving the wrong problem entirely — that agents don't need memory, they need documentation. It landed well because it names something teams discover late: most "memory" writes are compensating for context that should have been a durable, reviewed artifact in the repo. A CLAUDE.md or an ADR is memory with a diff, an owner, and a review gate. A vector of last Tuesday's conversation is none of those.
How to choose
These aren't competing products so much as three different write paths, and you probably need all three with hard boundaries between them:
- Facts that should outlive the agent → documentation. Version-controlled, human-reviewed, retrieved like any other corpus. Cheap to audit, cheap to delete.
- Working state within a task → session capture. Ephemeral by default, with an explicit TTL. Don't let it graduate to long-term store without a promotion step.
- Durability, isolation, and lineage → the storage layer. This is where the vendor argument has real force, and where most homegrown memory services are weakest.
The failure mode is letting the layers blur. Once an agent can autonomously write to a shared long-term store that other agents retrieve from, you've built a persistence-backed injection surface — the same class of problem as data poisoning and indirect prompt injection against RAG , except the poisoned document is one your own system authored and now trusts implicitly.
Practical move this quarter: audit what your agents write back, and ask of each item whether it would survive code review as a doc. Most of it won't. That's your answer.