The 50 Best Open-Source and Source-Available AI Agents in 2026

Most lists of open-source AI agents are wrong about the one thing that matters legally: the license. Projects get called "open source" because they have a public GitHub repository and a Docker image, not because anyone read the LICENSE file. Several of the most-recommended agent platforms in circulation right now are not open source at all. They are source-available under terms that forbid you from offering the software as a service, forbid you from removing the vendor's branding, or forbid you from competing with the vendor.

This list separates the two without pretending source-available software does not exist. It ranks 49 projects under licenses approved by the Open Source Initiative — MIT, Apache 2.0, BSD, GPL, or AGPL — plus AGNT, our source-available local agent operating system. Every entry labels the license class directly. Other widely recommended source-available projects appear in a separate section with the clause that keeps each one outside the OSI definition.

Each entry gives you six things: what it does, how you deploy it, the license, who it fits, where it breaks down, and the repository URL.

Methodology

License verification. Every license claim was checked against the LICENSE file in the project's canonical repository or the project's official licensing documentation, not against a package registry badge or a third-party summary. Where a repository uses a split license — an open core plus a separately licensed enterprise directory — the carve-out is named in the entry. An open-source entry qualifies only if the software is usable and deployable without a proprietary directory. Source-available entries must publish the relevant source and permit self-hosted internal use; they are labeled separately and never presented as OSI open source.

The OSI line. An open-source license qualifies if it grants the right to use, modify, and redistribute the software for any purpose, including commercial purposes and including competing with the original author. Licenses that restrict the field of use — Elastic License 2.0, Business Source License, PolyForm Shield, Sustainable Use License, and bespoke branding-restriction licenses — do not qualify. This is not a judgment about whether those licenses are reasonable. Several are entirely defensible business decisions. They simply are not open source, and calling them open source misleads readers who are about to make a procurement or architecture decision.

Re-verified on 2026-08-11. Fifteen licenses were read directly from their LICENSE files on the publication date, chosen because they are the ones public write-ups most often get wrong: Agno, Mastra, Flowise, Langfuse, LiteLLM, Onyx, OpenHands, Letta, Skyvern, Browser Use, elizaOS, and the five appendix entries plus AutoGPT. The exact disqualifying language for the appendix entries is quoted below.

No engagement metrics. This list contains no star counts, no contributor counts, and no commit-frequency claims. Those numbers change weekly, are trivially gamed, and correlate poorly with whether a project will still be maintained when your on-call rotation needs it. Judge maintenance by reading the issue tracker and the last three releases.

Selection. AGNT is included with an explicit disclosure because this is AGNT’s publication and excluding our own applicable system would make the comparison less useful, not more objective. Projects were otherwise included on the basis of doing something an agent system actually needs — reasoning loops, tool execution, computer control, memory, model routing, sandboxing, evaluation, or safety enforcement — and being deployable by a team that has decided to self-host. Wrapper repositories, tutorial repositories, and abandoned proof-of-concepts were excluded.

A note on scope. "Agent" is used here in the working sense: software that takes a goal, decides on actions, calls tools, observes results, and iterates. Some entries are complete agents you run. Others are the frameworks and infrastructure those agents are built on. Both belong on a list like this, because nobody ships an agent in production without the second category. For the architectural distinctions between these layers, see the AI agent architectures guide.

---

Comparison matrix

#	Project	Category	Primary language	Deployment	License
1	AGNT	Local agent operating system	JavaScript / TypeScript	Desktop, Docker, headless	AGNT Open License 1.0 — source-available
2	OpenHands	Coding agent	Python / TypeScript	Docker, cloud	MIT
3	SWE-agent	Coding agent	Python	CLI, library	MIT
4	Aider	Coding agent	Python	CLI	Apache-2.0
5	Cline	Coding agent	TypeScript	IDE extension	Apache-2.0
6	Roo Code	Coding agent	TypeScript	IDE extension	Apache-2.0
7	Continue	Coding agent	TypeScript	IDE extension, CLI	Apache-2.0
8	Goose	Coding agent	Rust	CLI, desktop	Apache-2.0
9	Gemini CLI	Coding agent	TypeScript	CLI	Apache-2.0
10	Codex CLI	Coding agent	Rust	CLI	Apache-2.0
11	OpenCode	Coding agent	Go / TypeScript	CLI, TUI	MIT
12	LangGraph	Framework	Python / TypeScript	Library	MIT
13	CrewAI	Framework	Python	Library	MIT
14	AutoGen	Framework	Python / .NET	Library	MIT
15	OpenAI Agents SDK	Framework	Python / TypeScript	Library	MIT
16	Google ADK	Framework	Python / Java	Library	Apache-2.0
17	Strands Agents	Framework	Python	Library	Apache-2.0
18	Semantic Kernel	Framework	C# / Python / Java	Library	MIT
19	Pydantic AI	Framework	Python	Library	MIT
20	Agno	Framework	Python	Library, service	Apache-2.0
21	Mastra	Framework	TypeScript	Library, service	Apache-2.0 (core)
22	LlamaIndex	Framework	Python / TypeScript	Library	MIT
23	Haystack	Framework	Python	Library, service	Apache-2.0
24	DSPy	Framework	Python	Library	MIT
25	CAMEL	Multi-agent	Python	Library	Apache-2.0
26	MetaGPT	Multi-agent	Python	CLI, library	MIT
27	GPT Researcher	Research agent	Python	Service, library	Apache-2.0
28	Agent Zero	General agent	Python	Docker	MIT
29	elizaOS	General agent	TypeScript	Service	MIT
30	Browser Use	Browser agent	Python	Library	MIT
31	Stagehand	Browser agent	TypeScript	Library	MIT
32	Skyvern	Browser agent	Python	Docker	AGPL-3.0
33	Playwright MCP	Browser tooling	TypeScript	MCP server	Apache-2.0
34	UI-TARS Desktop	Computer-use agent	TypeScript	Desktop	Apache-2.0
35	Open Interpreter	Computer-use agent	Python	CLI, library	AGPL-3.0
36	Letta	Memory / agent server	Python	Service	Apache-2.0
37	Mem0	Memory	Python / TypeScript	Library, service	Apache-2.0
38	Graphiti	Memory	Python	Library, service	Apache-2.0
39	RAGFlow	Retrieval	Python	Docker	Apache-2.0
40	Onyx	Enterprise search agent	Python / TypeScript	Docker, Kubernetes	MIT (core)
41	LiteLLM	Model gateway	Python	Library, proxy	MIT (core)
42	vLLM	Inference server	Python / CUDA	Service	Apache-2.0
43	Ollama	Local model runtime	Go	Desktop, service	MIT
44	E2B	Sandbox	Python / TypeScript	Self-hosted, cloud	Apache-2.0
45	Temporal	Durable execution	Go	Service, cluster	MIT
46	Langfuse	Observability	TypeScript	Docker, Kubernetes	MIT (core)
47	Opik	Observability / eval	Python / TypeScript	Docker, Kubernetes	Apache-2.0
48	promptfoo	Evaluation	TypeScript	CLI, library	MIT
49	NeMo Guardrails	Safety	Python	Library, service	Apache-2.0
50	garak	Red-teaming	Python	CLI	Apache-2.0
51	MCP reference servers	Tool protocol	TypeScript / Python	MCP servers	MIT

