LangGraph
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
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.
What a featured listing costs ยท from $99 a month
Library for building agents as graphs of steps with saved state, pauses for human review and streaming, in Python and JavaScript.
Python framework for multi-agent work where each agent has a role and goal and a crew of agents shares a list of tasks.
Microsoft's open-source framework for multi-agent conversations, with a Python API and a low-code studio for testing agent teams.
Framework for agents that work over your documents, with data loaders, indexing, retrieval and event-driven workflows.
Lightweight SDK for agents with tools, handoffs between agents, guardrails and built-in tracing, available for Python and TypeScript.
Python agent framework from the Pydantic team that uses type hints to validate tool inputs and structured model outputs.
Microsoft SDK for adding models, plugins and agents to apps written in C#, Python and Java.
Small Python library from Hugging Face for agents that write and run code as their actions, with any model you choose.
TypeScript framework for agents, workflows, memory and evals, aimed at web developers working in Node.js.
Google's open-source kit for building and testing single and multi-agent systems, with a local web UI for debugging runs.
Platform and open-source server for stateful agents that keep long-term memory across sessions, from the MemGPT research team.
Python framework from deepset for building retrieval pipelines and agents from swappable components.
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.
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.
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.
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.
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.
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.