The Open Source Agent Toolkit in 2026

The following article originally appeared on Paolo Perrone’s Substack, The AI Engineer, and is being republished here with the author’s permission.

You spent three weeks shipping an agent. It worked in the demo. Then production hit, and you realized the framework you picked has no checkpointing, the memory layer is a flat vector dump with no temporal reasoning, the browser tool falls over on any site with a canvas element, and the eval suite is a Notion doc someone keeps forgetting to update.

The open source toolkit for building agents in 2026 has solved most of these problems. The catch is that it has solved each one in a dozen incompatible ways. The memory framework that wins LoCoMo (the standard long-conversation memory benchmark) runs 340x heavier per conversation than the runner-up, a difference no benchmark column shows. The same gap between benchmark score and production behavior shows up at every layer.

So the best way to zero in on the constraint your system will hit first under load: latency budget, audit trail, model portability, or language stack. Get this wrong and you rewrite your state schemas in week three.

TL;DR

If you read “The AI Agents Stack (2026 Edition),” this is the open source half. Same seven layers around the think-act-observe loop from “What Is an AI Agent?”: orchestration, memory, tool interface, browser/CUA, coding agents, evals and observability, and inference. Here’s where to start at each layer.

How to pick at each layer

When choosing tools at each layer, ask three questions:

What’s the dominant constraint? Four constraints decide most layer picks. Latency budget is how many tokens or milliseconds you can spend per turn. Audit trail is whether every action has to be traceable for compliance. Model portability is how tied your stack gets to one provider. Language stack is whether your team is Python, TypeScript, or both. One of these usually dominates at each layer.

What’s the rip-out cost if you’re wrong? Swapping an MCP server changes one config line. Swapping orchestration rewrites your state schemas, your nodes, and your edges. The bigger the rewrite, the more you should pick by constraint first.

Is it open source or open core? Open core means the project ships under an open source license, but production features (multitenant auth, replication, SSO, audit logs) only run in the managed cloud product. The repo’s feature list tells you which side of the line you’re buying.

Layer 1: Orchestration and runtime control

The orchestration layer runs the agent’s reasoning cycle. The LLM picks an action, the runtime executes it, the runtime observes the result, and the LLM picks again. If you skip a framework here, you write the loop yourself, which means reinventing retries, checkpointing, and human-in-the-loop gating before you ship.

LangGraph is the default for Python production work. Graph-based state machine, durable execution via PostgresSaver, time-travel debugging, and the largest verified enterprise list in the field (Klarna, Uber, LinkedIn, JPMorgan, Replit). Graph state maps onto what regulated industries need: Every state transition is an audit log entry, and any failed run rolls back to a prior node and replays from there. The ceiling: It’s verbose. A two-agent flow still needs a state schema, nodes, edges, and compilation. For “call three tools sequentially,” it’s overkill.

CrewAI has the lowest setup overhead of the four orchestration frameworks. You declare roles like researcher, writer, and reviewer, pick a coordination pattern, and run the crew with no state schema to define first. The ceiling: CrewAI optimizes for prototype velocity at the cost of production durability. The framework can’t resume crashed runs from where they failed, error handling lives at the crew level rather than per-node, and no inspectable state schema records what the agents decided and when. Teams move from CrewAI to LangGraph when production state management starts mattering more than the role metaphor.

Pydantic AI treats every agent output as a typed Pydantic model, so validation, retries, and downstream serialization come for free. FastAPI-style decorators for tools and dependencies. The ceiling: Pydantic has weaker multi-agent primitives than CrewAI or LangGraph. It’s the best fit when the agent is a single loop that has to return validated data to a downstream service.

Mastra is the TypeScript answer: agents, workflows, RAG, and evals in one package, built by the ex-Gatsby founders, designed to drop into existing Next.js apps without a Python sidecar. The ceiling: smaller ecosystem and fewer production case studies than LangGraph. Choose Mastra when the team is already on TypeScript end to end and rewriting in Python isn’t on the table.1

The vendor SDKs (Claude Agent SDK, OpenAI Agents SDK, Google ADK) belong here too. Each one removes orchestration friction and locks the agent to one provider’s API. Pick one if you’re already committed to that provider and not planning to swap models.

Layer 2: Memory and state

The context window isn’t memory. Even at 200K tokens, every turn pays for the entire conversation again, and nothing survives the session. Production agents in 2026 keep memory in a dedicated layer that lives outside the prompt.2

Mem0 memory can be scoped to a user (persists across all their sessions), a session (just this conversation), or an agent (shared across all users of one agent). Hybrid storage combines vectors and a graph, with mature SDKs that plug into LangGraph, CrewAI, and Mastra. The project has 48,000+ GitHub stars. Mem0’s ECAI 2025 paper benchmarked Mem0 against 10 alternatives on LoCoMo and reported 92% lower latency and 93% fewer tokens versus naive full-context (the baseline every team replaces by week two), which translates to roughly 14x cheaper inference at the same recall.3 The ceiling: Mem0 treats memory as retrieval, returning the most similar facts to a query. Temporal reasoning, like “what did the user say last week that contradicts what they said today,” needs a graph that tracks edges between facts with timestamps.4

