I have been building a local AI memory layer for a while, and the same problem shows up every time you try to make an assistant feel stateful.

The agent is impressive in the moment, then it forgets. Or it remembers the wrong thing and hardens it into a permanent belief. A one off comment becomes identity. A stray sentence becomes a durable trait. That is not a model quality issue. It is a state management issue.

Most people talk about memory as “more context.” Bigger windows, more retrieval, more prompt stuffing. That is fine for chatbots. Agents are different. Agents plan, execute, update beliefs, and come back tomorrow. Once you cross that line, memory stops being a feature and becomes infrastructure.

The mental model I keep coming back to is an operating system.

1.What gets stored 2.What gets compressed 3.What gets promoted from “maybe” to “true” 4.What decays 5.What gets deleted 6.What should never become durable memory in the first place

If you look at what most memory stacks do today, the pipeline is basically the same everywhere.

Capture the interaction. Summarize or extract. Embed. Store vectors and metadata. Retrieve. Inject into the prompt. Write back new memories.

That loop is not inherently wrong. The bigger issue is where the loop runs. In a lot of real deployments, the most sensitive parts happen outside the user’s environment. Raw interactions get shipped out early, before you have minimized or redacted anything, and before you have decided what should become durable.

When memory goes cloud first, the security model gets messy in a very specific way. Memory tends to multiply across systems. One interaction becomes raw snippets, summaries, embeddings, metadata, and retrieval traces. Even if each artifact feels harmless alone, the combined system can reconstruct a person’s history with uncomfortable fidelity.

Then there is the trust boundary problem. If retrieved memories are treated as trusted context, retrieval becomes a place where prompt injection and poisoning can persist. A bad instruction that gets written into memory does not just affect one response. It can keep resurfacing later as “truth” unless you have governance that looks like validation, quarantine, deletion, and audit.

Centralized memory also becomes a high value target. It is not just user data, it is organized intent and preference, indexed for search. That is exactly what attackers want.

And even if you ignore security, cloud introduces latency coupling. If your agent reads and writes memory constantly, you are paying a network tax on the most frequent operations in the system.

This is why I think the edge is not a constraint. It is the point. If memory is identity, identity should not default to leaving the device.

There is also a hardware angle that matters as agents become more persistent. CXL is interesting here because it enables memory pooling. Instead of each machine being an island, memory can be disaggregated and allocated as a shared resource. That does not magically create infinite context, but it does push the stack toward treating agent state as a real managed substrate, not just tokens.

My bet for 2026 is simple. The winning agent architectures will separate cognition from maintenance. Use smaller local models for the repetitive memory work like summarization, extraction, tagging, redundancy checks, and promotion decisions. Reserve larger models for the rare moments that need heavy reasoning. Keep durable state on disk so it survives restarts, can be inspected, and can actually be deleted.

Curious what others are seeing. For people building agents, what is the biggest blocker to running memory locally today: model quality, tooling, deployment, evaluation, or something else?

2026 will be the year of on-device agents