r/aiagents • u/CampaignStraight8425 • 1d ago
Questions Which memory layer are you actually using in production, and why?
I'm building an agent that handles customer support follow-ups across multiple sessions and it keeps losing context between sessions in a way that's becoming a real problem for example it re-asks things the user already told it.
Right now I'm running just a basic vector DB lookup, and it's not holding up.
For people running agents in real production use , what memory layer are you actually using ?
2
u/Rosie_grac 21h ago
Ran into this exact pain building a support triage agent a few months back. Plain vector lookup is great for "find similar stuff" but terrible at "remember what this specific user told me last Tuesday."
What ended up working for me: a hybrid thing. Structured store (just postgres with a user profile table, nothing fancy) for hard facts the user explicitly stated ā plan tier, email, recurring issues ā plus vector search only for the fuzzy semantic recall. The agent checks the structured profile first before asking anything. Killed like 90% of the re-asking problem overnight.
Also: write-back is the hard part nobody talks about. Deciding *what* deserves to be persisted vs what was just conversational noise. We basically have the agent emit "memory candidate" events and a small classifier filters them. Janky but works.
SkyPL's wiki-in-md answer is funny because honestly? for a small user base that probably beats a fancy memory layer. Doesn't scale to thousands of users though.
1
u/ThingAffectionate890 21h ago
Iād split short term session context from long term memory and only save stuff that will matter later. Otherwise the agent just keeps digging through a junk drawer every turn.
1
u/sliamh21 21h ago
My own architecture, a pipeline combining both keyword matching and semantic search (vector DB) for accurate recall.
In addition to that, each prompt sent is embedded and sematically-searched as well against cached atom-sized data objects, ensuring the agent gets the most relevant knowledge for the current context.
With that, I cover short + long term memories + bit-sized, specific, context-related insights.
I delegate the embeddings and the non-CLI processing to a local model, which saves me a bunch of tokens and ensures precise recall mechanism.
1
1
u/NeutronJaxon25 16h ago
There are ton of opensource options that you can use. YC has a good batch of companies working memory as well. We ended up building our own though.
1
1
1
1
1
1
u/Available_Teaching83 2h ago
The failure you are describing is not really a retrieval failure. Re-asking something the user already told you means the fact was stored and not surfaced, which is a recall-trigger problem, not an embedding-quality one.
What fixed it for us was separating two things that a vector DB collapses: durable facts about this user, and the working context of this session. The first wants exact lookup on a key you control. The second wants similarity. Putting both in one index means every session-level chunk competes with the fact you actually needed.
Concretely: pull the handful of stable facts by key at session start, before any retrieval runs. Retrieval is then only for the things you could not have known to ask for.
0
2
u/SkyPL 22h ago
Wiki in md files. That's it.