Provider-native agent SDKs

What to watch for

The embedded video runs about 48 minutes — longer than most lessons here — because it’s OpenAI’s own team covering the Agents SDK end to end rather than a short third-party explainer; the extra depth is from the source, not padding.

A new category: the provider builds the framework

For a while, if you wanted to build an agent, you reached for a third-party framework — something written by a separate team, designed to work across whichever model you plugged into it. That’s no longer the only option. OpenAI ships its own Agents SDK (and before it, the Assistants API) as a first-party way to build agents against its own models. Google ships its own agent tooling built around Gemini’s function-calling and tool-use capabilities. These aren’t community frameworks that happen to support a given provider well — they’re built by the same organization that trains the model and controls its API, specifically to be the most direct path to an agent running on that model.

Why first-party integration is a genuine advantage

A third-party framework has to work across multiple providers, which means it necessarily abstracts over differences between them — in how each provider formats a tool call, how each handles multi-turn tool use, what each one returns when a call fails or needs clarification. That abstraction is valuable, but it’s also a layer that can lag behind a provider’s own newest capabilities, or smooth over a difference in a way that loses some provider-specific behavior. A provider-native SDK has no such layer to maintain: when the Agents SDK handles OpenAI’s own tool-calling conventions, it’s talking to the API exactly as its own team understands it, often including features or behaviors that haven’t yet been generalized into third-party frameworks at all. For someone committed to one provider who wants the agent working as fast as possible with the least friction, this is a real, not merely marketed, advantage.

Why that advantage comes with a cost

The same tight fit that makes a provider-native SDK fast to build with is what locks you into it. The SDK’s core abstractions — how it represents a tool, how it threads conversation state, how it structures a multi-step agent run — are shaped around that one provider’s specific API design, not around some generic model of what an agent is. Code built this way doesn’t translate to a different provider’s SDK by changing a configuration value; the concepts underneath often don’t line up one-to-one, so porting means re-architecting the agent’s core logic, not swapping an endpoint.

A worked scenario

Imagine a startup building a customer-support agent on OpenAI’s Agents SDK because it’s the fastest way to ship a first version, and it is — the team has a working agent in a fraction of the time a general-purpose framework would have taken, because the SDK’s tool-calling and state-handling line up exactly with the model they’re already calling. Eighteen months later, a new model from a different provider offers meaningfully better quality or pricing for their use case, and the team wants to switch. If they’d built on a provider-agnostic framework like LangGraph, switching providers would mostly mean changing which model the graph calls and retesting — the graph’s nodes, edges, and state don’t know or care which provider sits behind them. Having built directly on OpenAI’s own SDK, the team instead has to re-express large parts of the agent’s structure in terms of the new provider’s primitives, because the original code was never written in provider-agnostic terms to begin with. Neither choice was wrong at the time — the provider-native SDK genuinely got them to market faster — but the tradeoff it carried has now come due.

Making the call

This is a real tradeoff, not a question of which option is more advanced. If a project is firmly committed to one provider for the foreseeable future — because of cost, a specific capability, or an existing relationship — a provider-native SDK is often the fastest, best-supported way to build the agent, and worrying about portability you won’t need is wasted effort. If switching providers is a real possibility, whether to chase quality, pricing, or avoid dependence on one company, a provider-agnostic framework is worth the modest extra effort up front, because the cost of lock-in is paid later, all at once, and usually at a less convenient time than now.