Framework Showdown: LangGraph vs CrewAI vs Google ADK vs Managed Agents

Eighteen weeks into this series and we’ve gone deep on four agent frameworks — LangGraph (Post 3–4), CrewAI (Post 5), Google ADK (Post 6), and Claude Managed Agents / Bedrock AgentCore (Post 7). Each made different architectural bets. None is “the winner.” This post is the side-by-side: what each gets right, where each leaks, and how to actually choose.

The bets, in one line each

LangGraph bet on state machines as the right abstraction — primitives for nodes, edges, reducers, checkpointers; control flow you write yourself.
CrewAI bet on roles and crews as the right abstraction — agents with goals and backstories, crews that collaborate, Flows that orchestrate.
Google ADK bet on the runtime as the right abstraction — event-driven engine, multi-language SDKs, Cloud Run / GKE deploy story.
Claude Managed Agents bet on the operator running the agent for you — managed runtime, sandboxed containers, simple billing.

Each abstraction is right for some workloads and wrong for others. The choice is matching the workload to the bet.

The honest comparison

Dimension	LangGraph	CrewAI	Google ADK	Managed Agents
Primary abstraction	State graph	Role + crew	Workflow agent + runtime	Hosted agent
Control flow	Explicit, code	Implicit, role-based	Mixed (workflow + LLM-routed)	Inside the runtime
State	Typed graph state + checkpointer	Pydantic flow state	Session state + memory	Managed by Anthropic
Languages	Python, TS	Python	Python, TS, Go, Java	API (any language)
HITL	First-class (interrupt + resume)	Via Flows	Supported	Built-in
Multi-agent	Subgraphs + supervisor	Hierarchical or sequential crews	Sub-agents + LLM routing	Single agent (compose via A2A)
Tool standard	LangChain tools + MCP	CrewAI tools + MCP	FunctionTool + MCP + Vertex Extensions	Native + MCP + MCP tunnels
Deploy story	DIY (k8s, Cloud Run, LangGraph Cloud)	DIY + CrewAI Enterprise	First-class (`adk deploy`)	Vendor-managed
Observability	LangSmith + OTel	Verbose + OTel	Cloud Trace + OTel	Built-in dashboard
Lock-in	Provider-agnostic	Provider-agnostic	GCP-leaning, provider-agnostic	Claude only
Best at	Complex control flow	People-shaped workflows	Multi-language platform	Fastest path to prod
Worst at	Steeper learning curve	Conditional branching inside crew	Provider neutrality breadth	Customization beyond hosted model

This table is opinionated. Each row has caveats. The dimensions that matter most for your decision depend on your constraints; the matrix gives you a place to start.

The decision tree

Strip the comparison down to the few questions that actually drive choice:

That tree gets most teams to the right answer. The question it doesn’t ask, but should: do you actually need the framework you’re picking, or would a thin wrapper over the provider’s function-calling API do? For very simple agents (one tool, one loop), the answer is sometimes “no framework.” The frameworks earn their keep when state, multi-step planning, or multi-agent coordination is involved.

Composing frameworks

The interesting 2026 shift is that you don’t have to pick one. A few combinations that show up in production:

LangGraph supervisor + Managed Agent workers

The supervisor runs in LangGraph (because you want explicit state and HITL). The workers are individual Claude Managed Agents called via A2A (because you don’t want to operate their containers). Best of both — control flow you own, infrastructure they own.

CrewAI inside a LangGraph node

The outer orchestration is a LangGraph state machine (because you need conditional branches, retries, checkpointing). One of the nodes invokes a CrewAI crew (because that particular sub-task is genuinely a roles-and-handoffs workflow). The crew’s kickoff() returns a string the LangGraph state absorbs.

ADK + LangChain tools

ADK is the runtime. LangChain provides the tool primitives. The Python SDKs interoperate; ADK can call LangChain tools and vice versa. Common when the team already has LangChain tooling but wants ADK’s deploy story.

Managed Agents + AgentCore Identity

Claude Managed Agents for the runtime, AWS AgentCore Identity for the credential/IAM layer. Most useful for teams that want Anthropic’s container model but with AWS’s IAM ecosystem for credential management.

The point: the frameworks aren’t mutually exclusive. They share enough protocol (MCP for tools, A2A for inter-agent, OpenTelemetry for traces) that hybrid stacks work.

What’s worth migrating between

Some honest migration advice for teams who picked a framework and want to move:

LangGraph → CrewAI: rare. People go the other way.
CrewAI → LangGraph: common when you outgrow the role abstraction. You’ll keep your tools and prompts; you’ll rewrite the orchestration. Plan one to two weeks per non-trivial flow.
DIY → Managed Agents: common when the operational burden of your platform exceeds the cost of the managed runtime. Surprisingly fast — the agent logic is portable; the runtime is the work.
Managed Agents → DIY: rare. Usually triggered by a specific constraint (custom scheduling, on-prem requirement) the managed runtime can’t satisfy.

The migration that isn’t worth it: changing frameworks because of a perceived feature gap that’s actually a configuration question. Read the docs first; ask your team second; migrate third.

The 2026 honest take

If I were starting a new production agent today, with no prior commitments:

Default for a single-agent workload: Claude Managed Agents. Two weeks to production, vendor handles infra.
Default for a multi-agent workload with complex control flow: LangGraph.
Default for a multi-agent workload that’s primarily role-based collaboration: CrewAI.
Default for a GCP-heavy organization: Google ADK.
Default for a research-mode prototype: whatever your team knows. Switch later if needed.

None of these is wrong. The picks differ on what you’re optimizing for: time-to-prod, control, ergonomics, or platform fit.

Next week: a full reference architecture — putting eight months of pieces into one diagram and one repo layout for an enterprise agent platform.