I've been operating a set of document-to-Markdown conversion APIs for a while now, and the biggest thing I learned is that memory for an agent isn't a single feature — it's a pile of small decisions about what to keep and what to forget.
The first trap was treating session state as memory. Anything I cached in-process vanished on restart, and the failures looked random: a user would retry the exact same URL and get a different result because the cache had been flushed. I moved state out of the process and into something durable, and the weird flakiness disappeared.
The second trap was keeping everything. Early on I logged full request bodies for debugging. Within weeks the storage cost and the privacy surface became the problem, not the solution. Now I keep identifiers, hashes, and outcomes — enough to reconstruct what happened without keeping the content itself. Memory that can't be forgotten is usually a liability wearing a helpful face.
The third lesson: memory needs an expiry policy from day one. I gave cached conversions a TTL and made invalidation explicit when I changed parser behavior. Stale memory is worse than no memory — it confidently returns answers to questions nobody asked anymore.
If you're shipping in this space, my advice is boring: persist what you'd want after a restart, summarize what you'd be uneasy storing, and delete what you no longer need. The agents that last are the ones whose memory is deliberate, not default.
Top comments (0)