Main area
Agency
ki-werkzeuge

Agent Frameworks at a Glance

Redaktion ·

You want to build an agent — and you are drowning in framework names

Anyone setting out to build an agentic system in 2026 faces an overcrowded shelf: CrewAI, AutoGen, AutoGPT, DSPy, Browser Use, LangGraph — plus the SDKs from the model vendors (OpenAI Agents SDK, Google ADK, Claude Agent SDK) and a dozen smaller projects. The temptation is to grab the loudest name and start coding. That backfires, because these tools do not all solve the same problem. Some orchestrate multiple agents, one optimizes prompts, one drives a browser, and one is more of a demo project than a production framework.

This article sorts the field. You will learn what an agent framework actually does, how it differs from “tool use” and from a finished agent, and you will get an honest assessment of each of the six tools above: what it does, how mature it is, when to pick it. If you first want to understand how an agent works internally, read Building AI agents — here we assume the mechanics (agent loop, tool call, stop condition) are already familiar.

Keep three levels apart: tool use, agent, framework

Before we compare anything, three terms that get constantly conflated need to be separated.

Tool use is the mechanism

Tool use (also called function calling) is a model’s ability to call an external tool in a structured way. You describe a tool to the model as a JSON schema, the model replies with a tool call plus arguments, your code executes it and feeds the result back. That is a feature of the LLM API, not a framework. Tool use is the ingredient agents are built from — but on its own it is not yet an agent.

The agent is the running system

An agent decides at runtime which tools to call and when, how often the loop spins, and when it is done. The difference from a deterministic workflow is the control logic: in a workflow your code fixes the order, in an agent the model makes the steering decisions. So an agent is the concrete running thing — not the toolbox you built it with.

The framework is the toolbox

An agent framework is a library that takes the recurring plumbing off your hands: the agent loop, tool registration, memory (conversation history, optionally a vector store), coordination of multiple agents, and often observability. You could write all of that yourself — for a single agent with three tools that is in fact often the better choice. But as soon as multiple agents collaborate, state has to persist, or a human needs to step into the loop, hand-rolling gets expensive and a framework starts to pay off.

What an agent framework concretely delivers

Across the projects, the same four areas of responsibility keep showing up. They are how the frameworks differ from one another.

Orchestration. Driving the agent loop and — with multiple agents — deciding who goes when. This is where the biggest differences sit: from free conversation between agents (AutoGen), through role-based teams (CrewAI), to explicitly modeled graphs with nodes and edges (LangGraph).

Tool integration. How easily you register your own functions, APIs or MCP servers as tools. Almost all of them now support the Model Context Protocol as a shared tool standard.

State and memory. Short-term memory (the message list of the running task) and long-term memory (vector store, external DB). The decisive question for production: can state be persisted and restored — for example to resume an interrupted task or roll a step back?

Observability and human-in-the-loop. Tracing every tool call, measuring cost, and the ability to pause at defined points for human approval. This is the area that separates “demo” from “production”.

The six frameworks in detail

A maturity caveat up front: the star counts and version numbers below come from web sources dated spring 2026 (see Sources) and age quickly. Treat them as a snapshot, not a fixed quantity.

LangGraph — the graph for production

LangGraph models the agent as a graph: nodes are work steps, edges are the control flow, and state moves explicitly through the graph. That is more boilerplate than its competitors, but it gives you exactly the control production systems demand: checkpointing, resumption after a crash, rollback points and cleanly defined human-in-the-loop stops.

According to the researched sources, LangGraph reached version 0.4 in April 2026 with improved state persistence and human-in-the-loop checkpoints, and overtook CrewAI in GitHub stars. Together with its in-house observability (LangSmith), it is regarded as the most production-ready of the frameworks listed here. More on the graph idea in the glossary entry LangGraph.

Pick it when you need a stateful system that keeps running after a crash, that produces audit trails, and where a human approves at fixed points. Skip it when you only want a simple single-agent prototype — then the graph overhead is unnecessary.

CrewAI — role-based teams

CrewAI thinks in crews: you define agents as roles (“researcher”, “writer”, “editor”) with goals and a backstory, assign them tasks and let them produce a result. It is the most intuitive model for multi-agent prototypes — the abstraction reads almost like a job description.

According to the sources, CrewAI has added enterprise observability and scheduling for multi-agent coordination, is listed at over 44,000 GitHub stars and is (per one of the sources) in use at many Fortune 500 companies — such adoption figures come from marketing-adjacent sources and should be read with caution. It continues to be actively developed.

Pick it when you want to quickly assemble a team of specialized agents and the role model fits your task. Skip it when you need fine-grained control over every step and hard persistence — then the graph approach fits better.

AutoGen — conversation between agents

AutoGen (Microsoft Research) builds multi-agent systems as conversation: agents send each other messages, one agent can generate code, another execute it, a third check the result. Strong for complex, research-leaning scenarios where the interaction cannot be squeezed into a fixed graph.

According to the sources, AutoGen reached 1.0 GA with the v2 API as the default. Important context: Microsoft has moved AutoGen into maintenance mode and is shifting further development into the broader Microsoft Agent Framework. For new production projects that means: check whether you should orient yourself toward the successor right away.

Pick it when you are studying research-leaning multi-agent conversations with code execution. Skip it when you need long-term maintainability for a production system — the maintenance status is a real risk.

AutoGPT — the autonomous pioneer

