The agent framework landscape: lightweight SDKs vs orchestration frameworks

The agent framework space looks impossibly crowded, but it clusters into two categories: lightweight, provider-backed SDKs, and higher-level orchestration frameworks. Sorting any tool into one of those two buckets makes the choice much clearer than comparing them one against another.

Category 1: lightweight, code-first SDKs

These are minimal, unopinionated libraries — usually from a model provider — that hand you the agent loop, tool calling, and handoffs without much ceremony. You write mostly normal code, and the SDK stays thin.

• OpenAI Agents SDK — a small, production-minded successor to Swarm: agents, tools, handoffs, and guardrails, tightly integrated with OpenAI's models and the Responses API.
• Google ADK (Agent Development Kit) — Google's open-source, code-first framework for building and deploying agents, model-flexible and integrated with Vertex AI.
• AWS Strands Agents — AWS's open-source, model-driven SDK: you describe the model, tools, and prompt, and let the model drive the loop; it pairs naturally with Bedrock and AgentCore.

What they share: you stay close to the metal, the abstraction is light, and they lean on their provider's runtime and models.

Category 2: orchestration frameworks

These sit a level up. They bring structure for multi-agent collaboration, complex control flow, and stateful workflows — more concepts to learn, but more done for you.

• CrewAI — models a team of role-playing agents (a 'crew') collaborating on tasks; opinionated and quick for multi-agent division of labour.
• LangGraph / LangChain — LangChain for integrations and building blocks, LangGraph for explicit, stateful, graph-based control over an agent's steps; powerful when you need fine-grained, durable orchestration.

Or: no framework at all

The option the framework debate keeps forgetting is to use none. An agent loop is, at heart, a while-loop around a model that speaks tool calls (see the agent-loops post), and you can write it yourself against the raw provider SDK in a couple of dozen lines. For a simple, well-scoped agent that's often the right call: no abstraction to fight, no framework churn to track, and total control over every token and every tool. Reach for a framework when the plumbing it saves you genuinely outweighs the abstraction it imposes — not as a reflex.

Which category do you need?

• Start in Category 1 when — you want a lean agent close to one provider's stack and you'll own the orchestration in your own code.
• Move to Category 2 when — you need multiple agents coordinating, complex or long-running stateful flows, or graph-level control worth the extra abstraction.
• Watch the trade — lightweight SDKs keep you flexible and legible; orchestration frameworks do more but ask you to adopt their model of the world.

How to actually compare them

Within and across the two camps, compare on the axes that predict production fit — not on GitHub stars or launch-week buzz:

• Control vs convenience — how much the framework does for you, versus how much of what it does you can see and change.
• State & durability — does it persist state and resume a run (checkpointing), or is every run ephemeral?
• Multi-agent support — first-class crews and handoffs, or roll-your-own coordination?
• Provider lock-in — tied to one model or cloud, or genuinely model-agnostic?
• Observability & evals — built-in tracing and testing, or bring-your-own?
• Learning curve & churn — how much you must learn, and how fast the API moves under you.

The market at a glance

• OpenAI Agents SDK — the least ceremony for lean agents on OpenAI's stack.
• Google ADK and AWS Strands — code-first agents that lean into Vertex AI and Bedrock/AgentCore respectively.
• CrewAI — the fastest way to a multi-agent 'crew' with role-based division of labour.
• LangGraph — explicit, durable, stateful control when the workflow is genuinely complex (its companion LangChain brings the integrations).

Two market forces are worth watching. The space is converging on MCP as the standard way to expose tools (see the anatomy-of-an-agent-framework post), so tool investments increasingly port across frameworks. And it churns fast — so pick for the need in front of you, keep your actual agent logic portable, and don't bet the company on any one framework's abstractions.

Don't ask 'which agent framework is best?'. Ask whether you want a thin SDK you drive, or a framework that drives the orchestration for you.