Zep/Graphiti is the temporal graph option. The knowledge graph layer handles entity resolution: figuring out that “Alice,” “[email protected],” and “the CEO” all refer to the same person. It also tracks how relationships change over time, so the agent can answer, “What did this customer’s status look like in Q2?” or “When did the contract owner switch?” The trade-off is that graph construction is expensive. Zep’s memory footprint per conversation runs past 600,000 tokens versus Mem0’s 1,764, and immediate postingestion retrieval often fails because correct answers only appear after background graph processing completes. Choose Zep when the agent needs to reason about history and you can wait seconds, not milliseconds, between turns.

Letta (formerly MemGPT) treats memory like an operating system. Main context is RAM, archival memory is disk, and the agent decides what to promote into RAM, archive to disk, or forget. It’s fully open source, model agnostic, and self-hosted from day one. The architecture extends an agent’s effective context far beyond the LLM’s native window by paging memory in and out, the same trick operating systems use to give programs more virtual memory than physical RAM. The ceiling: You run the storage layer yourself. Letta is harder to deploy than calling a hosted Mem0 endpoint and harder to debug because memory decisions happen inside the agent at runtime.5

Engineering lesson. “Memory” means two different things in an agent system, and using one tool for both breaks both. Runtime state is the agent’s scratchpad mid-task: which node it’s at, what tools it called, what intermediate results it has. LangGraph’s PostgresSaver writes this after every step, so a crashed run resumes from the last node. Knowledge memory is what the agent learned across sessions: preferences, prior questions, and facts about the user. Mem0 and Zep store this. Conflate them and you get an agent that resumes a crashed run correctly but forgets the user the moment they open a new session, or one that remembers the user but can’t recover when it crashes mid-task.

Layer 3: Protocols and tools

Two years ago this layer was function calling: Each provider had its own JSON schema, and each framework wrapped them differently; switching models meant rewriting your tools.

In 2026 this layer is MCP. The Model Context Protocol is the open standard the Claude Agent SDK uses, that OpenAI Agents SDK supports natively, that Google ADK integrates with, that every serious framework now ships a client for. If you’re writing tools today, you’re writing MCP servers. If MCP itself is fuzzy, “What Is MCP?” is the prerequisite.

There’s no framework to pick at this layer. The orchestration choice from layer 1 already decided how MCP integrates.

FastMCP is the Python framework for writing MCP servers fast. Decorator-based and async-first, it’s the closest thing to FastAPI for MCP. mcp-agent is an orchestration framework built around MCP as the primary tool interface. Server lifecycle, multiserver routing, and prompt context handling are built in. With LangGraph or CrewAI, you write that integration code yourself. It’s worth looking at when your agent connects to several MCP servers and the integration code starts becoming the bottleneck.

Layer 4: Browsers and computer use

When the system the agent has to act on doesn’t expose an API, the toolkit has to act through screens. The 2026 field split into two architectural approaches: DOM-driven (parse the page, find elements, and click them) and vision-driven (screenshot the page, feed it to a vision model, and click pixels).

Browser Use is the Python default. With 50,000+ GitHub stars, it’s one of the fastest-growing open source AI projects of 2025–2026. The LLM gets full control of the browser through an agent loop and integrates with LangChain, CrewAI, and custom frameworks. The ceiling: Every step costs an LLM call, which is fine for novel tasks and brutal for repeated workflows. Production teams cache the repeated 80% in Playwright (the deterministic browser automation library) and leave Browser Use for the 20% that needs reasoning.

Stagehand is the TypeScript answer. It’s an open source, MIT-licensed SDK from Browserbase, built as a layer on top of Playwright. Four primitives let the developer keep AI inference for the steps that need reasoning and use scripted Playwright code for the rest. Stagehand v3 (February 2026) rewrote the engine on top of Chrome DevTools Protocol and ships 44% faster.6 The ceiling: Production deployment runs through Browserbase’s managed cloud. The open source SDK is the on-ramp.7

Skyvern is the vision-first option. Each task runs through a three-phase pipeline: Planner breaks the goal into steps, actor sends a screenshot to a vision model and clicks the coordinates it returns, and validator confirms the page changed. Skyvern scores 85.85% on WebVoyager 2.0, the strongest published score on form-filling tasks in domains where the DOM is unreliable: canvas elements, React virtual DOMs nested in iframes, or antibot machinery. That score still translates to roughly one in seven multistep tasks failing. The ceiling: Vision-driven stacks lag DOM-driven ones by 12–17 points on common tasks and cost 4–8 times more per step.8

The production pattern in 2026 wires both in: DOM-driven as the primary path, Skyvern or Anthropic Computer Use or OpenAI CUA as the escape hatch when selectors keep failing on canvas elements or antibot screens. Edge surfaces are one of the four agent failure modes, and we cover all four in “Why AI Agents Keep Failing in Production.”

Layer 5: Coding agents and sandboxes

Coding agents are a category of their own now. They write code, run it, debug it when it breaks, and read docs to figure out what they got wrong. This layer ships with three things the other six don’t: a sandb

[truncated for AI cost control]