Why developers argue about AI-agent memory: technique or philosophy?

On Habr, a typical technical article was published about memory for AI agents: SQLite, context storage, searching through accumulated knowledge, token economy. But the comments under the publication turned out to be much more interesting than the text itself.

Technique as a reason for dispute

On the surface, the discussion looked standard: which database to use, whether semantic search is needed or full-text search is sufficient, how to index context. Some insisted that SQLite covers most tasks — simple and reliable. Others demanded vector stores, RAG pipelines, multi-level retrieval mechanisms. Disputes about performance are commonplace. But as the discussion developed, a different question began to emerge from behind the technical arguments, one that is far more fundamental.

Three positions that can't agree

Developers arguing about memory for agents are actually divided on what they consider the agent itself to be. Roughly, three positions emerge:

• Instrumental: memory is a cache. An agent works better if it doesn't have to rebuild context from scratch each time. The task is purely engineering: speed, reliability, token economy.
• Behavioral: an agent should "remember" user preferences and adapt to them over time. This is about personalization and user experience.
• Identity-based: an agent should have a continuous "self" — a sense of its own history that influences judgments and decisions here and now.

Externally, these positions conflict over technical questions — storage format, context window size, forgetting policy. But in reality, they diverge at the level of conceptual expectations. If for one person "memory" means a lookup table, and for another it means forming the agent's identity, they won't agree on the structure of a database table.

"The problem isn't how to store — it's what we want to preserve at

all" — one discussion participant accurately formulated the essence of the disagreement.

Why tools are enough, but questions remain

Technically, the memory problem is solved fairly well. PostgreSQL with pgvector, Chroma, Pinecone, Redis, plain SQLite — each of these tools covers real scenarios. The stack is chosen for the task. The problem is different: the community has no consensus on what an agent is — which means there's no clear answer to what exactly needs to be remembered. If an agent is an autonomous entity, the task becomes almost philosophical:

• How to organize continuity of "self" between different sessions?
• How to decide what's important to remember and what to deliberately forget?
• How to prevent accumulated memory from becoming a source of hallucinations?
• Where is the boundary between personalization and creating user dependency?

These questions are not solved by choosing between SQLite and a vector database.

What this means

The discussion on Habr is a symptom of a broader split in the professional community. As AI agents move from prototypes into real products, fundamental questions about their nature cease to be academic. Teams that today design memory architecture are de facto deciding what their agent will be — a smart tool or something claiming to be more. And while this question remains open, technical disputes will continue.