Frameworks for building AI agents: how to choose your stack

LangGraph’s reported 34.5 million monthly downloads and its approximately 2.2× execution advantage over CrewAI on identical benchmark tasks describe a market that has moved beyond the first question—whether an LLM can call a tool—and toward the operational question: where is agent state stored, replayed, inspected, and constrained when the workflow fails halfway through a production transaction.

That distinction determines the framework choice more reliably than GitHub stars, demo quality, or the number of agents shown collaborating in a product video. Building AI agents is now primarily an orchestration problem. The model supplies inference; the framework defines the control plane around inference: routing, retries, state transitions, tool schemas, observability hooks, human handoffs, and failure containment.

The practical stack is therefore selected from the shape of the workload upward. A low-latency support triage flow, a long-running research pipeline, and an internal procurement agent may all invoke the same frontier model, yet they impose radically different requirements on memory bandwidth, token serialization, concurrency, and approval boundaries.

An agent framework is not an intelligence layer. It is the runtime that decides how expensive, inspectable, and recoverable a model-driven workflow becomes.

Graph orchestration has displaced the linear chain

Early LLM application frameworks were optimized for linearity: prompt, model call, parser, perhaps a retrieval step, then output. That pattern remains adequate for many generative AI software releases, but it degrades when an application must branch, revisit an earlier decision, pause for approval, or resume from durable state after a worker failure.

This is the architectural reason graph-based orchestration has become the reference design for production agentic workflow frameworks.

LangGraph, built within the broader LangChain ecosystem, treats an agent flow as an explicit graph of nodes and edges. A node can invoke a model, execute a tool, evaluate a guard condition, or transform shared state. Edges determine which operation follows, including conditional routing and cycles. The apparent abstraction is simple; the important consequence is that workflow state is not merely embedded in a growing chat transcript.

That matters because token history is a poor database. Re-sending a full conversation history at every step imposes recurring inference cost, creates ambiguous state semantics, and raises latency as the context window expands. LangChain remains the broadest integration layer, with roughly 134,000 GitHub stars and more than 1,000 pre-built integrations, but a chain-oriented implementation can consume more tokens when complete histories are repeatedly serialized into downstream model calls.

LangGraph is the more suitable layer when a system needs any of the following:

• Durable execution state, where an interrupted workflow must resume from a known checkpoint rather than restart a multi-step run.
• Conditional routing, such as escalating only high-confidence fraud signals to a payment tool while sending uncertain cases to a human reviewer.
• Explicit retry semantics, where tool failure, malformed structured output, and model refusal are treated as separate transitions rather than generic exceptions.
• Long-running workflows, where an agent may wait for a human response or an asynchronous data source without retaining an in-memory process indefinitely.
• Traceable state mutation, which becomes material once teams need to establish why a tool was called and which model output altered the workflow’s next state.

CrewAI occupies a different point in the design space. Its core abstraction is role-based collaboration: define agents with responsibilities, tools, and goals, then organize them into sequential or hierarchical crews. This is useful during prototyping because the mental model is compact. A researcher gathers data, an analyst synthesizes it, an editor formats the result. The framework turns an organizational diagram into executable code with relatively little ceremony.

The limitation is not that role-based systems cannot be put into production. It is that role assignment is not equivalent to a state machine. Once a workflow requires idempotency, structured recovery, explicit concurrency control, or audit-grade replay, the hidden orchestration logic must be made visible somewhere. In a graph runtime, that machinery is first-class. In a crew-oriented implementation, it is more often introduced around the abstraction.

The distinction should not be exaggerated into a universal ranking. A two-step content enrichment workflow does not need a graph merely because graph orchestration is fashionable. Conversely, a workflow that can create records, initiate payments, modify cloud configurations, or act on customer data should not be modeled as a conversational theater piece because a “crew” is easy to demo.

Microsoft has consolidated its agent runtime

Microsoft’s October 2025 announcement of the Microsoft Agent Framework changed the company’s platform story in a useful way. AutoGen and Semantic Kernel had represented two partially overlapping approaches: AutoGen supplied conversational multi-agent abstractions, while Semantic Kernel concentrated on enterprise-oriented state management, middleware, plugins, and type-safe application integration.

The Microsoft Agent Framework combines those trajectories into one successor platform. For organizations already running.NET services, Azure infrastructure, Microsoft identity, and typed internal APIs, this is not a cosmetic consolidation. It reduces the cost of choosing between two models of orchestration that were increasingly being deployed side by side.

The relevant comparison is not “Microsoft versus open source.” The more useful question is whether the application’s control plane must sit naturally inside an existing enterprise software estate.

