What an open-source AI agent actually means
An AI agent is software that uses a model to interpret a goal, choose actions, call tools, observe results, and continue until it reaches a stopping condition. Open source describes the software rights and access around that system. It is not a statement about intelligence, autonomy, quality, or safety. A public GitHub repository may expose the loop that coordinates a model and tools while leaving the model, data, hosting, and monitoring under somebody else's control. Sources: Open Source Initiative.
The Open Source Initiative frames open-source AI at the system level. People need the freedoms to use, study, modify, and share the system, plus access to the preferred form for making modifications. That definition is useful because agent products are assembled systems. Looking only at the license on an orchestration library can hide the commercial API, proprietary data, remote tool service, or managed control plane that the agent still requires. Sources: Open Source Initiative.
So the useful buyer question is not simply, Is this agent open source? Ask which layer is open, which layer is replaceable, and which layer still depends on a vendor account. That shift turns a vague label into a concrete architecture review.
Which parts of the agent stack can be open
A production agent is a chain of control points. The framework defines how work is represented. The runtime executes the loop. A model proposes decisions. Connectors reach external systems. Memory and retrieval provide context. Identity and policy decide what the agent may do. Observability records what happened. Deployment determines where all of this runs. Any one of those layers can be open, closed, self-hosted, or delivered as a service.
This is why two products can both market themselves as open-source agents and create very different operating positions. One might be a permissively licensed library that runs in your environment with replaceable models. Another might publish a client SDK but require a hosted control plane for durable state, tracing, or deployment. Neither pattern is automatically wrong. They offer different kinds of control.
| Layer | What to inspect | Why it matters |
|---|---|---|
| Orchestration | Planning, routing, state transitions, retries | Determines whether core behavior can be changed |
| Model | Weights, license, API dependency, data terms | Controls capability, cost, privacy, and portability |
| Tools and protocols | Connector code, schemas, permissions, remote servers | Defines what the agent can reach and change |
| Memory and data | Storage location, export, deletion, retrieval logic | Affects privacy, continuity, and migration |
| Runtime and deployment | Worker, scheduler, sandbox, hosting requirements | Determines operational independence |
| Identity and observability | Credentials, policy checks, logs, evaluation data | Determines accountability and incident response |
Framework, runtime, and harness are different things
An agent framework is the developer-facing set of abstractions used to describe agents, tools, handoffs, graphs, and state. A runtime is the execution environment that schedules those components, persists progress, handles failures, and applies operational rules. A harness is the surrounding application code and instructions that connect a model to a specific task. The words overlap in vendor descriptions, but the distinction matters during selection.
A framework can be fully open while a managed runtime adds proprietary deployment, tracing, identity, or evaluation services. Conversely, a team can use an open runtime with a closed model API. OpenAI describes its Agents SDK as an open-source foundation with tools, handoffs, tracing, and guardrails, while its broader platform also provides hosted capabilities. LangGraph documents a low-level orchestration framework for long-running, stateful agents and separately offers deployment infrastructure. CrewAI similarly pairs an open framework with a managed platform. Sources: OpenAI; LangChain; CrewAI.
Map the dependency you would have to replace if the managed service changed price, policy, geography, or availability. That dependency, not the repository badge, is the practical boundary of control.
Representative open agent frameworks active now
There is no single best open-source agent framework. The right choice depends on the shape of the work, the languages your team operates, and how much runtime behavior you need to control. The examples below are representative, not a ranking.
OpenAI's Agents SDK is a compact set of primitives for agents, tools, handoffs, guardrails, sessions, and tracing. In April 2026, OpenAI announced a broader evolution that keeps the SDK open source while aligning it with its hosted platform and visual builder. It is a sensible path when teams want a small abstraction layer and close compatibility with OpenAI services, but the surrounding service dependencies still need to be mapped. Sources: OpenAI.
Google's Agent Development Kit is an open-source, model-agnostic framework designed for multi-agent applications. Google introduced it with support for multiple model providers and deployment choices, then continued documenting it as a flexible framework for agent development. It is relevant for teams that want explicit multi-agent composition and a path into Google's cloud ecosystem without making that ecosystem the only possible model source. Sources: Google; Google.
Microsoft Agent Framework reached version 1.0 in April 2026. Microsoft positions it as the convergence of AutoGen and Semantic Kernel patterns, with graph workflows, middleware, observability, multiple language SDKs, and options spanning local development and Azure services. It deserves attention from teams already operating Microsoft identity, data, and cloud systems, while still requiring a clear view of which production services are optional and which become operational dependencies. Sources: Microsoft.
LangGraph focuses on durable, stateful orchestration with explicit graphs, persistence, human oversight, and long-running execution. CrewAI emphasizes agents, crews, and flows for collaborative task automation. Their abstractions encourage different mental models. A team should prototype the real workflow in two plausible candidates and compare failure recovery, state inspection, testing, and operational burden, not just the speed of a tutorial. Sources: LangChain; CrewAI.
Can an open agent use a closed model?
Yes. Open orchestration and closed model access are compatible. Many useful systems combine an open framework with a commercial model API because the team values inspectable workflow code while buying model capability as a service. The inverse is also possible: an open-weight model can run inside proprietary orchestration.
The tradeoff is that an open framework does not remove the model provider's price, availability, policy, privacy, or regional constraints. Ask whether model calls sit behind a clean interface, whether prompts and tool schemas are portable, whether evaluations can be rerun against another model, and whether behavior depends on provider-specific features. Model portability is rarely free, but deliberate boundaries keep it possible.
For sensitive workloads, inspect what leaves your environment, how long providers retain it, and whether tool results or memory are sent back to the model. The license on the agent loop cannot answer those data-governance questions.
Open source reduces some lock-in, not all lock-in
Source access can reduce lock-in by letting a team fork orchestration code, run it in a chosen environment, and repair or extend behavior without waiting for a vendor. It also improves auditability. But operational lock-in can move into hosted tracing, proprietary memory formats, identity integrations, remote tools, evaluation data, or deployment assumptions.
Open protocols help at system boundaries. The Agent2Agent protocol is now hosted by the Linux Foundation, and the foundation reported broad organizational adoption and production use in 2026. Model Context Protocol defines a common way for AI applications to connect with tools and context. These protocols can make components easier to connect and replace, but interoperability does not guarantee portability of state or equivalence of behavior. Sources: Linux Foundation; Model Context Protocol.
The Roundup's public archive keeps surfacing the same industry pattern: advantage is shifting from a model alone toward deployment, distribution, credentials, workflow integration, and trust. For open agents, that means code access matters, but control of the surrounding system matters more. Export tests are more revealing than architecture diagrams. Try moving traces, memory, tool configuration, and evaluation cases before committing.
Open code does not make an agent secure
Agents combine untrusted language inputs with credentials and actions, so their failure modes are broader than ordinary chat. OWASP's agentic risk work highlights threats such as goal hijacking, tool misuse, identity and privilege abuse, unsafe code execution, memory poisoning, insecure inter-agent communication, and supply-chain failures. NIST's agent work also centers secure interoperability, identity, authority, and practical security considerations. Sources: OWASP GenAI Security Project; National Institute of Standards and Technology; National Institute of Standards and Technology; National Institute of Standards and Technology.
Treat every tool call as a privileged operation. Give each agent its own identity. Use short-lived, narrowly scoped credentials. Separate read and write tools. Validate parameters outside the model. Require explicit approval for consequential actions. Sandbox code execution and risky parsers. Log the decision, inputs, tool call, result, and policy outcome in a form investigators can understand.
Protocols need the same discipline. MCP security guidance warns against confused-deputy problems, token passthrough, session hijacking, and weak consent flows. Its authorization specification requires tokens to be bound to the intended audience. A connector that accepts a powerful token from any client may be interoperable and still be dangerously designed. Sources: Model Context Protocol; Model Context Protocol.
- Keep credentials outside prompts, memory, source repositories, and generated logs.
- Default agents to least privilege and add capability only after a tested need.
- Make external content untrusted, even when it arrives through an approved connector.
- Test interruption, retries, duplicate actions, revoked access, and partial failure.
- Maintain a human-readable audit trail and a way to stop the workflow safely.
How to compare open-source agent stacks
Start with one real workflow, not a generic feature checklist. Define its inputs, tools, data sensitivity, maximum authority, acceptable latency, expected volume, failure cost, and human checkpoints. Then build the smallest end-to-end slice in the two most plausible stacks.
Score control and operations before developer ergonomics. Can you run the critical path in your environment? Can you inspect state after failure? Can you replay an execution? Can you replace the model, tool server, memory store, or tracing backend? Can your security team express policy outside the prompt? Can operators understand what happened without reading framework internals?
Finally, price the whole system. Include model calls, managed services, databases, observability, evaluation, support, engineering time, security review, and incident response. Open software can lower license costs while increasing integration or operating work. A managed service can be the rational choice when it removes undifferentiated burden without taking away a control boundary the business needs.
- License: Are the critical components under terms your legal team accepts?
- Replaceability: Can models, tools, storage, and hosted services be swapped behind stable interfaces?
- Durability: Does the runtime recover correctly from pauses, retries, crashes, and duplicate events?
- Security: Are identity, authorization, isolation, approvals, and audit logs first-class controls?
- Evaluation: Can you test task success, policy compliance, cost, and regression on your own cases?
- Operations: Can your team deploy, observe, upgrade, and debug the stack at the required reliability?
- Community: Is the project maintained, documented, and governed in a way that matches your risk horizon?
When an open-source agent is the wrong choice
Open source is not automatically the best operating model. A small team with a standard workflow may get more value from a mature managed product with strong controls, clear support, and predictable service levels. Owning code does not create the staff, monitoring, security review, or incident process needed to operate it safely.
Avoid introducing an agent when a deterministic workflow can solve the problem more safely and cheaply. Rules, queues, and ordinary software are better when the steps are known and exceptions are bounded. Use an agent where language interpretation, variable planning, or flexible tool choice creates measurable value.
The practical conclusion is simple. Choose open-source AI agents for the control you can verify, not for the label. Draw the complete stack, mark every external dependency, test the failure paths, and decide which boundaries the business genuinely needs to own.
Limits and uncertainty
This guide describes representative frameworks and control questions, not a benchmark or ranked list. Framework capabilities, licenses, managed services, and protocol specifications can change after publication. Security depends on the exact deployment, tool permissions, identity design, and operating process. Teams should verify current project documentation and license terms, run workload-specific evaluations, and complete their own legal and security review before production use.