Open-source agent frameworks

An agent framework is a code library that handles the repetitive parts of building an agent: sending messages to a model, parsing the tool calls it asks for, running those tools, feeding the results back and deciding when to stop. You still write the instructions, the tools and the rules, but you do not have to write the loop and the plumbing from scratch each time.

The frameworks here differ mainly in how much structure they impose. Some treat an agent as a graph, where each step is a node and you draw the paths between them, including loops and branches. That gives you explicit control over order and makes it easier to pause for human review at a known point. Others treat an agent as a role with a goal and let several such agents pass work between them. That is quicker to set up but harder to predict. A third group stays small on purpose and gives you a thin layer over model calls, tool definitions and typed outputs.

Language matters more than it looks. Most frameworks started in Python, and several now have TypeScript or JavaScript versions. Some are TypeScript first and fit naturally into a web team's stack. A few support C# or Java for teams in those ecosystems. Pick one that matches the language your production services already use, because the agent will need to call those services.

State and memory are where frameworks separate in production. A demo agent forgets everything when the script ends. A real one may need to save its progress after each step, resume after a crash, wait hours for a person to approve something, and remember facts across sessions. Check whether the framework can persist state to a database you run, and how it handles a run that is paused for a long time.

12 AI agent tools in open-source agent frameworks

LangGraph

by LangChain

Library for building agents as graphs of steps with saved state, pauses for human review and streaming, in Python and JavaScript.

  • Open source
  • Can run on your own servers

CrewAI

Python framework for multi-agent work where each agent has a role and goal and a crew of agents shares a list of tasks.

  • Open source
  • Can run on your own servers

AutoGen

by Microsoft

Microsoft's open-source framework for multi-agent conversations, with a Python API and a low-code studio for testing agent teams.

  • Open source
  • Can run on your own servers

LlamaIndex

Framework for agents that work over your documents, with data loaders, indexing, retrieval and event-driven workflows.

  • Open source

OpenAI Agents SDK

by OpenAI

Lightweight SDK for agents with tools, handoffs between agents, guardrails and built-in tracing, available for Python and TypeScript.

  • Open source
  • Works with MCP

Pydantic AI

by Pydantic

Python agent framework from the Pydantic team that uses type hints to validate tool inputs and structured model outputs.

  • Open source
  • Works with MCP

Semantic Kernel

by Microsoft

Microsoft SDK for adding models, plugins and agents to apps written in C#, Python and Java.

  • Open source

smolagents

by Hugging Face

Small Python library from Hugging Face for agents that write and run code as their actions, with any model you choose.

  • Open source

Mastra

TypeScript framework for agents, workflows, memory and evals, aimed at web developers working in Node.js.

  • Open source
  • Works with MCP

Agent Development Kit

by Google

Google's open-source kit for building and testing single and multi-agent systems, with a local web UI for debugging runs.

  • Open source

Letta

Platform and open-source server for stateful agents that keep long-term memory across sessions, from the MemGPT research team.

  • Open source
  • Developer API

Haystack

by deepset

Python framework from deepset for building retrieval pipelines and agents from swappable components.

  • Open source

Model choice should stay open. Most of these libraries work with several model providers, and some are tied more closely to one. Even if you plan to use a single provider, being able to swap models makes testing and cost control easier.

Look at observability before you commit. You will need to see each step an agent took, with inputs and outputs, to debug it. Some frameworks ship their own tracing, and others send traces to outside tools through OpenTelemetry or their own integrations.

Finally, be honest about the cost of a framework versus plain code. For a single model call with two tools, a framework can add more concepts than it saves. Frameworks pay off when agents need branching, retries, multiple agents, long-running state or many tools, and when several developers need a shared way of building them.

Testing is easier in some frameworks than others. Look for a way to run an agent against a fixed set of inputs with the model calls recorded, so a change to a prompt or tool can be checked without paying for a full run each time. Frameworks with a local debugging interface, where you can step through a run and inspect the state at each node, shorten the path from a strange output to its cause. Also read the project history before you commit: how often it ships breaking changes, how quickly issues get answers, and whether a company or a foundation stands behind it.

Questions about open-source agent frameworks

Should I use a framework or call the model API directly?

For a simple agent with a few tools, direct API calls are often clearer and easier to debug. A framework earns its place when you need saved state, human approval pauses, several cooperating agents, or a common structure that a whole team will follow.

Are open-source frameworks free to run?

The library code is free to use under its license, but you still pay for the model calls, hosting, storage and any tracing service. Some projects also sell a hosted platform or enterprise features on top of the open code.

Can I switch frameworks later?

Your prompts, tools and test cases usually carry over, but the orchestration code does not. Keeping tools as plain functions and keeping business logic outside framework-specific classes makes a later move much easier.

What is the difference between a graph framework and a multi-agent framework?

A graph framework has you define the steps and the paths between them, so the order is explicit. A multi-agent framework has you define agents with roles and lets them pass work among themselves, which is faster to set up and less predictable.

How do these frameworks handle tools from MCP servers?

Several frameworks here can load tools from Model Context Protocol servers, so a tool wrapped once as an MCP server can be used without writing a new integration. Check the framework's docs for which server types and transports it supports.

Related categories