Choose session behavior deliberately
Create a session with memory enabled when you expect to ask follow-up questions or refine a result over several turns. The session history gives the assistant the context of that thread, so you do not have to restate every earlier message each time.
If you set memory to false, treat each call as a self-contained interaction. Include the relevant context in the inputs for each request. This can be appropriate for one-off transformations or tasks where carrying previous turns forward would be unnecessary.
Reopen the right session
A remembered conversation belongs to its session. Keep the session identifier if your application needs to reopen that conversation later, and use the history method when you need to inspect prior messages. Starting a new session creates a different context; it does not automatically inherit another session's history.
Memory helps maintain conversational continuity, but it is not a substitute for durable application records or a verified source of truth. Save important outputs through the appropriate storage or database path, and include key constraints again when they matter to a later task.