---

Source-available agent operating system

1. AGNT

Disclosure. AGNT is our product and this article is published by AGNT. We include it because it squarely matches the query: the source is public, it runs locally or self-hosted, and it is a complete agent system. We label the license accurately rather than calling it OSI open source.

What it does. AGNT is a local-first agent operating system for persistent agents, visual workflows, long-running goals, tools, memory, skills, plugins, MCP connections, evaluations, traces, provider routing, approvals, and a local API. The same runtime can be used as a desktop app, Docker service, or headless server.

Deployment model. Prebuilt desktop applications for Windows, macOS, and Linux; Docker and source builds for self-hosting; headless operation for always-on agents and workflows. Agent execution, workspaces, tools, and storage stay on infrastructure you control. Model inference follows the provider you configure, including local providers.

License. AGNT Community Core License 1.0, a custom source-available license. It permits downloading, viewing, modifying, and self-hosting AGNT for personal and internal business use. It restricts public SaaS, resale, rebranding, redistribution, and competing hosted offerings, so it is not OSI-approved open source. Read the license before adopting it.

Best fit. Teams and individual builders who want the operating layer around agents — UI, workflows, goals, memory, tools, plugins, evaluations, traces, and provider management — in one local system instead of assembling a dozen libraries and services.

Limitation. The license is deliberately more restrictive than MIT or Apache 2.0, and the runtime is designed for trusted local workspaces and self-hosted teams rather than public multi-tenant SaaS isolation.

Source. https://github.com/agnt-gg/agnt

Try it. Download AGNT and run your first local agent, or inspect the repository and license first.

---

Coding agents

These are the agents most teams meet first, because the feedback loop is short and the failure mode is a bad diff rather than a bad wire transfer.

2. OpenHands

What it does. Runs a full software-engineering loop inside a sandboxed container: reads the repository, writes files, runs shell commands, executes tests, and browses the web. It ships a web UI where you watch the agent work and intervene.

Deployment model. Docker container on your own machine or server, with the agent's runtime isolated in a second container. A hosted version exists from the maintainers; the self-hosted path is complete and does not require it.

License. MIT. The LICENSE file at the repository root is the unmodified MIT text, copyright the OpenHands contributors. There is no enterprise directory carve-out.

Best fit. Teams that want an autonomous coding agent they can point at a private repository without sending the repository to a vendor. The container isolation is real isolation, which matters when the agent is allowed to run arbitrary commands.

Limitation. Resource-hungry. Each session spins up a runtime container, and long sessions accumulate context that degrades the agent's judgment on large codebases. Budget for supervision on anything touching more than a handful of files.

Source. https://github.com/OpenHands/OpenHands

3. SWE-agent

What it does. Gives a language model a purpose-built interface to a repository — a file viewer, an editor with linting feedback, and a search tool — and lets it resolve issues. It originated as a research system for the SWE-bench benchmark and is the reference implementation most other coding agents were measured against.

Deployment model. Python package run from the command line, or imported as a library. Executes in a Docker container by default.

License. MIT.

Best fit. Researchers and engineers who want to study or modify the agent-computer interface itself. The codebase is small enough to read in an afternoon, which is not true of most alternatives.

Limitation. Optimized for issue-resolution tasks with a clear success signal. It is not a general-purpose pair-programming tool and has no interactive UI worth the name.

Source. https://github.com/SWE-agent/SWE-agent

4. Aider

What it does. Pair-programs in the terminal against a local Git repository. It builds a repository map to give the model structural context, applies edits as proper diffs, and commits each change with a generated message so you can revert cleanly.

Deployment model. Python CLI installed on the developer's machine. Talks to whichever model API you configure, including local endpoints.

License. Apache-2.0.

Best fit. Developers who live in a terminal and want every agent action recorded as a Git commit. The commit-per-edit discipline makes agent mistakes trivially reversible, which is the single most useful safety property a coding agent can have.

Limitation. Requires a clean Git working tree to behave well, and the repository map degrades on very large monorepos where the map itself consumes most of the context window.

Source. https://github.com/Aider-AI/aider

5. Cline

What it does. Runs an autonomous coding agent inside VS Code. It proposes file edits and terminal commands, shows a diff, and waits for approval before each action unless you enable auto-approval for specific action types.

Deployment model. VS Code extension. Bring your own model API key; supports local endpoints.

License. Apache-2.0.

Best fit. Developers who want agent autonomy with a human in the loop by default. The per-action approval gate is the design decision that distinguishes it, and it is the right default for anything touching production code.

Limitation. Token consumption is high because it re-sends substantial context on each step. Costs escalate quickly on frontier models, and the approval prompts become fatiguing on long tasks, which pushes users toward disabling the safety feature they installed it for.

Source. https://github.com/cline/cline

6. Roo Code

What it does. A fork of Cline that adds configurable agent modes — architect, coder, debugger, and custom modes you define — each with its own system prompt and tool permissions.

Deployment model. VS Code extension.

License. Apache-2.0.

Best fit. Teams that want to constrain what the agent is allowed to do at different phases of work. Giving the planning mode no write access and the implementation mode no network access is a meaningful reduction in blast radius.

Limitation. Configuration surface is large. The mode system rewards teams willing to invest in prompt engineering and punishes those who expect good defaults.

Source. https://github.com/RooCodeInc/Roo-Code

7. Continue

What it does. Provides autocomplete, chat, and agent modes inside VS Code and JetBrains, with the model, prompts, context providers, and tools defined in configuration files you can commit to the repository.

Deployment model. IDE extension plus a CLI. Configuration is file-based and version-controllable.

License. Apache-2.0.

Best fit. Organizations standardizing agent behavior across a team. Because the configuration is a file in the repository, everyone gets the same model routing, the same system prompt, and the same tool allowlist.

Limitation. The breadth costs depth. Its agent mode is less aggressive than dedicated coding agents, and the JetBrains implementation historically trails the VS Code one.

Source. https://github.com/continuedev/continue

8. Goose

What it does. An extensible agent from Block that runs locally, installs and calls MCP servers as extensions, and executes multi-step engineering tasks from a CLI or desktop app.

Deployment model. Native binary for macOS, Linux, and Windows. CLI and desktop app share the same engine.

License. Apache-2.0.

Best fit. Engineers who want a local agent that is not tied to an editor and that treats MCP as its primary extension mechanism. Being a Rust binary rather than a Python environment removes an entire category of setup problems.

