Agent framework vs agent library

"Agent framework" has become a catch-all for anything that helps you build agents, which hides the decision that actually matters: who owns the loop. The classic test from software — a library is something you call, a framework is something that calls you — applies cleanly here. Agent frameworks run the orchestration and invoke your functions; agent libraries are primitives your orchestration calls. Most stack debates ("CrewAI or just the SDK?") are really this question.

Frameworks: you write the agents, they run the society

A framework owns the runtime. You declare agents — roles, tools, goals — and the framework executes the topology: who runs when, what state persists between steps, how a specialist's output reaches the coordinator, what happens on failure. In this catalog: CrewAI's crews and hierarchical processes, LangGraph's stateful durable graphs, Microsoft Agent Framework's graph orchestration, MetaGPT's SOP assembly line, CAMEL's agent societies.

The payoff is real — durable execution, checkpointing, and handoff semantics are genuinely hard to build well, and the framework authors already made the mistakes. The cost is lock-in of a specific kind: not to a vendor, but to a worldview. Your system's control flow is now expressed in someone else's metaphor — crews, graphs, agencies — and porting means re-expressing it.

Libraries: primitives, your loop

A library never owns the loop. Vendor SDKs, the Vercel AI SDK, MCP client libraries, LiteLLM's proxy-as-SDK, Stagehand's act/extract/observe primitives — you call them, collect what they return, and decide what happens next. State, retries, and topology are yours.

That buys portability and comprehension — the whole control flow is in your codebase, reviewable line by line — at the price of rebuilding orchestration every team eventually writes for itself: the retry loop, the tool-call dispatcher, the "which agent handles this" switch. Libraries are the right call when one agent is the product, when you're embedding agentic behavior inside an existing system, or when you expect to outgrow any framework's opinion.

The middle: SDKs with opinions

The line blurs in one direction: libraries shipping orchestration-shaped primitives without taking over your process. The OpenAI Agents SDK is the clearest case — handoffs, guardrails, and sessions are multi-agent-flavored building blocks, but your code still owns the loop; there's no framework scheduler running a crew. BeeAI sits at the other end — a full platform that hosts the loop for you. When classifying something, ask whether you could delete it and keep your program's control flow. If yes, it's a library. If the control flow is the thing, it's a framework.

The quick diff

Who owns the loop

Framework: it calls your code on its schedule (roles, graphs, crews). Library: you call it from a loop you wrote.

State and memory

Framework: checkpoints, shared state, durable execution built in. Library: your database, your choice.

Opinion load

Framework: high — topologies, abstractions, conventions. Library: low — primitives only.

Switching cost

Framework: the orchestration is the product; leaving means rewriting the loop. Library: swap a call site, keep your loop.

Catalog examples

Frameworks: CrewAI, LangGraph, Microsoft Agent Framework, MetaGPT. Library-shaped: OpenAI Agents SDK, Stagehand primitives, MCP client libs.

How to choose

• Prototyping or a single-agent product → library first. The loop is short enough to own, and you'll learn where the framework tax would have been paid.
• Several specialists plus a coordinator, durable runs → framework. Handoffs, shared state, and tracing are the features that hurt to rebuild.
• Cross-vendor or cross-org composition → neither quite covers it; that's what agent-communication protocols (A2A, AGNTCY) are for, and they compose with both.
• Portability is a requirement → library, or a framework you treat as disposable behind a thin internal interface.