Agent memory is not useful because it exists. It is useful when it prevents repeated steering without creating new ambiguity.
The trap is treating memory as an infinite notebook. Dump every session into it and the agent starts sounding informed while quietly mixing durable facts, stale conclusions, and half-finished task state. That is worse than forgetting.
What belongs in memory
The memory layer should store facts that will matter next week: stable repo paths, provider policy, machine topology, user preferences, deployment quirks, and procedures that have already survived contact with reality.
It should not store the emotional weather of a session or every temporary TODO. Those belong in logs, transcripts, or task artifacts.
Why local-first
For the operator stack, memory runs through a local OpenAI-compatible endpoint backed by Ollama. That keeps the memory path close to the rest of the system and avoids turning recall into another opaque cloud dependency.
The control problem
Memory has to be governed. A fact can be true, stale, sensitive, too broad, or too noisy. Good memory hygiene is mostly deletion and compression, not accumulation.
- Prefer compact facts over transcripts.
- Separate operational policy from session history.
- Use skills/runbooks for procedures, not vague memories.
- Verify live system state instead of trusting remembered state.
The result
When it works, the agent stops needing the same corrections. It knows which repo is canonical, which provider lane is allowed, which machine owns the control plane, and when a task needs explicit approval.
That is not glamorous. It is the difference between an assistant and a tool you have to re-train every morning.