Advanced

The Framework Decision

Three frameworks built the same agent. Now apply the decision matrix. This lesson gives you the honest trade-off table, the twelve-question decision checklist, migration cost analysis, and the signal that tells you to skip frameworks entirely.

✍️ AI School Editorial Team · Lilly Tech Systems 📅 Published Jun 11, 2026 · Reviewed Jun 11, 2026

The Honest Trade-Off Table

Scored on each of the six dimensions from Lesson 1. Scoring is relative (1 = weakest, 3 = strongest on that dimension) based on the implementations in Lessons 4-6:

Dimension	LangGraph	CrewAI	OpenAI Agents SDK
State management	★★★ Built-in typed state + checkpointing + resume	★★ Per-task output storage; no resume primitive	★ Minimal; custom persistence required
Tool execution	★★★ ToolNode with structured error routing	★★ Dispatch built in; string-return constraint is limiting	★★★ Clean function_tool; errors need manual handling
Human-in-the-loop	★★★ interrupt_before/after; first-class suspend-resume	★ human_input flag per task; synchronous only	★★ Requires custom interrupt pattern in Runner
Observability	★★ LangSmith integration; requires account setup	★★ verbose logging; per-task output accessible	★★★ Zero-config tracing built in to OpenAI Platform
Abstraction cost	High (verbose, more code)	Medium (intuitive model, some magic)	Low (thin layer, close to raw)
Ecosystem coupling	LangChain ecosystem (broad, high churn)	Multi-provider, own ecosystem (growing)	OpenAI-first (tight, reliable for OAI stacks)

💡

Scores reflect the benchmark task and mid-2026 framework versions. Frameworks evolve quickly. Re-evaluate these trade-offs when major versions ship. The dimensions themselves (state, tools, HITL, observability, abstraction, coupling) are stable criteria for any future framework evaluation.

The Framework Decision Checklist

Work through these twelve questions. Your answers will point to one or two frameworks - or to the raw API.

✅

Decision Checklist

State & Resumability

☐ Does the agent need to run for more than a few seconds, or resume from partial completion? If yes: LangGraph.
☐ Do you need to inspect, modify, or replay historical agent states? If yes: LangGraph.

Control Flow Complexity

☐ Does the agent have genuinely branching control flow (not just “call tools until done”)? If yes: LangGraph.
☐ Is the agent’s execution model a linear task sequence or parallel workstreams? If yes: CrewAI.

Team Fit

☐ Do non-engineers need to configure or understand the agent’s behavior? If yes: CrewAI (YAML-first).
☐ Does your team think in graphs and state machines? If yes: LangGraph.
☐ Does your team think in job descriptions and team structures? If yes: CrewAI.

Infrastructure

☐ Is your team standardized on OpenAI and wants zero-config tracing? If yes: OpenAI Agents SDK.
☐ Are you running multiple LLM providers or need provider-agnostic code? If yes: LangGraph or CrewAI.
☐ Do you already have LangSmith or another tracing tool in production? LangGraph integrates natively; others can too but with more work.

Complexity

☐ Is this a single-step tool call dressed up as an agent? If yes: raw API.
☐ Will the agent run thousands of times per hour at strict latency budgets? Consider raw or a thin wrapper; framework overhead accumulates at scale.

The Most Common Match

In practice, teams fall into one of three profiles:

Profile	Best Fit	Reason
ML/backend engineers building complex, stateful agents for an OpenAI-optional stack	LangGraph	Explicit control, checkpointing, and multi-provider support justify the verbosity
Product teams building multi-agent workflows where roles map to job functions	CrewAI	Natural fit for task decomposition; YAML config keeps agent definitions readable by non-engineers
OpenAI-standardized teams shipping production agents with minimal framework surface area	OpenAI Agents SDK	Lowest abstraction overhead, zero-config tracing, Pydantic output typing

Migration Cost Analysis

Teams sometimes start with one framework and need to migrate. Here is a realistic assessment of the migration paths, illustrative of relative effort:

Migration	Effort	Key Work
Raw API → any framework	Medium (1-2 weeks per agent)	Wrap tools, add state model, wire error handling
OpenAI SDK → LangGraph	Medium-High (2-3 weeks per agent)	Remodel as state graph; add checkpointing; move to LangChain messages
CrewAI → LangGraph	High (3-4 weeks per agent)	Re-express role/task model as graph nodes; significant rewrite
LangGraph → CrewAI	High (3-4 weeks per agent)	Re-express explicit graph as role/task descriptions; lose checkpointing
OpenAI SDK → CrewAI	Medium (1-2 weeks per agent)	Add agent roles, task descriptions; adapt tool signatures

⚠

The migration trap: Teams that pick a framework because it was easiest to prototype with, then migrate when production complexity grows, pay the migration cost plus the cost of the wrong framework in production. Make the production decision at the start, not after you have a working prototype in the wrong tool.

When to Build Raw

Three signals that a framework is the wrong answer:

The agent is a single tool call. “Run this function and return the result” is not an agent. Using a framework for it adds dependency weight with zero benefit.
You are at the latency floor. Framework abstraction layers add milliseconds per turn. An agent making 100 API calls per second feels this. Profile before assuming it is acceptable.
The framework’s model actively fights your use case. If you spend more time working around the framework than using it, build a thin wrapper instead. The right answer for genuinely novel orchestration patterns is not to torture an existing framework into fitting.

💡 Apply the Checklist to Your Use Case

Think about the next agent you need to build. Work through the twelve checklist questions above and write down your answers:

If your answers point to two frameworks, prioritize the team-fit dimension: a framework that fits your team’s mental model will ship faster and break less in production, even if a different framework scores slightly higher on paper.