Limitation. The extension ecosystem is the product. Without well-chosen MCP servers configured, Goose is a competent but unremarkable shell agent.

Source. https://github.com/block/goose

9. Gemini CLI

What it does. Brings an agent loop to the terminal with built-in file, shell, and web-fetch tools, MCP support, and a configuration file for project-level instructions.

Deployment model. Node CLI installed globally or run via npx.

License. Apache-2.0.

Best fit. Teams already on Google Cloud who want a terminal agent with first-party model access and a permissive license on the client itself. The client being Apache-2.0 means you can fork it and point it elsewhere.

Limitation. The open-source component is the client. The models it is designed around are proprietary and metered, so "open source" here describes the harness, not the intelligence.

Source. https://github.com/google-gemini/gemini-cli

10. Codex CLI

What it does. OpenAI's terminal coding agent. Reads and edits files, runs commands, and operates under a configurable approval and sandboxing policy that controls whether it can write outside the workspace or reach the network.

Deployment model. Native binary, distributed via npm and package managers. Sandboxing uses OS-level primitives — Seatbelt on macOS, Landlock on Linux.

License. Apache-2.0.

Best fit. Developers who want OS-enforced sandboxing rather than prompt-enforced sandboxing. The distinction matters: an agent that is told not to touch /etc and an agent that cannot touch /etc are different risk profiles.

Limitation. Same caveat as Gemini CLI — the harness is open, the model is not. Sandbox behavior also differs meaningfully between operating systems, so a policy validated on macOS is not automatically validated on Linux.

Source. https://github.com/openai/codex

11. OpenCode

What it does. A terminal-native coding agent with a client/server split, so the agent can run on a remote machine while you drive it from a local TUI, a web interface, or a mobile client.

Deployment model. Single binary. Runs as a server you attach clients to, or as a standalone TUI.

License. MIT.

Best fit. Anyone who wants the agent running next to the code — on a build server or a dev container — rather than on a laptop that goes to sleep. It is also model-agnostic by design, with no preferred vendor.

Limitation. The client/server architecture adds an authentication and networking surface you are responsible for securing. Exposing the server without an authenticating proxy hands remote code execution to whoever finds the port.

Source. https://github.com/sst/opencode

---

Agent frameworks and orchestration

The layer where you decide how your agent thinks. For a deeper comparison of the trade-offs between graph-based, role-based, and event-driven designs, see the best AI agent frameworks.

12. LangGraph

What it does. Models agents as explicit state graphs. You define nodes, edges, and conditional transitions; the framework handles checkpointing, interruption, resumption, and human-in-the-loop pauses at any node.

Deployment model. Library for Python and TypeScript. Persistence backends are pluggable; a Postgres checkpointer is the common production choice.

License. MIT.

Best fit. Production agents that need to pause for approval, survive a process restart, and be debugged after the fact. The explicit graph is verbose to write and enormously easier to reason about at 3am than an agent whose control flow is emergent.

Limitation. The learning curve is real, and the surrounding LangChain ecosystem has a history of API churn that has burned teams pinning loosely. Pin versions and read migration notes.

Source. https://github.com/langchain-ai/langgraph

13. CrewAI

What it does. Organizes agents as a crew: each agent has a role, a goal, a backstory, and tools, and tasks are executed sequentially or hierarchically with a manager agent delegating.

Deployment model. Python library. Standalone — it does not depend on LangChain.

License. MIT.

Best fit. Business-process automation where the work decomposes naturally into roles: a researcher, a writer, an editor. The role metaphor makes the design legible to non-engineers, which shortens the argument about what the system should do.

Limitation. The role abstraction hides control flow. When a crew produces a bad result, tracing which agent's output poisoned which downstream task is harder than in an explicit graph. Debugging tooling has improved but remains the weak point.

Source. https://github.com/crewAIInc/crewAI

14. AutoGen

What it does. Microsoft's multi-agent framework, built around asynchronous message passing between agents. Agents converse, call tools, and terminate on conditions you define; a separate studio application provides a low-code interface over the same core.

Deployment model. Python and .NET libraries. The event-driven core can be distributed across processes.

License. MIT.

Best fit. Systems where agents genuinely need to talk to each other — negotiation, critique loops, adversarial review — rather than execute a fixed pipeline. The .NET support is a real differentiator for enterprise shops.

Limitation. The framework underwent a substantial architectural rewrite, and a community fork exists. Tutorials and Stack Overflow answers written for the older API do not apply to the current one, so verify which version any example targets before copying it.

Source. https://github.com/microsoft/autogen

15. OpenAI Agents SDK

What it does. A deliberately small framework: agents with instructions and tools, handoffs to transfer control between agents, guardrails that validate input and output, and built-in tracing.

Deployment model. Python and TypeScript libraries. Works with any provider exposing a Chat Completions-compatible endpoint, not only OpenAI's.

License. MIT.

Best fit. Teams who found larger frameworks over-abstracted. The whole surface area is a handful of primitives, which means you can read the source when something misbehaves instead of filing an issue.

Limitation. Minimal by design means you build the missing pieces. There is no durable execution, no built-in persistence layer, and no scheduler. For long-running workflows you will pair it with something like Temporal.

Source. https://github.com/openai/openai-agents-python

16. Google Agent Development Kit

What it does. A code-first framework for building and evaluating agents, with sequential, parallel, and loop workflow agents as first-class constructs, a built-in evaluation harness, and a local development UI for inspecting agent traces.

Deployment model. Python and Java libraries. Deploys to a container runtime of your choice; first-party deployment targets exist on Google Cloud but are not required.

License. Apache-2.0.

Best fit. Teams that want evaluation built into the framework rather than bolted on. Being able to define test cases against agent trajectories from day one changes how the project is developed.

Limitation. Cloud-adjacent design. Several conveniences assume Google Cloud services, and the non-Google paths receive less attention in the documentation.

Source. https://github.com/google/adk-python

17. Strands Agents

What it does. A model-driven agent SDK from AWS. Rather than encoding the control flow, you give the agent a prompt and a set of tools and let the model plan; the SDK supplies the loop, tool invocation, streaming, and session state.

Deployment model. Python library. Deployment guidance covers Lambda, Fargate, and EC2, but the library has no AWS dependency for local use.

License. Apache-2.0.

Best fit. Teams betting that models will keep getting better at planning and who therefore want minimal scaffolding between the model and its tools. Also a natural fit if your infrastructure is already on AWS.

Limitation. The model-driven premise is a bet. On weaker models the loop wanders, and there is less structural machinery to constrain it than in a graph framework. Verify with your actual model before committing.

Source. https://github.com/strands-agents/sdk-python

18. Semantic Kernel

What it does. Microsoft's SDK for embedding model calls, plugins, and planners into conventional applications. Its strength is treating AI as a component inside an existing service rather than as the architecture of a new one.