A.NET team building an internal agent that reads governed documents, invokes line-of-business APIs, and emits typed approval objects gains more from framework alignment than from importing a Python-first abstraction solely because it has a larger community. Type safety matters at the boundary between model output and real systems. A JSON-shaped response produced by a model is not a valid business object until it has been validated, normalized, authorized, and passed through policy.

Microsoft’s unified approach is particularly coherent where the runtime must support:

1. Middleware-based interception of agent activity. Logging, policy checks, schema validation, telemetry, and request transformations can be inserted at stable points in the execution path.

2. Typed application contracts. A model may generate candidate arguments, but tool invocation should occur against constrained interfaces rather than free-form text parsing.

3. Enterprise identity and service integration. The agent is usually one component in a larger service topology, not a standalone chatbot process.

4. Hybrid conversational and procedural workflows. Multi-agent dialogue remains possible, but it can be contained within a more conventional application architecture.

AutoGen and Semantic Kernel should therefore be viewed through the migration lens established by the unified framework, not as independent long-term platform bets. The strategic value lies in the merged runtime surface, especially for teams that need agent behavior to coexist with existing software governance rather than replace it.

OpenAI Agents SDK is leaner than a full orchestration platform

OpenAI released its Agents SDK in March 2025. It accumulated more than 26,900 GitHub stars and 10.3 million monthly downloads by mid-2026, indicating substantial developer adoption for a deliberately narrower implementation model.

The SDK is useful when the application already accepts the provider’s model and tool-calling conventions, and the team wants a compact way to define agents, handoffs, tracing, and tool execution without adopting a larger framework ecosystem. Its appeal is reduced integration friction. Fewer layers sit between the application code and the model runtime.

That economy can be beneficial. Every additional framework abstraction introduces its own serialization format, callback model, dependency graph, and debugging surface. For a bounded customer-service router or an internal analyst assistant with three tools, a thin agent SDK may produce lower implementation latency than an enterprise orchestration stack.

But thinness is not the same as completeness. Once an agent must coordinate multiple asynchronous systems, retain durable state over hours or days, enforce business-process transitions, or run under a provider-agnostic model strategy, the application will need to supply more of the runtime itself.

This is the recurring trade-off in AI agent development tools:

For teams asking how to build an AI agent, the correct first move is often to implement the narrowest useful runtime, then identify which failure mode it cannot represent. If an SDK handles the workload with typed tool schemas, traces, and a clear human escalation path, adding an orchestration layer preemptively may only increase operational surface area.

The point at which a prototype becomes a system is usually visible in its state transitions, not in its prompt count.

Costs are dominated by model inference, but framework design still changes the bill

Production cost discussions around agents are often distorted by framework branding. Across deployments handling 1,000 agent requests per day, reported monthly infrastructure costs range from roughly $63 to $171. The underlying LLM selection is the principal variable. Model input and output pricing, context length, tool-call frequency, and retry behavior have more effect on the bill than the framework name in the repository.

Nevertheless, framework architecture determines how efficiently the model budget is consumed.

An agent that appends every observation to a single conversation transcript turns state growth into repeated input-token spend. If each step replays a large history, total inference cost scales with the accumulated context rather than only the information required for the next decision. The result is not merely a cost issue. Larger prompts raise latency, increase the probability of distraction by stale context, and consume scarce context-window capacity that may be needed for actual task data.

The most consequential cost controls are structural:

• Externalize durable facts. Store task records, intermediate artifacts, and tool outputs in application state rather than treating the prompt as a universal memory layer.
• Pass compact state projections. A routing node may need a status code and risk score, not a complete transcript of how those values were generated.
• Constrain retries by failure class. Retrying a transient HTTP failure is rational; repeatedly retrying an invalid tool schema can multiply tokens without improving success probability.
• Use model tiers deliberately. Classification, extraction, and validation often require fewer FLOPs than open-ended synthesis. A high-cost reasoning model should not become the default executor for deterministic transformations.
• Measure tool latency separately from model latency. A slow agent may be waiting on a database, a browser session, or a third-party API. Model optimization cannot repair a blocked network call.

The same analytical discipline applies to tool selection outside AI. A comparison of how crypto portfolio trackers differ is useful precisely because the visible interface rarely reveals the data synchronization, asset coverage, and operational assumptions underneath it. Agent frameworks should be evaluated with the same suspicion toward surface-level feature lists.

Quantization, batching, and accelerator selection matter most for self-hosted inference, where parameter count and memory bandwidth become direct infrastructure constraints. In API-based architectures, those decisions are abstracted behind the provider’s endpoint, but the equivalent application-level variables remain: token volume, concurrency, request queueing, and output length. A framework cannot eliminate those physics; it can only avoid making them worse.

