Choosing an Agentic AI Framework: LangGraph, CrewAI, OpenAI SDK, ADK

Picking an agent framework in 2026 feels harder than it should. Search for one and you meet LangGraph, CrewAI, the OpenAI Agents SDK, Google's Agent Development Kit, the Claude Agent SDK, AG2, PydanticAI and a handful more, each presenting itself as the sensible default.

That confusion isn't a research failure on your part. The space has fragmented, and the choice is closer to a philosophical one than a technical one, because each framework bakes in a different opinion about how much control you should keep over an agent's execution and how agents should talk to each other. A line from an IBM explainer captures the better way to approach it: stop asking which framework is best, and ask what kind of agentic system you're building.

What follows is aimed at mid-level and lead developers and architects who already know what an agent is: a model with tools, instructions and some memory that can take more than one step toward a goal. It assumes you can read Python and have tried at least a single-agent tool-calling loop. It sorts projects into five shapes, then compares four orchestration philosophies, then shows three minimal code samples so you can feel the difference in programming model before committing a codebase.

What a framework actually saves you from

You can build an agent without any framework for a demo. A few problems come back in nearly every serious system, though, and a framework mostly exists so you don't re-solve them:

• The reasoning loop. Call the model, run whichever tools it picks, feed the results back and repeat until a stop condition fires.
• State and memory. Keep context across steps and, for longer-lived agents, across process restarts.
• Coordination between agents. Decide how agents find each other, hand work over and share or isolate state.
• Observability. See why an agent did what it did. That hardly matters in a demo and matters enormously once something breaks in production.

All the frameworks here cover these four areas. They differ in how strongly they push their own answer.

Start from the use case

Before comparing features, ask what you're really building. Five categories cover most projects, and each suggests a different shortlist.

• Linear workflows. Steps run in a predictable, mostly fixed order: a support agent searches a knowledge base, drafts a reply and perhaps opens a ticket. No one needs agents debating anything here. You need reliability. LangChain suits sequences, LlamaIndex suits retrieval-heavy work and LangGraph earns its place once the sequence needs conditions or loops.
• Autonomous multi-agent teams. The goal is handed over and a group of agents negotiates the route, for instance a planner, a coder and a reviewer sharing a programming job. These problems are open by nature. AG2 (the maintained successor to AutoGen) and CrewAI are the usual candidates.
• Role-based systems. Similar, except each agent stays inside a clearly defined job, say researcher, writer and editor, instead of improvising. CrewAI is the natural fit, along with niche tools such as ChatDev for software-development role play.
• Production orchestration. Here the system has graduated to real APIs, databases and business processes, such as an operations agent that triages alerts, consults runbooks and executes fixes. Candidates include LangGraph, Google ADK and Microsoft's Agent Framework, which folded in AutoGen and Semantic Kernel. All three are designed with durability and deep integration in mind.
• Rapid prototyping. At times you only want a fast yes or no on an idea. Drag-and-drop builders like LangFlow and Flowise let you sketch a flow on a canvas before any code exists.

Sorting like this turns "which framework?" into something smaller. Is the pipeline predictable, exploratory, bounded by roles, heading to production, or merely a hypothesis?

Four ways frameworks model coordination

Within a shortlist, frameworks still differ in how they represent coordination. Broadly they follow one of four philosophies.

• Graph-based. Agents and logic are nodes in a directed graph, and explicit edges, conditional or cyclic, decide what runs next. LangGraph is the clearest case. You're effectively defining a state machine.
• Role-based. Each agent is a team member with a role, a goal and a backstory, while a process layer above decides how tasks move among them. CrewAI is organised around exactly this idea.
• Handoff-based. A few primitives, namely an agent, its tools and the ability to pass the conversation to another agent, are exposed with little ceremony. The OpenAI Agents SDK works this way.
• Hierarchical. One root agent hands work to sub-agents arranged as a tree, running locally or as remote services. Google's ADK takes this route.

No philosophy wins outright. Your choice should follow your team's existing mental model of the problem and the amount of explicit control over execution paths you actually want.

Where a framework sits in the stack

Every framework sits on top of one or more model providers and manages the reasoning loop. On top of that comes tool calling, which is increasingly standardised through MCP. Reports say it has been stewarded by the Linux Foundation's Agentic AI Foundation since December 2025, and each framework here speaks it in some form. When agents must talk across process or service lines, the Agent2Agent (A2A) protocol is rising as a similar standard, with built-in support in ADK and more arriving elsewhere.

Below sits state persistence, such as LangGraph's checkpointing to a database or a simple in-memory chat history, and an observability layer, such as LangSmith for LangGraph or built-in tracing in the OpenAI Agents SDK. Those matter far more once an agent faces real users than they do in a notebook. None of these frameworks is tied to a particular cloud. The OpenAI Agents SDK and Google ADK lean naturally toward their own vendors' models, while LangGraph and CrewAI aim to stay model-agnostic.

Three minimal examples

The snippets are deliberately tiny. They show each framework's programming model and are not production systems. Package names and install steps change quickly in this area, so check each project's current documentation first.

LangGraph: a two-node graph

# pip install langgraph
from langgraph.graph import StateGraph, END
from typing import TypedDict

class State(TypedDict):
    question: str
    answer: str

