Provider SDK or Independent Framework: Pick by Where Your Control Flow Lives

The agent framework landscape in 2026 splits cleanly into two camps. Provider-native SDKs, from Anthropic, OpenAI, and Google, optimised for one model family and shipped alongside it. Independent frameworks, LangGraph, CrewAI, Smolagents, Pydantic AI, AutoGen, that work across providers.

Every comparison article I have read organises around that split, and it is the wrong organising principle. It sorts by vendor relationship when the decision that determines whether you will still like your choice in a year is architectural: where does the control flow of your loop actually live?

There are three answers, they cut across the vendor split, and they have very different consequences.

Architecture one: the model drives the loop

The model gets a set of tools and a goal, and it decides what to call, in what order, and when to stop. Your code provides the tools and runs the loop until the model says it is finished.

This is the shape the provider SDKs are built around, and it is what the Claude Agent SDK is for. Anthropic renamed the Claude Code SDK to the Claude Agent SDK earlier this year, a deliberate signal that the framework targets general agent workloads rather than coding specifically. It is also how most people use the OpenAI Agents SDK, currently at v0.10.2.

It is by far the fastest route from nothing to a working agent, and it degrades gracefully as requirements change. Add a tool and the agent can use it. Change the goal and the agent adapts. There is no orchestration to rewrite because there is no orchestration.

You pay for that in one specific way: the sequence of steps is an output, not a specification. You did not decide that the agent would check the customer record before issuing the refund. The model decided that, this time, for reasons that are not recoverable from the trace beyond the text it generated. Next week, with a slightly different phrasing, it may not.

For a large class of work that is completely acceptable. It is not acceptable when you need to guarantee that a step happens, or prove afterwards that it did.

Architecture two: a graph you declare up front

You define nodes and edges. The model decides what happens inside a node, but the topology, which node can follow which, is yours and it is static.

LangGraph is the reference implementation. It reached 1.0 GA in October 2025, has since moved through v1.0.10, and overtook CrewAI in GitHub stars during early 2026, driven mostly by enterprise adoption. The graph model maps cleanly onto things enterprises need: audit trails, rollback points, explicit state at each transition.

What you buy is the ability to make guarantees. If there is no edge from draft_response to send_email that bypasses human_approval, then no model output can produce that sequence. Not unlikely, impossible. That property is worth a great deal in a regulated environment and worth very little in an internal tool nobody audits.

What you pay is real. The graph is a second artifact that has to stay in sync with your intent, and every new capability is a change to the topology rather than an addition to a tool list. Teams that adopt a graph framework for a problem that did not need one end up with the flexibility of a model-driven loop plus the maintenance cost of a state machine: the worst of both.

Architecture three: ordinary code that calls a model

Your loop is a function. It calls the model, gets structured output, validates it, branches on it with an if, and calls the model again. Pydantic AI sits closest to this philosophically, though you can reach it from any SDK by declining to use the agent loop and just calling the model.

This is underrated, and I think it is the right default for a larger share of production agents than the current discourse suggests.

The reasons are unglamorous. Every debugging tool you own already works. Stack traces point at lines. Tests are ordinary tests. A new engineer reads the loop top to bottom and understands it without learning a framework's execution model. When something goes wrong at 2am, you are reading Python or TypeScript, not reconstructing why a graph took an edge.

The limit is genuine: once branching logic gets complex enough, hand-written control flow becomes a state machine that you did not design and cannot see. When you notice you have implemented retries, checkpointing, and resumability by hand and they are subtly wrong, that is the signal to adopt something that provides them.

The trap is adopting the framework before that point, on the theory that you will need it later. Frameworks are cheap to adopt when the need is real and expensive to carry when it is not.

The lock-in question is smaller than it looks

The standard argument against provider-native SDKs is vendor lock-in. I think it is mostly overstated, and being precise about why matters.

The OpenAI Agents SDK works with 100+ non-OpenAI models. That single fact dismantles most of the portability argument, because the SDK is not a moat, it is a loop plus a tool schema plus some plumbing.

Where switching actually hurts is everywhere except the SDK. Your tool definitions are tuned to how one model family interprets descriptions. Your prompts encode assumptions about a specific model's behaviour. Your evals were built against the failure modes you observed on that model. Your cost model assumes a particular caching behaviour. None of that lives in the framework, and all of it has to be redone when you move.

The practical implication is that "use an independent framework to stay portable" buys less than advertised, while "keep your tool definitions, prompts, and evals as first-class artifacts independent of any framework" buys quite a lot. The portable layer is your harness and your evals, not your SDK choice.

One genuine provider-specific consideration is commercial rather than technical: Anthropic's Claude Agent SDK began drawing subscription usage from a separate monthly Agent SDK credit on 15 June 2026. That is the kind of billing detail that does not change an architecture decision but does change a budget forecast, so check the current terms of any provider-native path before you commit a roadmap to it.

Choosing, in the order that actually resolves it

Work down this list and stop at the first thing that is true.

Do you have to prove what happened, to someone who is not you? A regulator, an auditor, a customer with a contractual right to an explanation, an incident review that will be read by people outside the team. If yes, you need the sequence to be a specification rather than an output, and you want the graph. This is the strongest reason to accept its overhead, and here you should accept it.

Is there a step that must never be skipped or reordered? Approval before an irreversible action, a permission check before a data read, a spend limit before a purchase. You can enforce this without a graph by putting the check in the tool rather than in the loop, which is usually better anyway because it cannot be prompted around. But if the constraint is about ordering across several steps rather than a guard on one, topology is the honest way to express it.

Is the task open-ended enough that you cannot enumerate the steps? Research, exploration, debugging, anything where the right next action depends on what the last one found. This is what model-driven loops are for, and trying to express it as a graph produces a graph with an edge from everything to everything, a model-driven loop with extra steps.

Everything else. Write the loop in ordinary code. Most production agents are three to six steps with a couple of branches, and that is a function. You can always adopt a framework later, and the migration is much easier than people fear because the hard assets, tools and prompts and evals, carry over unchanged.

What I would not choose on

A few criteria that come up in these discussions and should not decide them.

GitHub stars. LangGraph overtaking CrewAI in early 2026 tells you about mindshare and hiring pool, both of which are worth something, and nothing at all about fit for your problem.

Multi-agent support. Nearly every framework advertises it. The question of whether you need multiple agents is separate from and prior to the framework question, and the answer is usually no. A framework that makes multi-agent easy is not a reason to build multi-agent.

Feature tables. Every framework in this space can do streaming, tool calling, structured output, memory, and human-in-the-loop. The differences are in ergonomics and defaults, which a table cannot convey and an afternoon of building a real task in each one can.

The test worth running

If you are still undecided, take one real task from your product, something with a couple of tools and at least one branch, and build it three ways: the provider SDK's agent loop, a small graph, and a plain function. Timebox each to half a day.

You will learn more from that than from any comparison, and you will learn the thing that actually matters, which is not which framework is best but which one your team reads most easily at three in the morning. The framework you choose is a thing your colleagues will be debugging for years. Legibility under stress is a better selection criterion than almost anything on a feature list.