AutoGPT popularized the phrase “autonomous agent” in 2023: a goal-driven system that sets its own subtasks, searches the web, writes code, manages files. With around 170,000 GitHub stars it is one of the best-known AI projects of all. The 2026 version relies, per the sources, on a visual workflow builder, a marketplace for agent templates and a plugin architecture.

Context: AutoGPT is historically and conceptually important, but it counts less as a sober production SDK and more as an accessible platform and learning object for autonomous agents. The early fascination (“set a goal, let it run”) quickly hit limits — endless loops, high token cost, brittle results. Those lessons still shape why mature frameworks bet on control rather than maximum autonomy.

Pick it when you want a platform with a visual builder and want to experiment with autonomous agents. Skip it when you need a lean framework embedded in your own code.

DSPy — not an orchestrator, but prompt optimization

DSPy (Stanford NLP) is the odd one out, because it is not an orchestration framework. Instead of writing prompts by hand, in DSPy you describe the task declaratively as signatures and modules — and optimizers like BootstrapFewShot, COPRO or MIPROv2 automatically search for the best prompts and few-shot examples for your model. DSPy does ship some agent building blocks (ReAct loops), but its core is optimization, not coordination.

According to the sources, DSPy sits at roughly 34,700 GitHub stars, is vendor-agnostic (OpenAI, Anthropic, Gemini, Ollama and others) and shipped GEPA, an optimizer presented as an Oral at ICLR 2026.

Pick it when you want to systematically improve prompt quality instead of tinkering by hand — even alongside one of the other frameworks. Skip it when you mistake it for a multi-agent orchestrator; it is not built for that.

Browser Use — the browser specialist

Browser Use solves exactly one problem: letting an agent operate a real website — click, type, scroll, fill in forms. It makes web pages accessible to models and is therefore not a general-purpose orchestrator but a tool for web automation. You typically combine it with one of the other frameworks when your agent needs to use the web not just via API but like a human in a browser.

According to the sources, Browser Use sits at roughly 78,000 to 95,000 GitHub stars (figures vary by source and date), came out of the Y Combinator Winter 2025 batch and shipped, among other things, SOC 2 Type 2 compliance, a desktop app and version 2.1 in 2026.

Pick it when your agent has to operate websites without an API. Skip it when your targets offer clean APIs — an API call is more robust and cheaper than browser control.

Comparison at a glance

| Framework | Category | Strength | Maturity note (spring 2026) | |-------------|----------------------------|---------------------------------------|--------------------------------------| | LangGraph | Orchestration (graph) | persistence, rollback, human-in-loop | v0.4, seen as most production-ready | | CrewAI | Orchestration (roles) | fast multi-agent prototypes | active, ~44k stars | | AutoGen | Orchestration (chat) | research-leaning multi-agent chats | 1.0 GA, now in maintenance mode | | AutoGPT | autonomous platform | visual builder, pioneer status | ~170k stars, more a platform | | DSPy | prompt optimization | automatic prompt/few-shot search | ~34.7k stars, active | | Browser Use | browser automation | real website operation | v2.1, YC W25, ~78–95k stars |

Pitfalls when choosing a framework

Picking a framework before the problem was clear. The most common mistake. First analyze the task (one agent or several? persistence needed? browser needed? approval steps?), then the tool.

Confusing orchestrator and optimizer. “Comparing” DSPy against LangGraph is like comparing a screwdriver against a power drill — they solve different problems and can be combined.

Confusing maturity with stars. GitHub stars measure popularity, not production readiness. Maintenance status (AutoGen), persistence capability and observability say more about fitness for a live system.

Taking multi-agent as the default. More agents mean more tokens, more latency, more failure points. Often a well-built single agent or a fixed workflow solves the same task more robustly.

FAQ

What is the difference between an agent framework and tool use?
Tool use is the mechanism a model uses to call a single external tool — an API function. An agent framework builds on top of it and handles the surrounding plumbing: agent loop, memory, coordination of multiple agents and observability.
Which framework should I pick for a production system?
For stateful production systems with persistence and approval steps, LangGraph is regarded as the most mature choice. For fast role-based multi-agent prototypes, CrewAI is more pleasant. Since its move into maintenance mode, AutoGen should be approached with caution for new projects.
Is DSPy a competitor to LangGraph or CrewAI?
No. DSPy optimizes prompts and few-shot examples; it does not orchestrate agent teams. You can even use DSPy for prompt optimization in addition to an orchestration framework.
What do I need Browser Use for?
When your agent has to operate a website that lacks a usable API — clicking, typing, filling in forms like a human. If the target offers an API, a direct API call is more robust and cheaper.
Do I even need a framework?
Not necessarily. For a single agent with a few tools, hand-rolling is often the clearer and more debuggable solution. Frameworks pay off as soon as multiple agents collaborate, state has to persist, or a human needs to step into the loop.

Conclusion

Agent frameworks do not all solve the same problem. LangGraph, CrewAI and AutoGen orchestrate agents — with different philosophies (graph, roles, chat) and different maturity. AutoGPT is more platform and pioneer than sober SDK. DSPy optimizes prompts instead of coordinating agents. Browser Use is the specialist for the real web. The useful order stays the same: first cut the problem, then choose the level (orchestration, optimization, browser), then the concrete tool — and honestly check whether it needs to be an agent at all.

Themenuebersicht

KI-WerkzeugeAgenten-Frameworks