Question about session memory

[xylhal]

Please read this first

• Have you read the docs?Agents SDK docs - Yes
• Have you searched for related issues? Others may have had similar requests - Yes

Question

Based on the docs (https://openai.github.io/openai-agents-python/sessions/), when using sessions, the memory between runs/in between runs are managed the following way:

1. Before each run: The runner automatically retrieves the conversation history for the session and prepends it to the input items.
2. After each run: All new items generated during the run (user input, assistant responses, tool calls, etc.) are automatically stored in the session.
3. Context preservation: Each subsequent run with the same session includes the full conversation history, allowing the agent to maintain context.

Upon closer inspection, I noticed that the following are logged as dicts in a list when using session.get_item() :
type, id, call_id, arguments, name, content, role.

• My question is are all these pushed in entirety to the LLM as part of the input?
• If so, doesn't it seem a little overloaded (though useful for debugging) to pass in things like id, call_id for the agents to manage the conversation state?
• Also, is there a simple way without creating a custom memory to only save certain types of items?

[seratch]

Thanks for asking the questions. The items vary, so what properties are included really depends on the items' types. All the properties are required to continue a conversation with LLM, so I don't think the current built-in SQLite implementation stores unnecessary data.

[xylhal]

Thanks for your response.

Suppose I decide I do not want my current active agent taking in the previous agent's ids because I believe that's not really helpful in terms of the conversation state, is there a built-in way to remove those information by types/properties?

Or is the best way to create another helper function to parse and filter out the information I do not need in the session based on the item types/properties?

[seratch]

This sounds like you need your own implementation to manage conversation sessions in the most suitable way for your use case. If you think the sessions store is useful for managing the raw data within such a mechanism, you can use the sessions store as part of your implementation.