The frameworks disagree about what an agent even is

Four frameworks currently anchor most agentic-system builds, and they disagree at a level deeper than syntax: each one encodes a different answer to "what is the fundamental unit of orchestration." LangGraph says it's a node in an explicit state graph. CrewAI says it's a role with a goal, on a crew. AutoGen says it's a participant in a conversation. Google's ADK says it's a composable agent that can itself contain sub-agents. Picking a framework before understanding which of those four mental models matches your actual problem is how teams end up fighting their tooling for months.

This isn't a feature checklist -- feature parity between these four changes every quarter. It's a comparison of the assumption baked into each one's core abstraction, because that assumption is what survives every version bump and is genuinely hard to work around once a codebase commits to it.

Advertisement

LangGraph: agents as an explicit state graph

LangGraph's unit is a node in a graph, and the graph's edges -- including conditional edges that branch on the current state -- are declared up front. An agent run is a walk through that graph: state flows node to node, each node reads and writes a shared state object, and the graph's shape is inspectable before anything runs. This is the framework most willing to make you draw the whole workflow before you write a line of prompt.

What that buys: the control flow is never implicit. You can look at the graph definition and know exactly which states can lead where, which is exactly the property this site's own agent state machine article argues for when a workflow shape is known and fixed. Cycles (an agent looping back to re-plan) are first-class, not a workaround. Persistence and resumability -- checkpointing the state object mid-run -- are built into the same abstraction, not bolted on.

What it costs: you pay the graph-drawing tax even for simple, mostly-linear workflows, and a genuinely open-ended "figure out the steps as you go" agent (the domain of ReAct-style interleaved reasoning) fights the model, because you're forced to pre-declare transitions for behavior that's supposed to be dynamic. LangGraph is the strongest fit when the workflow's shape is knowable in advance and you want that shape enforced, not merely documented.

CrewAI: agents as roles on a crew

CrewAI's unit is a role -- an agent defined by a persona, a goal, and a backstory, assigned tasks, and grouped with other roles into a crew that executes a process (sequential or hierarchical, with a manager agent delegating). The abstraction is organizational, borrowed directly from how a human team is described in a project brief, and that's deliberate: it's the fastest framework to get a multi-agent demo running in, because "define three roles and describe what each does" maps directly onto how people already think about dividing work.

What that buys: low ceremony for the common case of "a few specialized agents collaborating on a bounded task" -- a researcher role, a writer role, a reviewer role, with CrewAI handling hand-off between them. The role/goal/backstory framing also turns out to be a genuinely useful prompt-engineering forcing function: writing a clear backstory tends to produce a better-behaved agent than writing a bare system prompt, because it forces scope statement.

What it costs: the organizational metaphor doesn't map cleanly onto workflows that aren't naturally role-shaped -- a single agent iterating through a long tool-use loop doesn't benefit from being told it's "a crew of one," and the hierarchical process's manager-delegates-to-workers pattern can become a black box exactly where LangGraph's explicit graph would still be inspectable. CrewAI is the strongest fit for a small number of clearly-differentiated specialist roles collaborating on a bounded, describable task.

AutoGen: agents as conversation participants

AutoGen's unit is a conversational agent, and orchestration is a message exchange between agents in a group chat -- including a human-proxy agent that can inject human input mid-conversation. Multi-agent coordination happens through agents talking to each other in natural language, with a manager (or a configurable speaker-selection policy) deciding who talks next. This is the framework closest to "simulate a Slack channel of specialized bots and let them hash it out."

What that buys: it's a natural fit for genuinely open-ended collaborative problem-solving where the right sequence of who-does-what isn't knowable in advance, and for human-in-the-loop workflows specifically, since a human participant slots into the conversation as just another agent rather than a special external mechanism -- see human-in-the-loop for the general pattern this instantiates well.

What it costs: conversation-as-control-flow is hard to make deterministic and hard to test -- the same setup can converge on a different sequence of turns run to run, which is exactly the property a production pipeline usually wants to minimize (compare against output verification's emphasis on checking results deterministically). AutoGen is the strongest fit for exploratory, research-style multi-agent collaboration where flexibility matters more than reproducibility.

Google ADK: agents as composable, hierarchical building blocks

ADK's unit is an agent that can itself be composed of sub-agents (via sub_agents and AgentTool), with a formal notion of a "skill" as a reusable bundle of tools plus instructions -- distinct from the portable cross-tool skill-file pattern this site covers in its skills section; ADK's skill concept is a framework-internal composition primitive, not a file format meant to move between different agent runtimes. The framework leans into hierarchy: an orchestrating agent can delegate a whole sub-problem to a specialized sub-agent, which itself might delegate further down.

What that buys: clean encapsulation for genuinely hierarchical problems -- a top-level agent that doesn't need to know how a sub-agent solves its piece, only that it can be delegated to, mirroring how a large codebase decomposes into modules with narrow interfaces. It also gives a first-class notion of reusable capability bundles within one codebase, which matters once a team has more than a handful of agents that should share tooling.

What it costs: the hierarchy has to be designed, and a flat problem forced into a hierarchical shape gains layers of delegation overhead for no benefit. ADK is the strongest fit for genuinely nested problems -- and for teams already inside Google's agent/model ecosystem, where the integration surface is deepest.

A decision table, not a leaderboard

None of these four is strictly better; each externalizes a different kind of workflow shape into its core abstraction, and fighting that shape is where the real cost of a wrong choice shows up months in.

FrameworkCore unitBest fitFights you when
LangGraphNode in a state graphWorkflow shape known in advance, needs enforcement + resumabilityWorkflow is genuinely open-ended / exploratory
CrewAIRole on a crewA few clear specialist roles, bounded taskWork isn't naturally role-shaped
AutoGenConversation participantOpen-ended collaboration, human-in-the-loopYou need deterministic, reproducible runs
ADKComposable hierarchical agentGenuinely nested sub-problems, shared tool bundlesThe problem is actually flat

A practical filter: if you can already draw the workflow as a flowchart with defined transitions, LangGraph will feel like the natural expression of what you already know. If you're describing the system as "a few people with different jobs," CrewAI's metaphor will fit without translation. If you don't yet know the right sequence and want agents to figure it out together, AutoGen's conversational model is built for that uncertainty. If the problem is naturally a tree -- a top-level concern that delegates cleanly to independent sub-concerns -- ADK's composition model is the one that won't fight you.

Advertisement

These four frameworks encode four different assumptions about what an agent workflow looks like -- a graph, a crew, a conversation, or a hierarchy -- and that assumption, not the feature list, is what a codebase actually commits to. Match the framework's core abstraction to your problem's real shape before evaluating anything else.