Deployment model. Libraries for C#, Python, and Java. Runs wherever your application runs.

License. MIT.

Best fit. Enterprise .NET and Java teams adding agent capability to systems that already exist, with dependency injection, structured logging, and telemetry that match the rest of the codebase.

Limitation. The abstraction layers are heavy relative to Python-native frameworks, and the Python implementation lags the C# one in both features and documentation quality.

Source. https://github.com/microsoft/semantic-kernel

19. Pydantic AI

What it does. Brings Pydantic's validation model to agents. Tool arguments and agent outputs are typed and validated; when the model returns malformed output, the framework feeds the validation error back and retries.

Deployment model. Python library.

License. MIT.

Best fit. Anyone whose agent output feeds another system. Type-checked structured output eliminates the entire category of bugs where the model returns a plausible string that the downstream parser rejects.

Limitation. Focused on single-agent correctness. Multi-agent orchestration exists but is thinner than in purpose-built frameworks, and the retry-on-validation-failure pattern costs tokens on models that are bad at following schemas.

Source. https://github.com/pydantic/pydantic-ai

20. Agno

What it does. A full-stack agent framework covering agents, teams, workflows, memory, knowledge, and a served API, with an emphasis on low instantiation overhead and multi-modal input.

Deployment model. Python library, plus a served runtime you can host yourself for a REST interface over your agents.

License. Apache-2.0. The LICENSE file at the repository root is the unmodified Apache 2.0 text with a copyright notice for Agno Inc. There is no enterprise directory carve-out in the repository.

Best fit. Teams that want batteries included — memory, storage, and an API surface — without stitching five libraries together. It moves faster from prototype to running service than most alternatives.

Limitation. Broad surface, and the project renamed from an earlier identity, so older documentation and blog posts reference the previous package name and import paths.

Source. https://github.com/agno-agi/agno

21. Mastra

What it does. A TypeScript agent framework with agents, tools, workflows built from typed steps, RAG primitives, evaluation hooks, and a local development playground.

Deployment model. TypeScript library. Deploys to Node servers, containers, or serverless platforms.

License. Apache-2.0 for the core, with a carve-out. The LICENSE file states that content under any directory named ee/ — currently auth-related code under packages/core/src/auth/ee/ and packages/server/src/server/auth/ee/ — is governed by a separate license in ee/LICENSE. Everything outside those directories is Apache-2.0. The framework is fully usable without the ee/ code, so it qualifies here, but you should read ee/LICENSE before depending on the enterprise authentication paths.

Best fit. JavaScript and TypeScript teams who do not want to run a Python service alongside their Node application. The type safety across workflow steps catches integration errors at build time.

Limitation. The open-core split means the authentication story for multi-tenant deployments is the part most likely to require a commercial conversation.

Source. https://github.com/mastra-ai/mastra

22. LlamaIndex

What it does. Started as a data framework for retrieval and grew an event-driven agent layer. Its Workflows abstraction models agents as steps that emit and consume events, which composes well with the ingestion and indexing machinery underneath.

Deployment model. Python and TypeScript libraries.

License. MIT.

Best fit. Agents whose primary job is answering questions over a document corpus. Nothing else on this list has as much depth in document parsing, chunking, and index construction.

Limitation. The package ecosystem is heavily split into separate integration packages, which makes dependency management tedious and version conflicts common in large projects.

Source. https://github.com/run-llama/llama_index

23. Haystack

What it does. A pipeline framework from deepset for building search and agent applications out of composable components, with strong typing on component connections and a serializable pipeline format.

Deployment model. Python library, with a REST service wrapper for deploying pipelines as APIs.

License. Apache-2.0.

Best fit. Teams with an information-retrieval background who want pipelines defined as data — serializable to YAML, versionable, and deployable without code changes. It has a longer production track record than most agent frameworks because it predates the agent wave.

Limitation. The pipeline metaphor is a better fit for retrieval than for open-ended agent loops. Highly dynamic agent behavior fights the abstraction.

Source. https://github.com/deepset-ai/haystack

24. DSPy

What it does. Replaces prompt engineering with programming. You declare signatures — input and output fields — and compose modules, then run an optimizer that generates and selects prompts and few-shot examples against a metric you define.

Deployment model. Python library. Optimization is a build-time step; the compiled program runs like any other.

License. MIT.

Best fit. Teams with a labeled evaluation set who are tired of hand-tuning prompts and re-tuning them every time they change models. The optimizer often finds prompts a human would not have written.

Limitation. Requires an evaluation metric and data to optimize against. Without those, DSPy is a more abstract way to write the same prompt you would have written anyway, and the compilation step consumes significant tokens.

Source. https://github.com/stanfordnlp/dspy

---

Multi-agent and general-purpose agents

25. CAMEL

What it does. A research-oriented framework for studying multi-agent societies, with role-playing agents, structured inter-agent communication, and a large body of implemented agent types and benchmarks.

Deployment model. Python library.

License. Apache-2.0.

Best fit. Research into how agent populations behave — emergent cooperation, task decomposition, synthetic data generation from agent dialogue. It is the most academically serious project in this section.

Limitation. Research code. Interfaces change between releases, and production concerns like retry behavior, cost control, and observability are not the priority.

Source. https://github.com/camel-ai/camel

26. MetaGPT

What it does. Assigns agents the roles of a software company — product manager, architect, engineer, QA — and runs them through a standard operating procedure that produces requirements, design documents, and code from a one-line brief.

Deployment model. Python CLI or library.

License. MIT.

Best fit. Generating a first-pass scaffold and its accompanying documentation for a greenfield project. The intermediate artifacts — the requirements document, the API design — are often more useful than the code.

Limitation. Output quality drops sharply as project complexity rises, and the generated code frequently requires substantial rework. Treat it as a document generator that also writes code, not a code generator that also writes documents.

Source. https://github.com/FoundationAgents/MetaGPT

27. GPT Researcher

What it does. Runs an autonomous research loop: plans sub-questions, searches the web, scrapes and summarizes sources, and produces a cited report. It separates a planner agent from parallel execution agents to reduce latency and bias from any single source.

Deployment model. Python library or a self-hosted service with a web UI. Search providers and scrapers are configurable.

License. Apache-2.0.

Best fit. Producing sourced research briefs at volume. The citation discipline is the reason to choose it over a generic agent with a search tool bolted on.

Limitation. Output quality is bounded by the search provider you configure and by the fact that the agent cannot tell a reliable source from a confident one. It will cite content farms as readily as primary sources unless you constrain the domains.

Source. https://github.com/assafelovic/gpt-researcher

28. Agent Zero

What it does. A general-purpose agent framework that treats the operating system as its toolkit. It writes and executes code to accomplish tasks rather than selecting from a fixed tool list, and can spawn subordinate agents for subtasks.

