An open-source AI agent platform is one whose source code you can read, modify and run on your own hardware. The licence is the part that decides whether that is true in practice. Of the ten platforms in this comparison, seven carry an OSI-approved permissive licence, two are source-available with conditions attached, and one is copyleft. Two of the most frequently recommended projects in this category are archived and should not be adopted at all.
Most lists of open-source agent platforms are built from GitHub star counts. That produces a list that is wrong in two directions at once. It promotes projects whose licence forbids the thing the reader actually wants to do, and it recommends projects that stopped being maintained months ago.
This comparison starts from the licence file instead. Every licence here was read at the source in October 2026, and every claim about what a vendor gates behind a paid tier comes from that vendor’s own repository or pricing page.
The distinction that matters most: “open source” and “you can see the code” are not the same thing. A licence can let you read every line and still forbid you from offering the software to anyone else, or from removing the vendor’s logo, or from running it for more than one customer. Those are real restrictions, and they belong in the comparison rather than the footnotes.
What open source means in 2026, and why it is confusing
Three different things get called open source in this market. Only the first is open source by the standard definition used by the Open Source Initiative.
Permissive OSI licences. MIT and Apache 2.0. You can use the code commercially, modify it, redistribute it, and run it for as many customers as you like. The obligations are practical rather than restrictive: keep the copyright notice, and with Apache 2.0 state what you changed. Seven platforms in this list are here.
Copyleft OSI licences. The GNU AGPL is the one that appears in this market. It is a genuine open-source licence, approved by the same body, but it adds a condition: if you modify the software and let other people use it over a network, you have to publish your modified source. For internal use this changes nothing. For a company that modifies the platform and hosts that modified version for customers, it decides whether those changes can stay private.
Source-available licences. These are not open source, whatever the marketing says. The vendor publishes the code, then attaches conditions that break the OSI definition. Two of the largest projects in this category sit here. Dify’s licence file is headed “Open Source License” while adding conditions that fall outside the OSI definition, and n8n, which is more candid, calls its terms fair-code.
There is a fourth category worth naming separately: archived. A project can hold a perfect MIT licence and still be the wrong choice, because nobody is fixing its security bugs.
Two projects to avoid, and why they are still on every list
Before the ranking, two corrections. Both of these appear in most 2026 roundups of open-source agent platforms, and both are archived.
Flowise. The repository carries a banner reading “Flowise has been archived”, and the last push was 13 August 2026. It has 55,000 stars, which is exactly why it keeps appearing in lists generated from star counts. A starred project that has stopped receiving commits is a snapshot rather than a platform.
AutoGen. Microsoft’s own repository now carries an explicit warning: “Project archived and no longer maintained. Microsoft is not providing bug fixes, security fixes, new features, or support for this project.” The same notice advises against production use and points new users to Microsoft Agent Framework instead. AutoGen has more than 61,000 stars, so it will keep circulating for a while.
AutoGen also illustrates a licence trap worth understanding. Its repository holds two licence files: LICENSE covers documentation under Creative Commons Attribution 4.0, and LICENSE-CODE covers the code under MIT. GitHub reports the repository as CC-BY-4.0, which is the documentation licence. Anyone checking the licence badge rather than the files would conclude the code was not MIT. It was, but the point stands: read the files.
The 10 best open-source AI agent platforms in 2026
The list is ordered by how little the licence restricts what you can do with it. Permissive OSI licences come first, source-available licences after them, and the copyleft platform last. That order is a licence fact rather than a preference, and it means the further down you read, the more you should check the terms against your own plans.
Each platform is assessed on the same four points: what it is, where it is strong, where it falls short, and who it suits.
1. Langflow
What it is: Langflow is a visual builder for AI agents and workflows, written in Python and licensed MIT. You drag components onto a canvas, wire them together, and it produces a running flow you deploy as an API, or a JSON export of the flow definition.
Strengths: The MIT licence is unqualified, so there is no tier at which the terms change. The export path matters more than it sounds: a visual builder usually becomes a trap once your workflow outgrows the canvas, and Langflow gives you two ways out. Flows export as JSON, and a running flow can be deployed as an API that Python applications call through generated snippets. The logic stays portable, though it is not handed to you as standalone Python. It is actively maintained, with 156,000 stars and commits within the last week. It runs as a local server or in Docker with no vendor account.
Weaknesses: It is a builder, not an operations platform. There is no multi-tenant isolation, no per-customer billing, and no built-in audit trail for who changed which flow. Evaluation and deployment governance sit behind the vendor’s commercial offering. Memory does not: chat memory and a message-history component are in the open-source build, storing to SQLite by default. A single team building agents is well served; a company wanting to host agents for its own customers is not.
Best for: engineering teams that want a visual canvas for prototyping and a deployable API for production.
2. AnythingLLM
What it is: AnythingLLM is a local-first application for running agents and retrieval over your own documents, licensed MIT. It ships as a desktop app, a Docker container, or a self-hosted server.
Strengths: The licence is clean MIT with no conditions, and the desktop build is the fastest route in this entire list from zero to an agent reading your files. It connects to local models through Ollama as well as hosted ones, so a fully offline deployment is a configuration rather than a project. Workspaces keep separate document sets, and multi-user support with permissioning is documented as a Docker-only feature.
Weaknesses: It is an application rather than a framework, so extending it means working inside its structure rather than composing your own. Multi-user mode is lighter than a real identity system: roles are basic, and there is no per-workspace billing or tenant separation. Retrieval quality depends heavily on how you prepare documents, and the defaults are forgiving enough to hide bad chunking.
Best for: teams that need agents over internal documents without building retrieval themselves, especially where data cannot leave the building.
3. LibreChat
What it is: LibreChat is a self-hosted chat interface that fronts many model providers at once, licensed MIT. It is the closest open-source equivalent to a hosted chat product, with conversations, presets, file upload and agents.
Strengths: One interface across OpenAI, Anthropic, Google, local models and others, which solves the problem of a team holding four different subscriptions. The MIT licence has no strings. Authentication is real rather than bolted on: it supports OAuth through several providers and LDAP. It is the easiest project here to hand to a non-technical team, because it looks and behaves like a chat app they already know.
Weaknesses: It is a conversation surface, not an agent runtime. Agents exist inside it, but you are working within its plugin and tool model rather than deploying arbitrary code. There is no workflow engine, so multi-step automation with approvals belongs elsewhere. Enterprise features such as advanced admin controls are documented as part of the paid hosting rather than the self-hosted build.
Best for: organisations that want one private chat front end across several model providers, replacing per-seat subscriptions.
4. OpenHands
What it is: OpenHands is an open-source software engineering agent licensed MIT. It runs an agent-server with a browser and a shell, either inside a Docker sandbox or directly on the host machine, and it works on a repository the way a developer would.
Strengths: The MIT licence applies to the agent itself, not just a client library. The sandbox design is the real engineering, and it is worth reading before you install rather than after. OpenHands offers two modes. The Docker sandbox isolates the agent in a container. The non-sandboxed local mode runs the agent-server directly on the machine, and the README says so without softening it: “the agent will have full access to your filesystem”. Sandboxing is a setting you configure deliberately as risk reduction, not a guarantee the install gives you. With 92,000 stars it has the largest community in the coding-agent category, and it runs entirely locally against open models.
Weaknesses: It is a coding agent, so it solves one problem well and nothing else. There is no customer-facing surface, no workflow builder, and no team chat. Running it against weaker local models produces noticeably worse results than the hosted frontier models it is often demoed with, so the fully offline path is real but costs quality. Resource use is high: the sandbox wants memory.
Best for: engineering teams that want an agent doing repository work on infrastructure they control.
5. CrewAI
What it is: CrewAI is a Python framework for orchestrating multiple agents with assigned roles, licensed MIT. You define agents, give them tasks, and compose them into a crew that works through a process.
Strengths: The role-based model maps onto how teams actually describe work, which makes the code readable by people who are not the author. The MIT licence is unqualified and the framework is dependency-light compared with the larger orchestration stacks. It is actively developed with 60,000 stars, and the standalone design means it does not force you onto a particular model provider or hosting vendor.
Weaknesses: It is a library, not a platform. Everything around the agents, meaning the queue, the retries, the observability, the interface and the deployment, is yours to build. Multi-agent orchestration also multiplies cost and latency in ways that are easy to miss in a prototype, because every agent turn is a model call. Teams without Python engineers should not start here.
Best for: Python teams building multi-agent systems who want control of the runtime and no vendor in the path.
6. Microsoft Agent Framework
What it is: Microsoft Agent Framework is an open multi-language framework for building agents and multi-agent workflows in .NET, Python and Go, licensed MIT. It is the supported successor to AutoGen.
Strengths: It is where Microsoft is putting its maintenance effort, which is the single most important fact for anyone who was about to adopt AutoGen. The MIT licence is unqualified, and Microsoft publishes a migration guide from AutoGen. It supports Azure OpenAI, OpenAI, Microsoft Foundry and the GitHub Copilot SDK, with hosting patterns for both local development and cloud deployment, so it does not force one provider.
Weaknesses: It is young. At 14,000 stars it has a fraction of the community around the projects it replaces, which means fewer worked examples when you hit an edge case. The multi-language surface is genuinely broad, but documentation and samples are uneven across .NET, Python and Go. It is a framework, so the operational layer is still yours.
Best for: .NET and Python teams that want a maintained Microsoft-backed framework and were considering AutoGen.
7. Agno
What it is: Agno is a Python platform for building agents, teams of agents and multi-step workflows, licensed Apache 2.0. Its own description is “build, run, improve”: agents are built in code, run as durable services, and managed through a separate UI.
Strengths: Apache 2.0 is permissive with a patent grant, which matters to legal teams more than MIT’s silence on patents. Agents run as durable services with an API and an MCP server out of the box, so the operational layer exists without you writing it. The AgentOS UI gives you one place to review conversations, inspect traces, manage knowledge and track agent activity, which is more than most frameworks here offer. It runs in your own cloud against your own database, and supports any model provider.
Weaknesses: The Apache 2.0 licence covers the framework, and the hosted platform is a separate commercial product, so the boundary between the two needs checking against your plans. It is Python only. Documentation moves quickly enough that older examples drift from current APIs, which is a real cost when you are learning it. The breadth means more moving parts than a single-purpose library.
Best for: Python teams that want Apache 2.0 terms and a built-in control plane for observing runs.
8. n8n
What it is: n8n is a workflow automation platform with native AI agent nodes, which describes itself as “fair-code”. It is one of the two source-available platforms in this list.
Strengths: The breadth is unmatched: 209,000 stars, hundreds of integrations, and a self-hosted deployment that is genuinely simple through Docker. The visual builder plus the ability to drop into JavaScript or Python inside a node covers both non-technical and technical users in one tool. Agent nodes, vector store nodes and model nodes are first-class, so AI work sits alongside ordinary automation rather than in a separate product. Our roundup of AI workflow automation tools for operations teams covers how it compares on that builder side.
Weaknesses: The licence is the issue. n8n uses the Community License, which it long called the Sustainable Use License, and it permits use “only for your own internal business purposes or for non-commercial or personal use”, forbidding commercial distribution of the software itself unless it is free. Files containing .ee. in the filename or directory are excluded from that licence entirely and require an enterprise licence. The commercial line is narrower than “no business use”, and the exact position matters. n8n’s own licence FAQ permits building automations for clients on your own instance, charging for workflow creation, setup and maintenance, and charging for training and consultancy, provided clients receive the outputs and cannot create or edit the workflow logic themselves. It also permits running n8n behind the scenes in your own product where users trigger automations you built. A commercial licence is required when customers configure their own automations, when n8n is hosted as a service, or when it is white-labelled. So you can self-host it and you can earn from it; what you cannot do without terms is hand the builder itself to your customers. It is also not OSI-approved, which is why the project calls itself fair-code rather than open source.
Best for: internal automation inside one organisation, where the licence restriction never comes into play.
9. Dify
What it is: Dify is an LLM application platform for building agents, RAG pipelines and workflows in a collaborative workspace. It is the second source-available platform here.
Strengths: The scope is broad: agent workflows, retrieval, model management, and a usable interface for people who do not write code. It is heavily adopted at 160,000 stars with daily commits, and the self-hosted Docker deployment is well documented. For a team building internal AI applications, the amount of product you get for free is substantial.
Weaknesses: The licence is a modified Apache 2.0, and the modifications are material. Operating a multi-tenant environment requires written authorisation from the vendor, where one tenant equals one workspace. You may not remove or modify the logo or copyright in the frontend. Contributors agree that the vendor can tighten or relax the agreement as it sees fit. The vendor also notes an appearance patent on the product’s design. Apache 2.0 with those conditions is not Apache 2.0.
Best for: a single organisation building internal AI applications, where the multi-tenant restriction is irrelevant.
10. Shogo
What it is: Shogo is an open-source AI agent harness combining team chat, meeting memory, software building and Every frontier model, with 1,000+ integrations.
Strengths: The licence split is deliberate and documented. Client and library packages ship MIT, verified in packages/sdk/LICENSE and on npm, so anything built with the SDK is yours without obligation. The platform itself is AGPL, which for internal use imposes nothing. Self-hosting is documented rather than implied: fork the runtime and the agents, then run the API, the gateway, the database and the storage on your own hardware. Paid plans are unlimited inside rolling fair-use windows.
Weaknesses: The licence obligations are real but narrower than usually described. AGPL asks that a company modifying the platform and offering it over a network make its source available to the users of that version; it does not forbid hosting, and it does not require publishing to the public. What blocks white-labelling sits elsewhere: the trademark policy governs whether the Shogo name can stay on a fork, and a separate infrastructure licence governs the deployment materials. Shogo’s own documentation says the three layers together, not the copyleft clause alone, are what make a hostile fork expensive. Free and Basic are single-user, so a team sharing anything starts at Pro at $20 a seat, and SSO, audit logs and per-member spending limits do not appear until Business at $40. The public repository is young at 18 stars, so community support is thin and the auditable code is newer than the projects above.
Best for: teams that want the platform itself to be auditable and self-hostable, and that are deploying internally rather than reselling.
How to choose
If you want the fewest licence questions, stay in the first seven. MIT and Apache 2.0 let you run the software commercially, for multiple customers, with no obligation to publish your changes. If your plan involves hosting agents for clients, this is the only group where that is unambiguously fine.
If you are automating your own business, the source-available platforms are excellent value. n8n and Dify both give you a great deal of product for nothing, and the restrictions that make them not-open-source only bind when you redistribute or resell. Read the terms before you build a product on them, not after. Our breakdown of AI agent pricing models covers how those paid tiers are metered once you outgrow the free build.
If you plan to fork and offer the result as a service, check the copyleft clause first. AGPL means your modifications travel with the service. That is a feature if you want contributions to stay public, and a blocker if you wanted to keep them private.
If the project is archived, it is not a candidate, regardless of its licence or its star count. Flowise and AutoGen are both still widely recommended and both are unmaintained.
If your constraint is data location rather than licence, the question changes entirely: you need an offline model path as well as a self-hosted platform. AnythingLLM and OpenHands both support local models properly, which is a different requirement from merely running the software on your own server. If your team has no engineers, no-code AI agent builders are the better starting point than any framework here.
Where Shogo fits, and where it doesn’t
Shogo is worth considering when the thing you want to audit is the platform rather than a library. The monorepo covers the runtime, the agent, the tools and the interface, and the split between MIT packages and the AGPL platform is stated on the site rather than buried in a repository.
It is the wrong choice in two situations. If you intend to modify the platform and offer it to others as a hosted product under your own brand, plan on two separate conversations rather than one. The AGPL requires that your modifications be made available to the users of that version, which is a real constraint on a closed product. Separately, the trademark policy governs whether your brand can replace Shogo’s on the interface, and the infrastructure licence governs the deployment materials. Hosting the platform as it ships, unmodified and unrebranded, is permitted. And if community size matters to you, 18 stars is a small repository next to projects with tens of thousands, which means fewer answers when something breaks and a shorter track record to judge the code against.
It is also not the right starting point if what you need is a single-purpose tool. For document retrieval, AnythingLLM is more direct. For repository work, OpenHands is more focused. Shogo is a harness, and a harness is only worth its breadth if you intend to use several parts of it.
Frequently asked questions
Is n8n open source?
No, not by the Open Source Initiative’s definition. n8n uses the Community License, formerly called the Sustainable Use License, which permits use for internal business purposes, non-commercial use or personal use, and forbids commercial distribution except at no charge. The project describes itself as fair-code, and files containing .ee. in their name are licensed separately under an enterprise agreement. You can self-host it freely for your own organisation, and you can sell automation work built on it, because the licence FAQ allows client automations where the client cannot edit the logic. What needs a commercial licence is letting customers configure their own automations, hosting n8n as a service, or white-labelling it.
Is Dify open source?
It is source-available rather than open source. Dify’s licence is a modified Apache 2.0 that adds conditions: you may not operate a multi-tenant environment without written authorisation, you may not remove the logo or copyright from the frontend, and the vendor reserves the right to change the agreement. Those conditions place it outside the OSI definition even though the base licence is Apache 2.0.
What is the difference between AGPL and MIT for an AI agent platform?
MIT lets you use, modify and redistribute the code with almost no conditions beyond keeping the copyright notice. The AGPL adds a network clause: if you modify the software and let others use it over a network, you must make your modified source available. For internal deployment the two are practically identical. For a company planning to host the software for customers, AGPL obliges you to publish your changes.
Can I really self-host an AI agent platform with no internet access?
Yes, if the platform supports local models and does not require a licence check against the vendor. AnythingLLM and OpenHands both run against local models through runtimes such as Ollama. The part that usually breaks an offline plan is not the agent but the surrounding services: vector databases, embedding models and telemetry endpoints all need to be reachable or disabled. Check those before committing.
Which open-source agent platforms are no longer maintained?
Flowise and AutoGen are both archived. Flowise’s repository carries an archive banner and its last commit was August 2026. AutoGen’s repository states that Microsoft is no longer providing bug fixes, security fixes or support, and advises against production use. Both remain popular in star-count rankings, which is why they keep appearing in 2026 lists.
Is a permissive licence enough to build a product on?
Usually, but check what is licensed. Projects sometimes release a client SDK under MIT while the server or enterprise features carry different terms. AutoGen ships two licence files, one for documentation and one for code. n8n excludes its .ee. files from the main licence. Read the licence file for the component you are deploying, not the repository badge.
Which open-source agent platform is best for a small team?
For document work, AnythingLLM, because it installs as a desktop app and needs no infrastructure. For a shared chat interface across providers, LibreChat. For internal automation, n8n, provided the licence restriction does not affect you. All three can be running the same afternoon, which matters more for a small team than architectural flexibility.
Sources
- n8n, LICENSE.md and the Community License (formerly Sustainable Use License 1.0), plus licence FAQ and pricing page
- Dify, LICENSE and pricing page
- Flowise, repository archive notice and Future of Flowise discussion
- AutoGen, README archive notice, LICENSE and LICENSE-CODE
- Langflow, repository and MIT licence
- AnythingLLM, repository and MIT licence
- LibreChat, repository and MIT licence
- OpenHands, repository and MIT licence
- CrewAI, repository and MIT licence
- Microsoft Agent Framework, repository and MIT licence
- Agno, repository and Apache 2.0 licence
- Shogo, why-shogo, pricing, llms.txt, docs/LICENSING.md and the public monorepo
