Open-Source AI Agents: How to Pick One to Build On
Choosing an open-source AI agent to build on comes down to four checks: a licence that permits your commercial plan, an architecture you can actually read, recent and non-solo maintenance, and a tool interface you can extend without forking. Stars answer none of these.
What an agent project actually gives you
An AI agent framework bundles four things: a loop that decides what to do next, a way to expose tools to the model, some form of memory or state, and error handling for when the model returns nonsense. The loop is the easy part and the reason so many frameworks exist. The tool interface and the error handling are where the months of work hide.
When you evaluate a project, evaluate those two. If extending the tool surface means editing the framework's own source, you have adopted a fork, not a dependency.
The four checks that matter
| Check | What to look for | Red flag |
|---|---|---|
| Licence | MIT, Apache-2.0 or BSD if you plan to sell | AGPL or a custom 'source-available' licence |
| Readable architecture | You can trace one request end to end in an hour | Abstraction layers with no example that uses them |
| Maintenance | Commits in the last 90 days from more than one person | One heroic maintainer, issues unanswered for months |
| Extensibility | Tools registered from outside the package | Adding a tool means editing framework files |
Why star counts mislead
Stars measure the moment a project was discovered, not whether it is a sound foundation today. A repository that trended eighteen months ago may have been abandoned since; a project with 400 stars and three active maintainers is usually the better bet than one with 40,000 and none.
Stars also do not distinguish between a demo and a product. Plenty of the most-starred agent repositories were built to illustrate an idea, and their authors will tell you so in the README if you read past the animated GIF.
Matching the project to what you are building
- Building an internal tool: prioritise readability and self-hosting over features. You will be the one debugging it at 6pm.
- Building a product: licence first, then extensibility. A licence problem discovered after launch is expensive in a way nothing else on this list is.
- Building a prototype to validate demand: pick whatever gets you to a demo fastest and accept that you will replace it.
- Building on top of an existing SaaS: prefer a project with a real protocol layer such as MCP over one with hard-coded integrations.
Shortening the search
Doing these checks properly takes about an hour per candidate, which is why most people skip them and regret it. The RepoLoot catalog does the structural part in advance: what the project does, the problem it solves, what you can build with it, who it suits and the implementation difficulty — with the repository identity revealed once you decide it is the one.
Frequently asked questions
- How do I choose an open-source AI agent framework?
- Check four things: a licence compatible with your commercial plans, an architecture you can trace end to end in about an hour, maintenance activity in the last 90 days from more than one contributor, and the ability to register new tools from outside the package without forking it.
- Are GitHub stars a good way to pick a project?
- No. Stars record when a project was discovered, not whether it is maintained or suitable today. A project with 400 stars and three active maintainers is usually a better foundation than one with 40,000 stars and none.
- Which licence should I look for if I plan to sell my product?
- MIT, Apache-2.0 or BSD. Treat AGPL and custom source-available licences as a decision to make with legal advice before you build, not after.