Agent frameworks compared

Why it matters

The agent loop is about fifty lines: send messages and tool definitions, read the stop reason, run the tool, append the result, repeat. A framework wraps those lines in a few hundred thousand more. That can buy durability a team would otherwise write badly, or hide the prompt and turn a wrong answer into a two-day debugging session. Interviewers ask which framework you would use because the honest answer shows whether you know what the loop is, what a framework adds, and what it takes away.

The idea

What a framework gives you

The loop, so you do not write it. State that survives a step. Tool wiring from a function signature to a schema and back. Streaming of tokens and tool events to an interface. Persistence, so a run can pause and resume. Tracing hooks, so each step lands in an observability tool.

What it costs

Abstraction over the prompt: the framework assembles the system prompt, the tool descriptions and the history, and what the model sees is no longer what you wrote. Debugging gets harder for the same reason: a wrong answer could come from your code, the prompt assembly, a retry policy or state handling. Churn: a major version can rename the core abstractions. Anthropic's advice, which this track follows, is to start with the model API directly and add abstraction when a concrete need appears.

Four shapes

Graph-based. You declare nodes (a step that calls the model or a tool) and edges (which step follows which). The graph is explicit, so a run can be checkpointed at any node and resumed or replayed. LangGraph is the reference example, with LangChain beneath it for components. Good for workflows with known structure and anything that must survive a crash or a week-long pause.

Loop-based SDKs from model providers. A thin layer over the provider's API: an agent is a model, instructions and tools; a run is the loop; handoffs pass control between agents. The OpenAI Agents SDK, the Claude Agent SDK and Google's ADK sit here. Little hidden, easiest to debug, and tied to one provider unless the SDK abstracts it.

Role-based multi-agent. A crew of named roles, each with a goal, a persona and tools, handing work along a process. CrewAI is the well-known one; Microsoft's AutoGen and Semantic Kernel offer multi-agent orchestration in a similar spirit. Fast to prototype; the roles are prompts you did not write, and control flow lives in the conversation.

Minimal code-agent libraries. A small core where the model writes code that calls tools. Hugging Face's smolagents is the example. Tiny, transparent, strong for data tasks, and it needs the sandbox the Code execution and sandboxes lesson describes.

The choosing rule

Start with the model API and your own loop. Add a framework when one of three needs appears: durability, because runs must pause for a human or survive a restart; multi-agent structure, because several loops must hand work to each other in a defined way; or team conventions, because a team needs one way to write agents. If none applies, the framework is cost without benefit.

Lock-in and exit cost

The exit cost is the number of places the framework's abstractions touch your code: prompts in its template language, state in its checkpoint format, tools registered through its decorators, traces in its schema. Keep the exit cheap: own your prompts as plain strings, define tools as plain functions with the schema beside them, and keep evaluation outside the framework. Tools behind an MCP server and peers behind A2A outlive whichever framework drives the loop this year.

Evaluating one in a day

Morning: build the smallest real task from your product with the bare API and keep the transcript. Midday: build the same task in the framework. Afternoon: print what the model receives on each step and compare; break a tool and see how the error surfaces; kill the process mid-run and see what resumes; check the trace. If you cannot see the prompt or cannot resume, you have your answer.

	Graph-based	Provider SDK	Role-based	Minimal code agent
Control	Explicit nodes and edges; you own the flow	You own the loop's inputs; the SDK owns the loop	The conversation decides; roles are prompts	Model writes the control flow as code
Durability	Checkpoint at any node; resume, replay	Session state; durability is yours to add	Little; a run is a conversation	Little; a run is a script
Learning curve	Highest: graph, state schema, checkpointers	Lowest if you know the API	Low to start; hard to steer later	Low; small surface
Lock-in	State format and graph DSL	One provider, unless abstracted	Role and process abstractions	Minimal; near plain code