Deployment model. Docker container with a web UI. Designed to run in a container precisely because it executes arbitrary code.

License. MIT.

Best fit. Users who want maximum flexibility and are comfortable with an agent that improvises its own tooling. The prompt-driven design means behavior is customized by editing prompt files rather than writing code.

Limitation. Arbitrary code execution is the feature and the risk. Never run it outside a container, never give the container credentials you would not hand to an unvetted script, and expect it to be substantially less reliable than a constrained agent.

Source. https://github.com/agent0ai/agent-zero

29. elizaOS

What it does. A TypeScript framework for persistent, character-driven agents that operate across chat platforms — Discord, Telegram, X — with pluggable memory, actions, evaluators, and providers.

Deployment model. Node service, typically containerized. Plugin architecture for platform connectors and capabilities.

License. MIT. Verified against the LICENSE file at the repository root, which contains the unmodified MIT text.

Best fit. Social and community agents that need consistent personality and long-lived memory across many conversations and platforms. The plugin ecosystem for messaging platforms is the most developed of anything on this list.

Limitation. Much of the surrounding ecosystem is oriented toward cryptocurrency use cases, which colors the plugin catalog and the community. The core framework is general, but you will be filtering signal from a lot of token-adjacent noise.

Source. https://github.com/elizaOS/eliza

---

Browser and computer-use agents

30. Browser Use

What it does. Lets an agent drive a real browser. It extracts the interactive elements of a page into a structured representation the model can reason about, then executes clicks, typing, and navigation, with optional vision input for pages that resist DOM extraction.

Deployment model. Python library, driving Playwright. Runs headless or headed.

License. MIT. Verified against the LICENSE file, which contains the unmodified MIT text.

Best fit. Automating workflows on sites with no API, where selectors change often enough that traditional scripted automation breaks. The element-extraction approach is more token-efficient than sending screenshots.

Limitation. Slow and expensive per action compared to scripted automation, and unreliable on pages with heavy custom widgets, canvas rendering, or aggressive bot detection. It is the right tool only when a deterministic script is genuinely impossible.

Source. https://github.com/browser-use/browser-use

31. Stagehand

What it does. Adds three AI primitives — act, extract, and observe — on top of Playwright, so you can mix deterministic Playwright code with natural-language instructions in the same script and fall back to code where reliability matters.

Deployment model. TypeScript and Python libraries. Runs against local browsers or a remote browser service.

License. MIT.

Best fit. Teams that already have Playwright test suites and want to make the brittle parts adaptive without rewriting everything. The ability to cache a successful AI action as a replayable deterministic step is the feature that makes it viable in CI.

Limitation. You are still maintaining a Playwright codebase, with all the environment and versioning issues that implies. The AI primitives reduce brittleness; they do not eliminate the need for browser automation expertise.

Source. https://github.com/browserbase/stagehand

32. Skyvern

What it does. Automates browser-based workflows using vision and DOM analysis together, with an emphasis on repeatable business processes — filling forms, downloading invoices, completing multi-step applications across many similar sites.

Deployment model. Docker Compose or Kubernetes, with a web UI, a workflow builder, and a REST API.

License. AGPL-3.0. Verified against the LICENSE file, which contains the full GNU Affero General Public License v3.0 text.

Best fit. Operations teams automating the same process across hundreds of sites that differ cosmetically. The workflow builder makes it usable by people who will not write Playwright code.

Limitation. The AGPL is the decision point. If you offer modified Skyvern to users over a network, you must publish your modifications under the AGPL. That is fine for internal use and a genuine constraint for anyone embedding it in a commercial SaaS product. Read section 13 before you build on it.

Source. https://github.com/Skyvern-AI/skyvern

33. Playwright MCP

What it does. Exposes browser control to any MCP-compatible agent as a set of tools operating on Playwright's accessibility tree rather than on screenshots, which makes actions deterministic and cheap.

Deployment model. MCP server, run locally via npx or in a container, attached to whichever agent client you use.

License. Apache-2.0.

Best fit. Giving an existing agent browser capability without adopting a browser-agent framework. Because it is an MCP server, the same configuration works across every client that speaks the protocol.

Limitation. It is a tool server, not an agent. All planning, error recovery, and retry logic remain your agent's responsibility, and the accessibility-tree approach struggles on applications that render to canvas.

Source. https://github.com/microsoft/playwright-mcp

34. UI-TARS Desktop

What it does. A desktop application that lets a vision-language model control the computer directly — moving the mouse, typing, and reading the screen — rather than working through a browser DOM.

Deployment model. Desktop application for macOS and Windows, with the underlying model served locally or remotely.

License. Apache-2.0.

Best fit. Automating desktop applications that have no API and no web interface. This is the only category of automation that reaches legacy Windows software.

Limitation. Full computer control with no sandbox boundary. The agent can do anything the logged-in user can do, including deleting files and sending messages. Run it on a dedicated machine or a virtual machine, never on your primary workstation.

Source. https://github.com/bytedance/UI-TARS-desktop

35. Open Interpreter

What it does. Runs a language model that writes and executes code locally — Python, JavaScript, shell — to accomplish tasks on your machine, with a confirmation prompt before each execution by default.

Deployment model. Python package, run as a CLI or imported as a library. Executes on the host machine unless you configure a container.

License. AGPL-3.0.

Best fit. Ad-hoc local automation where writing the script yourself would take longer than describing it: batch file conversions, data munging, system inspection. The confirmation prompt makes exploratory use survivable.

Limitation. Two constraints. Executing generated code on the host is genuinely dangerous, and disabling confirmation for convenience removes the only guardrail. The AGPL also carries the same network-use obligations as Skyvern, which matters if you wrap it in a service.

Source. https://github.com/openinterpreter/open-interpreter

---

Memory, retrieval, and knowledge

Agents without memory repeat their mistakes. These projects are the difference between a demo and a system.

36. Letta

What it does. An agent server built on the memory architecture from the MemGPT research — agents manage their own context window, moving information between an in-context working memory and external storage, with all state persisted in a database.

Deployment model. Self-hosted service with a REST API and a development UI. Agents are server-side entities you address by ID rather than objects in your process.

License. Apache-2.0. Verified against the LICENSE file, which contains the unmodified Apache 2.0 text with a copyright notice for the Letta authors.

Best fit. Long-lived agents that must remember a user across months of interaction. The stateful server model means an agent survives your application restarting, which most frameworks cannot claim.

Limitation. The server-centric design is a commitment. Your agent logic lives inside Letta's model rather than in your application code, which is a harder architecture to migrate away from than a library.

Source. https://github.com/letta-ai/letta

37. Mem0

What it does. A memory layer that extracts salient facts from conversations, deduplicates and updates them, and retrieves relevant memories at inference time. It supports both vector and graph-backed stores.

Deployment model. Python and TypeScript libraries, or a self-hosted service. Storage backends are pluggable.

