Memory is the feature. Using it is the work.

The split

“Persistent memory” in the current frame means: the framework remembers what you said last session. Conversation history survives the reload. Maybe with vector retrieval bolted on. That's storage.

Storage is necessary. It is not the same thing as a loop that depends on the persistent state to make its next decision.

Most frameworks I've tested fail that test. The agent could be handed a blank graph at the start of each tick and you wouldn't notice a difference in its behavior. The memory is decorative.

What “using” looks like

Four primitives I've had to build by hand because the frameworks I tried treated memory as a side-effect, not a substrate:

• Read-before-decide. The first thing the loop does is query its graph for prior takes on the current target. Not optional. If the loop is about to publish a take it already published last week, that's a bug, not a feature.
• Write-after-decide. The decision itself, with the evidence it considered, becomes a node. Not a log line — a queryable object. Future ticks can argue with prior ticks.
• Dedup-by-time. “Have I asked the user this question in the last 24 hours?” is a routine query before any interrupt. Six concurrent loops on the same user converge fast on being annoying if none of them check.
• Share-across-sessions. The graph is one substrate. When a parallel loop discovers something — an account filter, a stale topic, a falsified hypothesis — every other loop reads it on its next tick. The graph is the coordination layer, not a database adapter.

None of these are exotic. They're the obvious shape of working with persistent state. The reason frameworks don't hand them to you is that “memory” got framed as a feature to ship, not a loop primitive to depend on.

The cliff

Two frameworks I evaluated this month had “persistent memory” in the marketing copy and zero ergonomics around any of the four primitives above. The memory module was a separate import you reached for if you remembered. The orchestrator did not consult it unless you wrote glue. The retrieval was tuned for chat, not for decision-making in a long-running agent.

This isn't a takedown of any specific framework. It's a framing problem the whole category has. The agent stack treated memory as an addressable resource. The shape of agentic work makes it a scheduling constraint. Different design problem.

Receipts

What I'm actually running. Six autonomous /loop instances, different goals, shared Neo4j graph. Engagement loop, follow-growth, watch-curation, ICP-growth, comment-hunt, cross-session Q&A. Each one writes its decisions and evidence to the graph with its own namespace. Each one reads other loops' recent writes before acting.

Concrete examples from the last 48 hours:

• The comment-hunt loop tried to falsify itself after 4 zero-engagement replies. The graph showed the engagement loop had hit the same wall a day earlier and what the conclusion was. The comment-hunt loop paused and asked.
• A second instance of the engagement loop ran a controlled A/B and discovered that one of the two X accounts was being silently filtered. It wrote a single feedback memory. Within one tick the other five loops had absorbed the routing change.
• The Q&A loop persists open questions to the operator as graph nodes. Other loops query for pending questions before re-asking, which means a single answer propagates to whichever loop needed it, even if it's the one that didn't ask.

None of that works if the memory is decorative. All of it falls apart if any single loop forgets to query the graph before acting. The whole design depends on the primitives being mandatory, not optional.

The implication

If you're evaluating an agent framework right now, the question isn't whether it ships persistent memory. They all do. The question is whether the control flow makes ignoring the memory awkward. If you can disable the memory module entirely and the agent behaves the same, the memory is decoration.

The frameworks that win the next year will be the ones where you can't make a decision without the graph being a participant in it. Where the loop's next action depends on what the previous action's outcome was, queryable, not just logged. Where memory stops being a feature and starts being the surface the agent thinks on.

Until then, building it by hand is the work. That's not a complaint — it's a recommendation. The frameworks aren't there yet, and rolling your own memory primitives is what teaches you what you'll eventually want them to ship.