The demos always look the same. A user types a question. The agent answers. Everyone nods. What the demos don’t show is what happens in the second conversation, or the fiftieth, when the agent has no idea who it’s talking to or what happened before.

Memory is one of those things that seems optional until you try to ship something real. Then it becomes the problem you can’t ignore.

Why context degrades without memory

A language model’s context window is a finite resource. In a long conversation, you either pay to include more history (expensive, and eventually impossible) or you truncate (and lose information the agent needs). Neither is a satisfying answer.

The deeper issue is that even within a conversation, different kinds of information need to be managed differently. Facts the user told you in session one (“I’m on the Pro plan”) have different lifetimes than temporary working state (“I’m currently helping them with order #4821”).

Three layers of memory

The way we think about it at Korelos, there are three distinct layers:

• Session memory: The current conversation. Active while the session is open, discarded after. Used for tracking intermediate state and the immediate context of what’s being discussed.
• User memory: Persistent facts about a specific user. Their preferences, their plan tier, their history with your product. Persists across sessions. Scoped to the user identifier you provide.
• Global memory: Shared context that applies to all interactions. Your product FAQ. Business rules. Things that don’t change per-user but that every conversation might need.

How Korelos handles this

When you deploy an agent on Korelos, you configure a memory policy as part of the agent definition. You decide which layers are active, what the retention window is, and what gets summarised vs. stored verbatim. The platform handles the mechanics: retrieving relevant context at the start of each turn, updating user memory when the agent extracts persistent facts, and purging session state when conversations close.

None of this requires you to write any memory management code. It’s part of the infrastructure that Korelos handles by default.

The thing most people get wrong

The most common mistake is treating memory as a retrieval problem and ignoring the write side. Getting the right context into the model matters, but so does deciding what to write to long-term memory in the first place. If you store everything, retrieval becomes noisy. If you store nothing, context is lost.

Our agents use a lightweight extraction step at the end of each session to decide what, if anything, is worth persisting. You can configure what types of facts to extract or write your own extraction logic. Most teams start with the defaults and tune from there.