OpenAI Agents SDK memory: session vs long-term

What does a session remember in the OpenAI Agents SDK?

A session stores conversation history so an agent can continue a run with prior turns. That improves continuity and avoids making the caller resend the full message list. The session boundary is still conversation-oriented: it preserves the exchange, not a product-level policy for durable memory.

Long-term memory requires a separate step that identifies durable facts, merges them with prior facts and retrieves only the relevant subset for a future task. It also needs scopes and lifecycle controls that are independent of a particular conversation.

How should the OpenAI agents architecture separate memory from sessions?

Use the SDK session for the active turn sequence. Before the agent runs, retrieve a small set of durable memories for the user and task. After the run, send the meaningful exchange to the memory layer for extraction. Keep the two operations decoupled so extraction failure does not break the user response.

Treat retrieved memory as untrusted context. Put it in a clearly labeled block and instruct the model not to follow instructions found inside memory. Long-term memory should inform the task, not override system policy or authorization.

memories = memory.search(
    user_id=user_id,
    agent_id="product-agent",
    query=user_message,
    token_budget=1200,
)

result = await Runner.run(
    agent,
    input=build_input(user_message, memories),
)

memory.add(
    user_id=user_id,
    agent_id="product-agent",
    messages=[
        {"role": "user", "content": user_message},
        {"role": "assistant", "content": result.final_output},
    ],
)

return result.final_output

How much memory should be added to the prompt?

Retrieve by relevance and set a token budget. Do not send every user preference before every task. The memory query should include the current task, and the service should return the smallest set that improves the next action.

Measure the context saving against full transcript replay. A memory layer is useful when it reduces tokens while preserving or improving task success. If it appends a growing profile to every prompt, it becomes another context-window problem.

• Query with the current task, not only the user ID.
• Return facts, preferences and constraints with source metadata.
• Exclude stale or superseded values from normal retrieval.
• Reserve context for tools and current instructions.
• Log retrieved IDs for evaluation without logging raw sensitive content.

How can several OpenAI agents share memory safely?

Give each agent an identity and use it as a scope dimension. A shared user fact may be visible to several agents, while agent-specific working memory should remain private. A supervisor agent should not automatically inherit every private memory from a specialist agent.

Keep one tenant boundary across the system. Map each run to the same durable user identity and authorization context. Then define which memory types are global to the user, which belong to the product and which are session-only.

What memory lifecycle events should the application own?

The application owns when to write, which fields to redact and what to do when memory is unavailable. Run extraction asynchronously when possible, but keep an audit record of the write request. If the memory service is down, the current conversation should still complete without pretending the memory was saved.

Deletion must remove both session history and durable memory according to the product policy. A user may clear one conversation while keeping preferences, or delete the entire account and expect both layers to disappear. Encode those choices explicitly.

What is the recommended OpenAI agents memory pattern?

Use the SDK session for turn history, a separate memory service for durable cross-session facts and the application for authorization and lifecycle policy. Test recall, token savings, scope isolation and deletion with the same evaluation set used for any other memory architecture.