def research(state: State) -> State:
    state["answer"] = f"Researched: {state['question']}"
    return state

def write(state: State) -> State:
    state["answer"] = f"Written up: {state['answer']}"
    return state

graph = StateGraph(State)
graph.add_node("research", research)
graph.add_node("write", write)
graph.set_entry_point("research")
graph.add_edge("research", "write")
graph.add_edge("write", END)

app = graph.compile()
result = app.invoke({"question": "What is agentic AI?", "answer": ""})
print(result["answer"])
# Output: Written up: Researched: What is agentic AI?

The code defines a typed state shared between nodes, adds two nodes as ordinary Python functions and joins them with an explicit edge. Nothing here calls an LLM. LangGraph is intentionally neutral on that, so you plug in whichever model client you like at each node.

CrewAI: a two-agent crew

# pip install crewai
from crewai import Agent, Task, Crew

researcher = Agent(
    role="Researcher",
    goal="Find accurate information on the given topic",
    backstory="An experienced analyst who values accuracy over speed."
)

writer = Agent(
    role="Writer",
    goal="Turn research into a clear summary",
    backstory="A technical writer who favours plain language."
)

research_task = Task(
    description="Research agentic AI frameworks",
    expected_output="A short list of key considerations",
    agent=researcher
)

write_task = Task(
    description="Summarise the research for a developer audience",
    expected_output="A concise paragraph",
    agent=writer
)

crew = Crew(agents=[researcher, writer], tasks=[research_task, write_task])
result = crew.kickoff()

There are no nodes or edges to wire. Two agents are described by role and goal, and each is given a task. The crew's default process runs tasks one after another, passing each output to the next. CrewAI is doing the coordination that LangGraph would make you model explicitly.

OpenAI Agents SDK: passing a conversation between agents

# pip install openai-agents
from agents import Agent, Runner

billing_agent = Agent(
    name="Billing",
    instructions="Handle billing questions concisely."
)

triage_agent = Agent(
    name="Triage",
    instructions="Answer general questions; hand off billing questions to Billing.",
    handoffs=[billing_agent]
)

result = Runner.run_sync(triage_agent, "Why was I charged twice this month?")
print(result.final_output)

In the sample, a triage agent is told about a single other agent it may pass work to. If the model decides a message is about billing, the SDK's runner moves the conversation to the billing agent on its own. No graph, no role metaphor: only agents plus the tools and handoffs they can use. Google ADK looks alike at this size, a root agent with sub_agents, yet its sub-agents make up an explicit tree that can include remote agents over A2A, whereas the handoff list above is flat.

Matching each framework to your situation

Reach for LangGraph when:

• your workflow has loops, retries or conditional branches you want to model explicitly;
• you need durable state that survives a restart, or time-travel debugging;
• your team already uses LangChain components.

Reach for CrewAI when:

• the problem divides naturally into roles, and that framing helps people outside engineering follow along;
• you'd like something running within hours;
• you accept moving critical pieces onto a lower-level framework if role-based sequencing stops being enough;

Reach for the OpenAI Agents SDK when:

• you're building mainly on OpenAI models and want the thinnest sensible layer over the reasoning loop;
• your coordination need is plain delegation among a few specialists.

Reach for Google ADK when:

• you already work in Google Cloud or the Gemini ecosystem;
• agents will span teams or services, a setting where A2A's remote-agent model is a good match.

Look elsewhere when:

• type safety matters more than orchestration flexibility, in which case PydanticAI, which validates agent inputs and outputs against Pydantic models, may beat all four;
• you're at the prototype stage of one of the five use cases, in which case LangFlow or Flowise before any framework code is a better start.

Mistakes teams make

• Choosing before defining. Teams grab whichever framework has the most stars and squeeze the problem into it. Naming your category first usually makes the shortlist obvious, far more so than reading four sets of documentation.
• Ignoring switching costs. Prompts, agent logic and orchestration patterns seldom port cleanly. If you suspect you'll outgrow the first choice, plan for a partial rewrite and don't count on a quick swap.
• Postponing observability. Tracing and evaluation are easy to defer while prototyping and painful to retrofit once an agent handles real traffic. Switch on whatever tracing your framework offers from day one.

Your next moves

• Decide which of the five categories your project falls into before opening any framework's docs: linear, autonomous multi-agent, role-based, production orchestration or rapid prototype.
• Install one framework above and rebuild a toy example using your own use case instead of the one shown.
• Look for existing MCP tool servers for the systems you must connect, and skip hand-written tool glue where one exists.
• Agree a switch-over rule up front, such as moving to LangGraph once branching passes three conditions.

The short version

Before asking which framework is best, ask which of five familiar shapes describes your project: a predictable linear flow, an open-ended autonomous team, a role-bound crew, a production orchestration job or a prototype-stage idea.

Answering that cuts the field down before any feature table is opened. After that, what remains is mostly a matter of philosophy. Choose LangGraph for explicit control of branching, CrewAI for role-based thinking and fast iteration, the OpenAI Agents SDK for simplicity on OpenAI models and ADK if you already live in Google's ecosystem. MCP and A2A are settling in as common standards for tools and agent-to-agent traffic, so changing course later should hurt a little less, though it will never cost nothing.