OpenAI's Agents API: the framework tax just moved in-house

What happened

OpenAI has published the Agents API, a first-party endpoint that runs the tool-calling loop, session state, and multi-agent handoffs server-side instead of leaving the developer to orchestrate them. The docs frame it as the successor path to the Assistants API — same primitives (threads, runs, tools, files) but restructured around agents as the top-level object, with explicit support for handoffs between specialized sub-agents and streamed intermediate events.

The core move is that OpenAI is absorbing the orchestration layer that developers have spent two years building in Python and TypeScript. Where LangChain's AgentExecutor, LlamaIndex's agents, and CrewAI's role graphs each reimplemented the same run-tool-observe-repeat loop on top of `chat.completions`, the Agents API just… runs it. You POST an agent definition with tools and instructions, then poll or stream the run. Tool calls come back as structured events; you execute them client-side or hand them off to another agent, and the state persists in the thread without you managing message arrays.

The Hacker News thread (272 points as of writing) is doing the usual dance: half the top comments are engineers noting they can now delete a folder of glue code, the other half are pointing out that this is the third time OpenAI has shipped "the" agent primitive — Functions, then Assistants, now Agents. The Assistants API is officially in sunset mode; the migration doc exists but is thin.

Why it matters

For two years the agent-framework layer has been the most contested piece of the LLM stack. LangChain, LlamaIndex, Instructor, DSPy, Autogen, CrewAI, Semantic Kernel — pick your abstraction, then argue about it in a GitHub issue. The reason there were so many was structural: `chat.completions` is stateless and single-turn, so *someone* had to write the while-loop that reads a tool call, executes it, and stuffs the result back into the next request. That someone was usually a Python framework maintainer with strong opinions about pydantic.

By shipping the loop as an API, OpenAI is making a bet that the framework layer is a temporary fixture — like the ORMs people wrote in 2005 to paper over SQL drivers that couldn't parameterize queries properly. If the model host runs the loop, streams intermediate steps, and persists state, most of what LangChain does becomes optional. What's left — retrievers, evaluators, tracing — is either commoditized (LangSmith competes with OpenAI's own eval tooling) or a thin wrapper that could live in a 300-line file.

The strategic subtext is sharper. Anthropic's answer to this problem has been the opposite direction: give developers *more* primitives (computer use, MCP servers, the Claude Agent SDK as a subprocess) and let orchestration stay in userland. Google's Gemini has agent-adjacent features but nothing that competes head-on. OpenAI is betting agents work better when the model provider owns the control plane; Anthropic is betting they work better when the developer does. Both are defensible. Neither can be true forever.

The second source in this cluster — a Chinese reverse-proxy repo that wraps the national anti-fraud AI in an OpenAI-compatible interface — is unrelated on its face, but it's worth naming what it demonstrates: OpenAI's API shape is now the de facto lingua franca. Every serious inference provider and half the government models ship an OpenAI-compatible endpoint. That's leverage. It also means the Agents API, if it becomes standard, will get cloned by vLLM, Together, Fireworks, and the rest within a quarter — which changes the lock-in calculus.

What this means for your stack

If you're building agents on OpenAI today and your codebase has a `agents/` folder full of Python that reads suspiciously like a state machine, the honest read is: rewrite it against the Agents API and delete the folder. The migration is not free — thread persistence semantics are different, tool schemas are stricter, and streaming events have a new shape — but the ongoing maintenance cost drops noticeably.

If you're building agents on OpenAI and Anthropic simultaneously, do not migrate. The Agents API has no cross-provider equivalent. Porting your control loop into OpenAI's runtime means either (a) forking your agent code per provider or (b) writing a shim that flattens the Agents API back into a stateless interface, which defeats the point. For multi-provider shops, the framework tax is still cheaper than the abstraction rewrite.

If you're on the Assistants API, migrate now rather than later. Sunset timelines from OpenAI historically slip, but the tooling around Assistants (SDKs, examples, community help) is going to bit-rot fast. The new Agents primitives cover the same use cases with cleaner ergonomics — thread management, tool definitions, and run polling are all less awkward than they were.

Looking ahead

The interesting fight over the next 12 months isn't whether the Agents API succeeds — it will, because OpenAI has enough market share to make it succeed by default. It's whether Anthropic's userland-orchestration bet produces enough differentiation on complex agents (long-running tasks, tool-heavy workflows, computer use) that developers accept the framework tax to keep flexibility. If the Agents API turns out to run agents materially better than any framework can — better retries, better cost accounting, better failure modes — the framework era ends and we're back to a world where the model provider owns the runtime. If it turns out that agent orchestration is hard enough that server-side loops leave real value on the table, LangChain gets a second life. My money's on the former, but it's not a wide margin.