Keep the transcript, but don't treat it as memory

Think about what's actually in one conversation. There's probably a project name, a deadline, a preference, a question nobody answered and a few ideas that got talked about and then dropped. If you save the transcript, you've saved the exchange. What you haven't done is tell the next session which of those statements are still true, or which one should guide the work.

You notice this the moment something changes. Say someone gives a delivery date, corrects it later in the same thread, then talks through a "what if we pushed it out" option. A similarity search can quite happily pull back all three passages. The model gets a pile of related text and has to work out the current date from the order of the messages and how they were worded. That gets shakier again if the correction happened somewhere else, like an email or a different chat.

So I'd treat transcripts as source material. The durable memory should be smaller records pulled out of those sources, each with an identity, a type, a status and a link back to the evidence. A record like project delivery date can point at the message or document that set it, and then get superseded when an authorised correction comes in.

Splitting things this way also gives you control over what goes into the prompt. A task might need the current date and the decision that set it. It probably doesn't need the whole back-and-forth about calendar options. Retrieval can hand over the compact record first and let the agent open the source if the task needs the context.

Don't throw the transcript away once you've extracted from it, though. You'll need it to check exact wording, sort out disputes and improve the extraction later. It just has a different job from the store that holds current state.