How would you choose between LangGraph, CrewAI and a vendor agent SDK?

## Three families, not a ranking The question is asked to see whether you evaluate on requirements or on popularity. There is no best framework; there are three shapes with different centres of gravity, and the honest answer starts by naming what you need from the layer at all. **Graph-based orchestration frameworks.** LangGraph is the reference implementation. You describe the system as a graph — nodes that do work, edges that route between them, state that flows through — and the framework runs it. The distinguishing feature is *durable state*: the run is checkpointed, so it can be paused, resumed after a process restart, rewound, or interrupted to wait on a human. That is what long-horizon production work actually needs, and it is why this family leads in production deployments. The cost is that you must design the graph. For a system whose control flow you cannot describe yet, that upfront structure is friction. **Role- and crew-based frameworks.** CrewAI is the reference. You declare agents as roles with goals and backstories, hand them tasks, and the framework wires up the collaboration. This is the fastest path from idea to something running, which is why it dominates prototyping and internal tools. The tradeoff appears when you need to intervene precisely — enforce a specific ordering, checkpoint mid-run, or take control of a failure path — and find the abstraction is doing things you now want to do yourself. **Vendor agent SDKs.** OpenAI's Agents SDK, Google's ADK, the Claude Agent SDK, and Microsoft Agent Framework all sit here. They are thinner than the generic frameworks, closer to the provider's own primitives, and they expose that provider's newest agent capabilities first. As of mid-2026 they have become a common default starting point rather than an afterthought, largely because the generic abstraction layer buys less than it used to now that the underlying tool and agent primitives have converged across providers. One currency correction worth having ready: **Microsoft AutoGen is in maintenance mode**, its direction folded into Microsoft Agent Framework, with AG2 continuing as a community fork. Recommending AutoGen for a new build signals stale knowledge. ## The criteria that actually decide it **Do you need durability?** If a run spans minutes to hours, calls flaky tools, or must survive a deploy, checkpointed resumable state is close to non-negotiable and it pushes you toward the graph family. If runs are short and idempotent, it is over-engineering. **Do you need a human in the middle?** Pausing for approval before an irreversible action requires the framework to suspend and resume a run, not just to call a callback. Frameworks differ sharply here and it is worth testing before committing. **How much control flow is genuinely dynamic?** If the routing is fixed and known, you may not need an agent framework at all — plain code calling models is more predictable, cheaper to debug and easier to test. Frameworks earn their place when the path through the work is decided at runtime. **Observability.** Long agent runs are undebuggable without traces. Check what the framework emits and whether it follows the OpenTelemetry GenAI semantic conventions, so the traces land in the tooling you already run rather than in a proprietary silo. **Portability versus depth.** A generic framework abstracts providers, which is worth something if you genuinely switch. A vendor SDK gets you that vendor's capabilities sooner and with less indirection. Be honest about how often you actually switch providers — most teams do so far less than the abstraction implies. **Team fluency and ecosystem gravity.** A framework your team can read and debug at 3am beats a marginally better one they cannot. Maintenance status matters too, as the AutoGen case shows. ## What none of them decide for you This is the part that separates a strong answer. Frameworks give you plumbing: state passing, retries, a run loop, tracing hooks, sometimes memory adapters. They do not decide how to split the work, what belongs in each delegation brief, what a worker may return, who holds write authority, or what your budget ceiling is. Those decisions determine whether the system works, and they are identical across every framework in the list. A team that picks LangGraph without an ownership model has a well-checkpointed mess. It is also entirely reasonable to use no framework. Direct provider API calls plus your own loop is a legitimate production choice, and for a system with two agents and fixed routing it is often the better one — fewer abstractions between you and a failure, and nothing to migrate when the ecosystem shifts again. ## How to answer the question in an interview Refuse the beauty contest. State the three families and what each optimizes for, name the two or three requirements that would decide it for the system under discussion — durability, human-in-the-loop, dynamic routing, observability, provider lock-in — and say which way each requirement pushes. Add that the architectural decisions sit above the framework choice, and that you would prototype the riskiest requirement against two candidates rather than argue about it. That answer survives the ecosystem churning again next year, which it will.