Popularity measures ecosystem gravity, not production suitability

The open-source field has accumulated impressive attention metrics. Dify leads the open-source agent-platform category with approximately 144,000 GitHub stars. LangChain has around 134,000. AutoGen has roughly 58,700, CrewAI about 52,800, LangGraph around 33,900, Semantic Kernel about 28,100, Smolagents about 27,700, Haystack roughly 25,500, Mastra approximately 24,800, and Google’s Agent Development Kit near 20,000.

These numbers are useful, but only as indirect measurements.

Stars indicate developer awareness and repository appeal. Monthly downloads indicate dependency installation volume, though they can be inflated by CI environments, transitive packages, and repeated deployments. Neither metric establishes that a framework handles the specific failure domain of a particular application.

Ecosystem maturity should instead be evaluated as an engineering inventory:

• Does the framework expose trace data that can be correlated with application logs and request identifiers?
• Can a workflow be replayed from a persisted checkpoint without duplicating side effects?
• Are tool inputs validated before execution, not merely described to the model in natural language?
• Can model providers be swapped without rewriting business logic, if portability is a requirement?
• Does the language ecosystem match the services that own the data and tools?
• Is there a credible migration path when the framework’s abstractions change?

LangChain’s more than 1,000 integrations remain meaningful for teams working across vector stores, observability systems, data connectors, and model providers. Integration breadth can materially reduce implementation time. Yet every adapter should be treated as a dependency boundary, not a guarantee of semantic equivalence. A retrieval connector, for example, may expose different filtering, metadata, and consistency behavior across backends even if its method signature is uniform.

Dify belongs in a separate category from code-first runtimes. It is closer to an open-source application platform and visual builder, useful when teams need to assemble, expose, and operate agentic applications with less direct code. That can shorten the path to a beta test AI deployment. It does not remove the need to define state, permissions, data retention, or tool authorization; it changes where those decisions are represented.

Security is outside the framework boundary unless you build it in

The most expensive misunderstanding in the agent market is the assumption that orchestration implies control. It does not.

Agent frameworks provide loops, tool-calling abstractions, messages, state objects, and execution graphs. They do not natively provide out-of-process security controls or pre-dispatch approval gates merely by being installed. A tool definition that says “send invoice” or “delete account” is not a security boundary. It is an invitation for a model to propose arguments.

Production readiness requires an external enforcement plane between model output and side-effecting systems. In practical terms, this means that every consequential tool call should be mediated by software that can validate identity, scope, input schema, policy, and approval status independently of the model’s reasoning trace.

A credible architecture separates at least four layers:

1. Inference layer: model calls produce classifications, plans, structured candidates, or natural-language outputs.

2. Orchestration layer: the framework manages state transitions, routing, retries, and handoffs.

3. Policy layer: deterministic rules evaluate whether a proposed action is permitted for this user, object, environment, and transaction value.

4. Execution layer: narrowly scoped services perform the actual side effect and emit auditable results.

This separation also improves debugging. If an agent proposes an invalid operation, the failure should be recorded as a rejected action at the policy boundary, not buried inside a vague “tool error” in the agent transcript. The agent can then receive a constrained error code and choose a safe next transition. It should not receive unrestricted access to the exception details, credentials, or internal topology of the system it attempted to reach.

Choose the runtime after mapping the workflow

The selection process for building AI agents should begin with a state diagram, even if the final implementation does not use a graph framework. Identify the entry condition, durable state, external tools, irreversible actions, human checkpoints, and terminal states. Then ask which runtime makes those elements explicit rather than implicit.

LangGraph is the strong default for applications where graph structure, recovery, and stateful execution are central. CrewAI remains efficient for rapidly expressing role-based workflows where the operational boundary is modest. Microsoft Agent Framework is strategically aligned for organizations whose agent stack must fit typed enterprise services and Microsoft’s broader application environment. OpenAI Agents SDK is attractive when a focused, provider-native implementation is sufficient and architectural minimalism is an advantage.

No framework resolves model quality, tool reliability, security policy, or data governance on behalf of the application. It can, however, make those constraints visible—or conceal them until the first incident.

The durable decision is not which repository has the most stars. It is whether the framework’s unit of abstraction matches the unit of risk in the product: a message, a role, a graph transition, a typed service call, or a governed business action. In production, that difference determines latency, token burn, recovery behavior, and ultimately whether the agent remains a feature or becomes an uncontrollable subsystem.