License. Apache-2.0.

Best fit. Adding user-level memory to an existing agent without restructuring it. The API is small — add, search, update — and integrates in an afternoon.

Limitation. Extraction quality determines everything downstream, and extraction is itself a model call that can misjudge what mattered. Budget for the extra latency and cost of every turn triggering memory operations.

Source. https://github.com/mem0ai/mem0

38. Graphiti

What it does. Builds a temporally-aware knowledge graph from a stream of episodes. Facts carry validity intervals, so the graph records that something was true during a period rather than overwriting history when it changes.

Deployment model. Python library backed by a graph database. Also available as an MCP server.

License. Apache-2.0.

Best fit. Agents that need to reason about how state changed over time — customer accounts, incident timelines, entity relationships that evolve. Standard vector memory cannot answer "what did we believe last quarter" and this can.

Limitation. Requires operating a graph database, and ingestion is expensive because each episode triggers extraction and reconciliation model calls. Overkill for agents that only need recent conversation recall.

Source. https://github.com/getzep/graphiti

39. RAGFlow

What it does. A retrieval engine built around deep document understanding — layout analysis, table extraction, and chunking strategies chosen per document type — with an agent layer on top for multi-step question answering.

Deployment model. Docker Compose. Ships with a full web UI for document management, chunk inspection, and chat.

License. Apache-2.0.

Best fit. Corpora of complex documents — scanned PDFs, financial filings, technical manuals with tables — where naive chunking destroys the meaning. The chunk visualization UI is the feature that saves the most debugging time.

Limitation. Heavy deployment. The document-parsing stack has substantial resource requirements, and the full Docker Compose stack is not something you casually run on a laptop.

Source. https://github.com/infiniflow/ragflow

40. Onyx

What it does. Connects to your organization's systems — Slack, Drive, Confluence, Jira, and many more — indexes them with permission awareness, and answers questions with an agentic search that decomposes complex queries into sub-searches.

Deployment model. Docker Compose or Kubernetes. Fully self-hostable including the model layer.

License. MIT for the core, with a carve-out. The LICENSE file states that content under ee directories — backend/ee, web/src/app/ee, and web/src/ee — is licensed under the Onyx Enterprise License, and everything else is available under the MIT Expat license. The base product is a complete, usable enterprise search system without the ee directories.

Best fit. Internal knowledge assistants where document-level permissions must be honored. The permission-aware indexing is the hard part, and it is in the MIT core.

Limitation. Single sign-on, granular access control, and some analytics live in the enterprise directories. Teams that need those will be having a commercial conversation, so evaluate against the MIT core specifically rather than against the marketing site.

Source. https://github.com/onyx-dot-app/onyx

---

Runtime, gateway, and sandboxing

41. LiteLLM

What it does. Normalizes over a hundred model providers behind one OpenAI-compatible interface, with retries, fallbacks, load balancing, per-key budgets, and rate limiting. Usable as a library or as a standalone proxy server.

Deployment model. Python library, or a proxy deployed as a container in front of your agents.

License. MIT for the core, with a carve-out. The LICENSE file states that content under the enterprise/ directory is licensed separately under enterprise/LICENSE; everything else is MIT. The proxy, routing, fallback, and budget features that most teams need are in the MIT portion.

Best fit. Any agent system talking to more than one model provider. Putting the proxy in front of everything gives you a single place to enforce spend limits and to swap models without touching agent code.

Limitation. It is another network hop and another service to keep available. If the proxy is down, every agent is down, so it needs the same redundancy treatment as any other critical path component.

Source. https://github.com/BerriAI/litellm

42. vLLM

What it does. A high-throughput inference server for open-weight models, using paged attention and continuous batching to serve many concurrent requests efficiently. Exposes an OpenAI-compatible API.

Deployment model. Service on GPU hardware, containerized or bare metal.

License. Apache-2.0.

Best fit. Serving open-weight models to agents at volume. Agent workloads generate many concurrent requests with wildly varying sequence lengths, which is precisely what continuous batching handles well.

Limitation. GPU-bound and operationally demanding. Memory configuration, quantization choices, and model-specific quirks require real expertise, and CPU-only deployment is not a serious option.

Source. https://github.com/vllm-project/vllm

43. Ollama

What it does. Runs open-weight models locally with a single command, handling download, quantization selection, and serving behind a local API.

Deployment model. Desktop application or a background service on macOS, Linux, and Windows.

License. MIT.

Best fit. Development, prototyping, and privacy-constrained deployments where data must not leave the machine. It is the fastest path from nothing to a working local model endpoint. For the fuller picture of running agents entirely on your own hardware, see the best local AI agents.

Limitation. Optimized for single-user convenience, not multi-tenant throughput. Under concurrent load it is substantially slower than a dedicated inference server, and it is not the right choice for a production service.

Source. https://github.com/ollama/ollama

44. E2B

What it does. Provides isolated cloud sandboxes — microVMs — where agent-generated code executes with a filesystem, network access, and a lifecycle you control from an SDK.

Deployment model. Self-hostable infrastructure, or the maintainers' hosted service. SDKs for Python and TypeScript.

License. Apache-2.0.

Best fit. Any agent that runs generated code. The isolation boundary is a virtual machine rather than a container, which is a meaningfully stronger guarantee against escape.

Limitation. Self-hosting the infrastructure is significantly more involved than running a container, so most teams end up on the hosted service. Sandbox startup latency also affects the responsiveness of interactive agents.

Source. https://github.com/e2b-dev/E2B

45. Temporal

What it does. Durable execution. Workflow code runs to completion despite process crashes, machine failures, and multi-day waits, because the runtime persists every step and replays deterministically on recovery.

Deployment model. A server cluster you operate, plus SDKs in Go, Java, Python, TypeScript, .NET, and PHP. A managed cloud exists.

License. MIT.

Best fit. Agents whose work spans hours or days, involves human approval steps, or must never lose progress. Model calls become activities with automatic retries, and an agent that dies mid-task resumes exactly where it stopped.

Limitation. Substantial operational commitment — the server cluster has real dependencies and real tuning requirements. The determinism constraints on workflow code also take time to internalize, and violating them produces confusing failures.

Source. https://github.com/temporalio/temporal

---

Observability, evaluation, and safety

An agent you cannot inspect is an agent you cannot operate.

46. Langfuse

What it does. Traces agent executions — every model call, tool invocation, and nested span — with cost and latency attribution, prompt version management, dataset-based evaluation, and human annotation queues.

Deployment model. Docker Compose or Kubernetes, self-hosted. SDKs for Python and TypeScript, plus native integrations with most frameworks on this list. A managed cloud exists.

License. MIT for the core, with a carve-out. The LICENSE file states that content under ee/, web/src/ee/, and worker/src/ee/ is licensed under ee/LICENSE, and everything outside those directories is available under the MIT Expat license. Tracing, prompt management, datasets, and evaluation are in the MIT core.

