I checked what popular agent software actually uses

There are many posts comparing agent frameworks. Most explain the same tools and show similar diagrams. But I could not find much data on what popular agent software actually uses.

So I checked.

I collected 703 GitHub repositories with at least 300 stars. They came from topics such as ai-agents, ai-agent, llm-agent, and agentic-ai, along with a search of repository descriptions.

For each repository, I read its dependency files using the Git trees API. This also found dependencies hidden inside folders such as api/ or backend/ in monorepos. I then classified each repository as an app, a framework or library, or content such as tutorials and books.

I also wanted a rough sign that people were using these projects in production. For that, I counted how often the words "in production" appeared in each repository’s issues. I adjusted the number per 100 issues so repositories with more issue activity did not automatically score higher.

All data and scripts for this study are public. The link is at the end.

The common claim I wanted to test was simple: agent frameworks are good for demos, but real production agents are just loops around an API call.

I found five things. Two of them surprised me.

1. Many repositories tagged as agents are not agent apps

Of the 703 repositories, 552 were apps, 104 were frameworks or libraries, and 47 were content such as tutorials, books, and awesome lists.

Only about half of the apps had an LLM dependency I could detect.

Some large repositories in the group without an LLM dependency were Airbyte, Apache Doris, Nx, and Kestra. These are a data pipeline, a database, a build tool, and a scheduler. They do not call an LLM.

They appear in agent searches because they describe themselves as infrastructure for AI agents. GitHub topics are chosen by repository owners, so they are not a reliable way to identify agent software.

I manually checked 20 apps from the group where no LLM dependency was detected. About half were real agents written in Rust or Go, or they called model providers through plain HTTP. About a quarter were tools for agents, such as MCP servers and dashboards. The rest were general infrastructure using agent-related labels.

GitHub topic search mainly tells us how popular the word "agent" has become. It does not give us a clean list of agents.

2. Apps use libraries more often than full frameworks

I found 257 apps with an LLM stack that I could identify. Of these, 145 used only model clients and libraries such as the Anthropic or OpenAI SDKs, LiteLLM, or Ollama. The other 112 used something described as a framework.

Raw SDKs and libraries were more common than all the frameworks combined. The true share is probably even higher because the undetected group includes apps written in Rust and Go, as well as apps that use plain HTTP.

Here is the breakdown:

• Vercel AI SDK: 43 apps
• LangChain components only: 35 apps
• LangGraph: 30 apps
• Full LangChain framework: 26 apps
• LlamaIndex: 10 apps, 7 using the full framework and 3 using components
• OpenAI Agents: 10 apps
• AutoGen: 7 apps
• CrewAI: 5 apps

Three things stand out.

First, more apps use parts of LangChain than the full framework. I found 35 apps that only use packages such as langchain-core, langchain-text-splitters, or LangChain’s provider clients. Only 26 use the full framework.

A simple dependency scan would label projects such as browser-use, graphiti, and hindsight as LangChain apps. A closer look shows that they only kept some useful parts.

Second, LangGraph is now more common than LangChain among these apps, with 30 apps using LangGraph and 26 using the full LangChain framework.

Third, the most widely used item in the table is not an agent framework. The Vercel AI SDK is mainly a model client and streaming library. It does not manage an agent’s workflow.

CrewAI and AutoGen are both very popular framework repositories, but I found them in only 5 and 7 popular apps. A framework’s GitHub stars do not tell us how often apps depend on it.

3. Production apps use frameworks more often than expected

I called a repository production-grade when it met three conditions: at least 2 mentions of "in production" per 100 issues, CI, and tests. I called it POC-like when it had fewer than 0.5 production mentions per 100 issues.

Frameworks appeared in 25% of the production-grade group and 15% of the POC group.

Apps using frameworks also had a higher median rate of production discussion. They had 1.19 production mentions per 100 issues, compared with 0.70 for apps using raw SDKs. Framework use was also higher in organization-owned repositories than in personal repositories, 48% compared with 39%.

This does not support the strong claim that teams remove frameworks when they move to production.

But the type of framework matters. Of the 19 production-grade apps using frameworks, six used LangGraph. RagFlow, for example, pins LangGraph to version 1.2.0. Most other frameworks appeared only once.

The tools that seem to survive in production are focused graph runtimes and client libraries, not large frameworks that try to handle everything.

There is another number worth noting. Across 545 apps, the median number of issues mentioning "in production" was just one. Half of these popular repositories had one or no issues that mentioned production use.

Stars show interest. They do not necessarily show real use.

4. Frameworks are rarely the main problem in app issue trackers

I checked how often an app’s issues mentioned the framework it uses.

The median was 1.4% of issues. Only a quarter of the apps had framework mentions in more than 5% of their issues. The higher numbers often came from projects closely tied to the framework itself, such as Google’s agents-cli using Google’s ADK.

I also read 439 sampled issue titles. The most common words were ordinary ones: "error" appeared 43 times, "support" 34 times, and "integrate" 31 times. Only about 2.5% used words related to migration.

The recurring framework problem was version churn. Users reported deprecation warnings, breaking upgrades, and the need to pin versions.

The issue trackers do not show large numbers of teams trying to remove their frameworks. Most teams simply want the frameworks to change less often.

5. Search results can be confidently wrong

For the last part of the study, I searched GitHub issues for titles such as "remove X," "replace X," and "migrate away from X."

My first results showed about 190 issues for LangChain, 89 for LangGraph, 70 for the Vercel AI SDK, 52 for AutoGen, and 59 for Haystack.

Those numbers looked useful, but some were badly wrong.

When I read a sample of the issue titles, I found that many AutoGen results referred to GNU autogen.sh or auto-generated files. Many Haystack results used the normal English word “haystack” and had nothing to do with the framework.

I repeated the search with specific package names such as pyautogen, autogen_agentchat, and haystack-ai. AutoGen’s count fell from about 52 to 2. Haystack’s fell from about 59 to 3.

The first search was wrong by about 25 times. It still looked completely believable.

The LangChain results were real, but many were about removing only part of it. Examples included removing langchain-community or replacing langchain-text-splitters with an internal version.

This matches what I found in the dependency files. Teams often remove parts of LangChain while keeping the pieces they still find useful.

What I learned

The common claim is wrong in two different ways.

First, most popular agent apps do not use full agent frameworks. The amount of attention frameworks receive is much larger than their adoption in popular apps.

Second, production apps do not simply remove every framework. In this data, production-grade apps used frameworks slightly more often than POC-like apps.

The actual pattern is more practical. Apps use focused tools instead of broad abstractions. They use a model client, a streaming library, a text splitter, or a graph runtime when they need one. Full frameworks that try to manage the entire system are less common.

Limits of this study

This study only looks at open-source repositories. Most production agent systems are private, so these results do not describe the whole industry.

The production-grade group contains 75 repositories, which is a limited sample. The production signal is also based on issue text, so it is only an estimate.

Dependency detection works from manifest files. This misses some apps written in Rust or Go and apps that call providers through plain HTTP. That likely means the use of raw libraries is undercounted.

The scripts, classification overrides, and dependency decisions are published at github.com/vikasgrac/agent-framework-study, so anyone can check the work or run the study again.