The OpenAI Agents SDK is remarkably well-designed for orchestration. Handoffs between agents are clean and explicit. Guardrails let you set boundaries and safety rules. Tracing gives you visibility into what agents are doing. The SDK makes it easy to build multi-agent systems that coordinate smoothly and stay under control.
But the OpenAI Agents SDK has no memory layer, and that's intentional. This isn't an oversight. OpenAI made a deliberate scope decision: build the best orchestration SDK possible, and let memory be someone else's problem. The SDK focuses on the current execution context. Everything within that boundary is handled well. Everything outside of it is not the SDK's responsibility.
This is respectable engineering. A memory layer adds complexity, and one-size-fits-all solutions don't work for everyone. Some teams need vector-based semantic memory. Others need structured entity stores. Some want temporal reasoning; others don't. Building a universal memory layer usually means building something that fits no one particularly well.
Orchestration and Memory Are Different Problems
OpenAI made the right choice for what they're good at. They're excellent at managing agent execution, handoffs, and control flow. Memory is a separate infrastructure problem requiring different abstractions. OpenAI chose not to blur those boundaries.
The consequence is that when you deploy an agent built with the OpenAI SDK, it has no persistent memory by default. Each session starts fresh. The agent doesn't know who the user is unless you pass that information in the current request. The handoff architecture brilliantly passes control between agents within a session, but doesn't pass accumulated knowledge between sessions.
You have to bring your own memory infrastructure. You need to decide how you're storing user context, designing your retrieval strategy, and managing integration between your memory system and the agent SDK. This is necessary engineering work, not a flaw in the SDK's design.
What Teams Actually Need to Build
Your architecture looks like this: the OpenAI SDK handles agent orchestration and control flow. Your infrastructure handles user context and persistent memory. You load relevant user data before sending a request to the agents, pass it as context in execution, and save any learning back to your memory system after execution completes. The separation is clean, but it requires you to own the memory layer entirely.
Many teams deploying with the OpenAI SDK end up building this integration anyway, so the scope boundary isn't actually a limitation. But it does mean memory is explicitly your problem, not the framework's. If agents start contradicting each other across sessions, those are bugs in your memory implementation, not the SDK.
The openness of this boundary is actually valuable. You're not locked into OpenAI's memory model. You can integrate whichever memory infrastructure makes sense for your use case. But you do have to integrate something.
Why This Boundary Matters
Why agent frameworks ship without real memory explains the broader pattern. Frameworks optimize for the problem they're built to solve. OpenAI Agents SDK solves orchestration. Memory is a deployment-time problem. That's honest scoping. The danger is when teams assume a framework that handles execution also handles memory, and they end up with agents that forget.
The OpenAI SDK makes that boundary obvious. There's no memory layer to confuse, no false sense that the framework is handling persistence. You know immediately that you need to bring your own memory infrastructure. That clarity is actually a feature. Why AI agents forget users after one session shows what happens when that boundary is blurred.
FAQ
Can I use the OpenAI SDK without a memory layer?
Yes, for single-session or stateless use cases. If your agent solves a problem and you never see the user again, you don't need persistence. But if users return, you need memory.
What memory infrastructure works best with OpenAI Agents SDK?
That depends on your use case. Vector stores work for semantic retrieval, relational databases work for structured facts, and graph databases work for relationships. The SDK is agnostic because memory is your responsibility.