Best fit. Teams that need agent observability on their own infrastructure for data-residency reasons. The self-hosted deployment is a first-class path, not a degraded one.

Limitation. The clean-room MIT core excludes some access-control and analytics features. Verify which specific features you need against the ee/ directory contents before assuming the free tier covers your compliance requirements.

Source. https://github.com/langfuse/langfuse

47. Opik

What it does. Traces LLM and agent applications and pairs the traces with an evaluation framework — LLM-as-judge metrics for hallucination, relevance, and moderation, plus your own custom metrics — runnable in development and in CI.

Deployment model. Docker Compose or Kubernetes for self-hosting. Python and TypeScript SDKs. A managed cloud exists.

License. Apache-2.0.

Best fit. Teams that want tracing and systematic evaluation in one system, under a single permissive license with no enterprise directory to reason about.

Limitation. LLM-as-judge metrics are themselves model outputs and carry their own error rate. Calibrate them against human labels before you gate a release on them.

Source. https://github.com/comet-ml/opik

48. promptfoo

What it does. Declarative testing for prompts and agents. You define test cases and assertions in a configuration file and run them from the CLI or in CI, comparing outputs across models and prompt variants side by side. It also includes an adversarial red-team generator.

Deployment model. Node CLI and library. Runs locally and in CI; no server required.

License. MIT.

Best fit. Putting agent behavior under regression testing. The configuration-file approach means your test suite is a reviewable artifact in the repository rather than a notebook someone ran once.

Limitation. Assertions on free-form text are fundamentally harder than assertions on structured output. Expect to invest real effort designing assertions that catch regressions without failing on harmless rewording.

Source. https://github.com/promptfoo/promptfoo

49. NeMo Guardrails

What it does. Adds a programmable rail layer around a conversational agent — input rails, output rails, dialog rails, and execution rails — defined in a dedicated modeling language, enforcing topic boundaries and blocking unsafe content before it reaches the model or the user.

Deployment model. Python library or a server exposing a guarded chat endpoint.

License. Apache-2.0.

Best fit. Deployments with regulatory or brand constraints on what the agent may discuss, where the constraint must be enforced outside the system prompt.

Limitation. The rail definition language is a real language with a learning curve, rails add latency to every turn, and a determined prompt injection can still get through. Defense in depth, not a boundary.

Source. https://github.com/NVIDIA-NeMo/Guardrails

50. garak

What it does. A vulnerability scanner for language models and agents. It runs a catalog of attack probes — prompt injection, jailbreaks, data leakage, encoding attacks, toxicity elicitation — and reports which succeeded.

Deployment model. Python CLI, pointed at a model endpoint or an agent API.

License. Apache-2.0.

Best fit. Pre-deployment security assessment, and regression testing after prompt or model changes. It is the closest thing to a standard scanner in this space, and it produces evidence you can hand to a security reviewer.

Limitation. Scans a known catalog. It will not find the injection vector specific to your tool schema or your retrieval corpus, and a clean report is a floor rather than a clearance.

Source. https://github.com/NVIDIA/garak

---

Other source-available projects worth knowing

These six projects appear on nearly every "open source AI agents" list. None is open source under the OSI definition. They are still relevant to a guide that explicitly covers source-available systems, but they are not in the ranked fifty because this edition reserves the source-available slot for the complete local agent system we can verify most deeply: AGNT. Each is legitimate software; the distinction here is the license, not product quality. The quoted terms below were read from each project's LICENSE file on 2026-08-11.

n8n — Sustainable Use License. The license limits you to using or modifying the software "only for your own internal business purposes or for non-commercial or personal use," and permits distribution "only if you do so free of charge for non-commercial purposes." Files with .ee. in the filename or .ee in the directory name are excluded entirely and require an n8n Enterprise License. The project describes itself as fair-code, not open source. That description is accurate.
https://github.com/n8n-io/n8n

Dify — a modified Apache License 2.0. Two additional conditions: you may not use the source to operate a multi-tenant environment without written authorization, and you may not remove or modify the logo or copyright information in the console or applications when using the frontend. Either condition alone disqualifies it from the OSI definition.
https://github.com/langgenius/dify

Open WebUI — the "Open WebUI License," a BSD-3-Clause base with an added fourth clause. Licensees are "strictly prohibited from altering, removing, obscuring, or replacing any 'Open WebUI' branding," with an exemption only for deployments under fifty users in a rolling thirty-day period, or with written permission, or under a purchased enterprise license. Earlier releases remain under their original terms per the project's LICENSE_HISTORY file, so a fork from before the change has different rights than current main.
https://github.com/open-webui/open-webui

AutoGPT Platform — PolyForm Shield License 1.0.0 for everything inside the autogpt_platform directory, which is the actively developed product. That license permits any purpose "except for providing any product that competes with the software or any product the licensor or any of its affiliates provides using the software." Everything outside autogpt_platform — including the original standalone AutoGPT agent, Forge, and the benchmark — remains MIT. The MIT portion is open source; the platform is not.
https://github.com/Significant-Gravitas/AutoGPT

Suna (Kortix) — Elastic License 2.0. You may not provide the software to third parties as a hosted or managed service, and you may not circumvent the license key functionality. This one is mislabeled more often than any other project in this appendix.
https://github.com/kortix-ai/suna

Arize Phoenix — Elastic License 2.0, with the same hosted-service prohibition. Phoenix is a capable tracing and evaluation tool and is free to run internally. It is not open source, and if you are choosing an observability layer partly for licensing reasons, Opik and the Langfuse MIT core are the comparable options that are.
https://github.com/Arize-ai/phoenix

Open core is not the same thing

Three projects in the fifty — Mastra, Langfuse, LiteLLM — and one that narrowly missed it, Flowise, use a split license: an OSI-licensed core plus a directory under commercial terms. Flowise's LICENSE places everything under packages/server/src/enterprise and files carrying an explicit copyright notice under a commercial license, with all remaining content under Apache 2.0.

This is a different situation from the appendix entries. With open core, the software you can actually run is under an OSI license, and you retain the right to fork it, modify it, host it for others, and compete with the vendor. What you cannot do is use the specific enterprise code. With Elastic 2.0, PolyForm Shield, or the Sustainable Use License, the restriction applies to the entire program.

The practical test: read the enterprise directory listing and ask whether the product still does what you need without it. For Mastra, Langfuse, LiteLLM, and Flowise, the answer for most teams is yes. Confirm it for your own requirements rather than taking anyone's word for it, including this article's.

---

Security checklist before you deploy an agent

Agents combine three properties that security tooling was not designed for: they take instructions from untrusted content, they hold credentials, and they act without a human confirming each step. Work through this list before anything reaches production.

Isolation

