OpenAI’s Agents SDK 0.14.6 Says the Framework Fight Is Moving From Agent Loops to Default Runtime Choices
Agent frameworks used to compete on the fun parts: clever handoffs, cute orchestration diagrams, and how many times a demo agent could delegate to another demo agent before someone on X called it the future of software. That phase is ending. OpenAI’s openai-agents-python v0.14.6 release is small on paper, but it points at the more serious contest now underway: which framework gets to define the default runtime assumptions teams inherit when they stop prototyping and start operating.
The obvious headline is simple enough. OpenAI updated examples and defaults from GPT-5.4 to GPT-5.5. On the surface, that looks like routine housekeeping. It is not. In framework land, defaults are policy. They shape latency expectations, cost baselines, eval outcomes, bug reports, and eventually architecture decisions made by teams that never explicitly sat down to debate whether the default model was the right one. A runtime that chooses for you is not neutral, even when the change fits in a single release-note bullet.
That matters because OpenAI’s SDK is explicitly trying to position itself as the higher-level answer to the question, “When should I stop owning the loop myself?” Its documentation still emphasizes a deliberately small primitive set: agents, handoffs, guardrails, sandbox agents, sessions, human-in-the-loop controls, tracing, and realtime agents. The sales pitch is restraint. Do not learn an entire new graph calculus. Use a lightweight runtime that handles turns, tools, memory, and resumable execution while staying Python-first.
What 0.14.6 shows is that even a “small primitives” framework gradually accumulates a worldview. PR #3016 does more than rename a recommended model. It updates defaults, examples, and tests around GPT-5.5, including validation against default-model tests, sandbox compaction tests, converter tests, and example runs. That test surface is revealing. It says model choice now propagates through session memory, sandbox behavior, compaction, and developer ergonomics. In other words, the framework is not just wrapping model calls anymore. It is normalizing an expected operating environment.
A second release note looks even duller and is arguably more important. PR #3014 hardens uv dependency resolution with a seven-day exclude-newer gate, a first-index strategy, pinned setup behavior, and digest-pinned tutorial container installs. If that sounds like packaging trivia, read it again. Public agent frameworks are now supply-chain surfaces. The more a framework ships starter repos, examples, containers, and copy-paste install paths, the more it becomes responsible for reducing the odds that developers inherit a compromised dependency tree while trying to get a quick demo running before lunch.
This is where the category is getting more honest. The market spent the last year arguing over abstractions. Do you like handoffs, graphs, crews, agents-as-tools, event buses, capabilities, or workflows? Those questions still matter, but they are no longer the first filter. The first filter is increasingly operational: what model does the framework quietly optimize around, how does it preserve state, what are its dependency assumptions, and how much of your runtime posture are you delegating just by using the starter path?
The memory story is becoming the real product
The MongoDB session documentation added in PR #3015 deserves more attention than it will get. Sessions are where agent frameworks stop being fancy wrappers and start acting like runtime systems. OpenAI’s documentation already frames sessions as the persistent memory layer that maintains working context within an agent loop. That is easy to nod along with when you are building a toy assistant. It becomes much more concrete once approvals, resumable runs, multiple workers, or long-lived application context enter the picture.
SQLite is fine for local development. It is not the answer every team wants once state has to outlive a single process or a single machine. By making MongoDB sessions a documented path instead of an implied extension point, OpenAI is doing something strategically smart: it is widening the set of teams that can operationalize continuity without forcing them into a completely different framework. That is how frameworks become sticky. Not by adding another orchestration metaphor, but by making the boring persistence question easier to answer inside the existing runtime.
This also sharpens the difference between “use the Responses API directly” and “use the Agents SDK.” OpenAI’s own docs are candid here. If you want to own the loop, tool dispatch, and state handling yourself, stay closer to the API. If you want the runtime to manage turns, guardrails, handoffs, sessions, or sandboxed workspaces, use the SDK. That split is sensible. But releases like 0.14.6 remind us that when you choose the SDK, you are not just buying convenience. You are inheriting runtime judgment.
That is not necessarily a criticism. It is how frameworks work. The problem is when teams pretend otherwise. If GPT-5.5 becomes the normal path through examples and defaults, your eval baselines should be revisited. If the packaging path gets stricter to reduce dependency confusion, your internal mirrors and CI assumptions may need a look. If MongoDB sessions are now a first-class documented option, you should ask whether your agent memory model is still a dev artifact or something you are willing to call production state.
The framework war is moving down the stack
The broader industry pattern is hard to miss. Microsoft is pushing runtime seams like tracing, A2A, and hosted sessions. CrewAI keeps sanding checkpoint and sandbox behavior. LangChain keeps relearning that message shape and tool fidelity are architecture, not formatting. PydanticAI is formalizing approval and event middleware. OpenAI’s contribution in 0.14.6 is quieter, but it lands in the same place. The fight is moving from “who has agents?” to “whose runtime defaults are sane enough that you will still like them six months later?”
For practitioners, the advice is refreshingly unglamorous. If you use the OpenAI Agents SDK, re-run evals under GPT-5.5 assumptions before letting the new default quietly become your benchmark. Review whether the dependency-hardening changes affect reproducibility in your containers or CI. And if you have been hand-waving the memory layer, decide whether sessions are truly ephemeral in your product or whether you now need a persistence backend that matches your actual uptime and resume requirements.
The old framework discourse was too focused on what agents can do. The interesting question now is what the runtime assumes on your behalf when nobody is looking. v0.14.6 is a patch release. It is also a reminder that the most consequential framework decisions are increasingly hidden in defaults, package resolution, and memory backends, which is exactly where mature software platforms tend to reveal their real priorities.
Sources: OpenAI Agents SDK v0.14.6 release notes, OpenAI Agents SDK documentation, OpenAI Agents SDK sessions documentation