• Run every agent that executes generated code inside a container or microVM, never on the host. Container escape is a known risk; host execution is not a risk, it is a guarantee of full compromise on first bad output.
• Give the sandbox a filesystem that contains only what the task requires. Mount nothing read-write that you would mind losing.
• Default the sandbox to no network egress, then allowlist the specific hosts the task needs. Unrestricted egress turns any prompt injection into data exfiltration.
• Set CPU, memory, and wall-clock limits on every execution. An agent in a retry loop will consume whatever you let it.

Credentials

• Issue each agent its own identity with its own scoped credentials. Never share a service account across agents, and never give an agent a human's credentials.
• Scope tokens to the narrowest capability that completes the task. An agent that reads Jira issues does not need write access to Jira.
• Keep secrets out of the model's context entirely. Inject them at the tool boundary so they cannot be echoed into a response or a trace.
• Set short expiry and rotate on a schedule. Assume any credential an agent has touched is disclosed.

Input and tool boundaries

• Treat all retrieved content — web pages, documents, emails, tool responses — as untrusted input carrying potential instructions. Prompt injection is delivered through content, not through the user's message.
• Validate tool arguments against a schema before execution, and reject rather than coerce. A typed validation layer catches a meaningful share of malformed and adversarial calls.
• Require human approval for irreversible actions: sending external communications, moving money, deleting data, modifying production configuration, or publishing anything.
• Enforce allowlists for tools per agent role. The planning agent should not have the deployment tool available at all, rather than being instructed not to use it.

Supply chain

• Audit every MCP server and plugin before installing it. An MCP server runs with your agent's permissions and sees your agent's data.
• Pin dependency versions and review changes. The agent ecosystem moves fast and publishes breaking changes and, occasionally, compromised packages.
• Verify licenses at adoption and again at each major upgrade. Four projects commonly recommended as open source changed to restrictive terms in the last two years, and a license change lands in a routine dependency bump.

Observability and limits

• Trace every model call, tool call, and agent handoff, and retain the traces long enough to investigate an incident found weeks later.
• Set hard spend limits per agent, per user, and per session, enforced at the gateway rather than in agent code. Agent code is exactly what fails during a runaway loop.
• Alert on behavioral anomalies: unusual tool sequences, sudden token growth, repeated failures on the same step.
• Cap loop iterations and total task duration. Every agent needs a condition under which it stops and asks for help.

Data handling

• Decide explicitly which data may reach a hosted model API and enforce it at the gateway. If the answer is none, self-host the model.
• Redact personal data before it enters traces. Observability tooling becomes a secondary data store with its own breach surface.
• Confirm the data-retention and training terms of every model provider your gateway routes to, including the fallbacks you configured and forgot about.

---

Frequently asked questions

What makes an AI agent open source rather than source-available?

An open-source license grants the right to use, modify, and redistribute the software for any purpose, including commercial use and including competing with the original author. MIT, Apache 2.0, BSD, GPL, and AGPL all qualify. Source-available licenses publish the code but restrict what you may do with it — commonly forbidding hosted-service offerings, forbidding removal of branding, or forbidding competition with the vendor. Elastic License 2.0, PolyForm Shield, the Business Source License, and n8n's Sustainable Use License are all source-available. You can read the code and usually run it internally for free; you have not received open-source rights.

Does the license actually matter if I am only using the software internally?

Often not, and that is worth saying plainly. Most restrictive licenses permit unlimited internal use. The license matters when your circumstances change: you decide to offer the capability to customers, you get acquired by a company that already competes with the vendor, you want to white-label the interface, or you need to fork the project because upstream abandoned it. Those are the moments when a clause you skipped becomes a rewrite. The cost of checking is ten minutes; the cost of not checking is discovered at the worst time.

Can open-source agents match proprietary ones on quality?

The question conflates two layers. Agent harnesses — the loop, the tool calling, the memory, the sandboxing — are now competitive across open and closed implementations, and several coding agents on this list are the same software the commercial products are built on. The model is where the gap sits, and it varies by task. For code generation and tool use, open-weight models have closed much of the distance; for long-horizon reasoning over ambiguous goals, frontier proprietary models still lead. The practical answer is an open harness with a model chosen per task, which is why a routing gateway like LiteLLM appears on this list.

Which license should I prefer when I have a choice?

Apache 2.0 for anything you will build a product on, because it includes an explicit patent grant that MIT lacks. MIT is fine and simpler. AGPL is fine for internal deployment and requires a deliberate decision for anything network-facing, because modifications you serve to users must be published. Open-core projects are usually fine, but read the enterprise directory listing first and confirm the core does what you need.

How do I evaluate whether an agent project will still be maintained?

Ignore star counts. Read the last three release notes and check whether they contain substance or version bumps. Open the issue tracker and look at how old the oldest open bug with a reproduction is. Check whether pull requests from outside contributors get merged or stall. Check whether the project has a funded company behind it, and if so, whether the open-source version is the product or a lead generator for the product — the second pattern is the one that produces license changes.

Do I need a framework at all?

For a single agent with a handful of tools, no. A loop that calls a model, parses tool calls, executes them, and appends results is roughly two hundred lines, and you will understand every failure. Frameworks earn their weight when you need persistence across restarts, human-in-the-loop approval, multi-agent coordination, or distributed execution. Building those yourself is where the year goes. The agent architectures guide covers where each threshold sits.

What is the minimum viable production stack from this list?

A complete operating system such as AGNT when you want agents, workflows, goals, memory, tools, approvals, and traces in one install; or a framework for the loop — LangGraph or the OpenAI Agents SDK — when you want to assemble the rest of the stack yourself. LiteLLM in front of your model providers for routing and spend control. Langfuse or Opik for tracing. E2B or a container for anything executing generated code. promptfoo in CI for regression testing. That is five components, all permissively licensed and self-hostable. AGNT packages the corresponding operating concerns into one source-available local system when reducing integration surface matters more than using only OSI licenses. Add memory when you have evidence you need it, not before.

Can I run all of this without sending data to a model vendor?

Yes. Ollama or vLLM serves open-weight models on your own hardware, LiteLLM routes to them with the same API surface, and every other project on this list is self-hostable. The trade-off is capability at the model layer and the operational cost of running GPUs. The best local AI agents covers what that stack looks like in practice and where the quality ceiling currently sits.

---

How to use this list

Do not start by choosing a framework. Start by writing down the task, the tools it needs, whether it can fail silently, and who has to approve its actions. That description eliminates most of this list immediately.

If the task is coding, start with a terminal or IDE agent from the first section and give it a repository with good tests. If the task is a business process with defined steps, start with a framework that makes the control flow explicit and add durability when the process gets long. If the task involves a website with no API, budget more time than you expect, because browser agents remain the least reliable category here.

Then verify the license yourself, on the day you commit. Four of the six appendix entries were described as open source in widely-read articles before the terms changed under them. The LICENSE file is authoritative; nothing else is, including this page.