# The agent-framework field reinvents the same five wheels

URL: https://www.thedeepfeed.ai/posts/2026-06-02-oss-agent-runtimes-five-wheels/
Category: Agents
Published: 2026-06-02
Author: the-deep-feed
Tags: ai-agents, agent-frameworks, letta, langgraph, mcp
Kind: deep

> Eleven OSS agent runtimes, one recurring pattern: memory, sandboxing, skills-vs-MCP, tool governance, and transport. Only Letta solved memory, only smolagents solved sandboxing, and the 2026 vendor SDKs are quietly absorbing the rest into hosting platforms.

## TL;DR

- Eleven OSS agent runtimes keep solving the same **five problems**: persistent memory, tool sandboxing, skills-vs-MCP, tool governance, and transport. Most solve one well and punt the rest.
- **Letta** owns memory (tiered core/archival/recall, exact-match block edits, a 9-type `ToolRule` engine). **smolagents** owns sandboxing (a 1,768-line AST interpreter plus six pluggable executors). Almost nobody else treats either as a first-class problem.
- **MCP is now table-stakes** — all eleven support it. **A2A** reached a production v1 with 150+ orgs. The protocols converged even as the runtimes fragmented.
- The 2026 vendor SDKs — OpenAI, Anthropic, Google, AWS, Microsoft — are absorbing the hard wheels (sandboxing, transport, hosting) into platforms. **OpenAI and Anthropic still ship 0.x** while declaring 'production-ready.'
- Three layers, three trajectories: **protocols standardize, runtimes proliferate, hosting consolidates.**

**Letta** has 23,101 GitHub stars. CrewAI has 52,666. The frozen `microsoft/autogen` repo still carries 58,639 — the largest number in the field, attached to a project Microsoft has told its own users to stop building on. There are at least eleven open-source agent runtimes worth taking seriously in mid-2026, and counting their stars tells you almost nothing about which one to use, because the stars measure attention and the decision is about architecture.

Read the source of any five of them back to back and a pattern surfaces that no marketing page mentions. Every framework is solving the same five problems: where the agent's memory lives, where its tools execute, how it learns procedures versus how it calls capabilities, who approves a dangerous action, and how a message gets from a human to the loop and back. Call them the five wheels. Almost every runtime reinvents all five, ships one of them well, and leaves the other four as an exercise for the reader.

This is the map. Who solved which wheel, where the 2026 vendor SDKs from OpenAI, Anthropic, Google, AWS, and Microsoft fit, and the one structural story underneath all of it: the protocols converged while the runtimes fragmented, and the platforms are now eating the parts that are hardest to build.

# The field, counted

The numbers below are a live GitHub capture from June 2, 2026. Treat the star counts as ±1% volatile and the version tags as a snapshot — several of these projects ship a release a week.

| Framework | Repo | Stars | Latest | Governing org |
|---|---|---:|---|---|
| 🟢 AutoGen (legacy) | `microsoft/autogen` | 58,639 | frozen | Microsoft |
| 🟢 CrewAI | `crewAIInc/crewAI` | 52,666 | 1.14.6 | CrewAI Inc. |
| 🟢 Agno | `agno-agi/agno` | 40,466 | 2.6.10 | Agno AGI |
| 🟢 LangGraph | `langchain-ai/langgraph` | 33,651 | 1.2.3 | LangChain Inc. |
| 🟡 smolagents | `huggingface/smolagents` | 27,666 | 1.26.0 | Hugging Face |
| 🟡 OpenAI Agents SDK | `openai/openai-agents-python` | 26,852 | 0.17.4 | OpenAI |
| 🟡 Letta | `letta-ai/letta` | 23,101 | 0.16.8 | Letta |
| 🟡 Google ADK | `google/adk-python` | 19,960 | 2.1.0 | Google |
| 🟡 Pydantic AI | `pydantic/pydantic-ai` | 17,467 | 1.105.0 | Pydantic |
| 🔴 Microsoft Agent Framework | `microsoft/agent-framework` | 10,966 | 1.0 (.NET) | Microsoft |
| 🔴 Claude Agent SDK | `anthropics/claude-agent-sdk-python` | 7,158 | 0.2.87 | Anthropic |
| 🔴 AWS Strands | `strands-agents/sdk-python` | 5,998 | 1.42.0 | Amazon |

Two things in that table are worth pausing on. The largest star count belongs to a dead repo: Microsoft folded [AutoGen and Semantic Kernel into a single product](https://devblogs.microsoft.com/foundry/microsoft-agent-framework-1-0-ga/), the Microsoft Agent Framework, whose .NET track hit a 1.0 GA on April 2, 2026 while its 58,000-star predecessor sits frozen at an April 15 push. And the vendor SDKs, the five entries governed by OpenAI, Anthropic, Google, AWS, and Microsoft, are almost exactly one year old as a cohort. The `microsoft/agent-framework` repo was created April 28, 2025; `claude-agent-sdk-python` on June 11, 2025; `strands-agents/sdk-python` on May 14, 2025; `google/adk-python` on April 1, 2025. A year ago this half of the table did not exist.

# Wheel one: memory, and the Letta benchmark

The cleanest way to understand agent memory is to read the thirty lines that define it. In Letta, the entire core-memory editing surface is two functions in `letta/functions/function_sets/base.py`:

```python
def core_memory_append(agent_state, label, content):
    current = str(agent_state.memory.get_block(label).value)
    agent_state.memory.update_block_value(label=label, value=current + "\n" + content)

def core_memory_replace(agent_state, label, old_content, new_content):
    if old_content not in current_value:
        raise ValueError(...)   # forces an exact-match before editing
    agent_state.memory.update_block_value(label=label, value=current.replace(old, new))
```

The `replace` requires an exact-match `old_content` and raises otherwise. That one guard is the difference between an agent that surgically edits a memory block and one that regenerates the whole block from scratch and silently loses ninety percent of the detail. The model is forced to grep its own memory before it writes. It is a small piece of code carrying a large architectural opinion.

Around it sits the design that Letta inherited from the MemGPT paper and has refined since: conversation history lives in the database, not in the context window. The model sees only the always-resident `<memory_blocks>` it can edit with tools, a recent message buffer, and an optional summary of evicted turns. Everything else is retrieved on demand through `conversation_search` for recall and `archival_memory_search` for the vector store. Blocks are markdown files with YAML frontmatter, stored in a per-agent git repository. This is the field's reference memory architecture, and the reason is not that the idea is exotic — it is that almost nobody else implements it.

Watch what the rest of the field calls "memory." [LangGraph](https://github.com/langchain-ai/langgraph) persists graph state as checkpoints organized into threads, which gives you crash recovery, conversational continuity, and time-travel debugging. Pydantic AI [officially supports four durable-execution backends](https://ai.pydantic.dev/durable_execution/overview/) for the same reasons: Temporal, DBOS, Prefect, and a native option. Both are real and useful. Neither is memory. They persist execution state, which lets an agent survive a process restart; they do not curate a working set that keeps the context window from bloating. The field is quietly conflating durability with memory, and the distinction matters precisely when an agent runs for days instead of seconds.

Two frameworks ship genuine memory subsystems beyond Letta: Agno carries memory services and blocks, and CrewAI has a `unified_memory.py` that uses an LLM to analyze and consolidate rather than splitting tiers by hand. smolagents has none by design. The vendor SDKs mostly offer session storage or "memory services" rather than a Letta-style curated architecture, though their docs claim more than their source has been verified to deliver. The verdict for the field: memory is the least-reinvented wheel, because most frameworks decline to build it at all and reach for durable state instead.

![Hand-drawn diagram contrasting a curated tiered-memory tower with editable blocks against a flat append-only execution log, a red marker on the exact-match edit guard](/post-images/2026-06-02-oss-agent-runtimes-five-wheels/memory-tiers.jpg)

# Wheel two: sandboxing, and the only AST interpreter in the field

When an LLM emits code or a tool call, something runs it. The question every framework answers, usually badly, is *where*. smolagents answers it with the most serious piece of isolation engineering in the open-source field: `src/smolagents/local_python_executor.py`, roughly 1,768 lines of Python AST interpreter that walks the agent's code node by node and rejects everything not on a whitelist. The `DANGEROUS_MODULES` list blocks `os`, `subprocess`, `sys`, `socket`, `shutil`, `pathlib`, and a dozen others; `DANGEROUS_FUNCTIONS` blocks `eval`, `exec`, `compile`, `__import__`, `os.system`, and `os.popen`. A `check_safer_result` pass runs after every evaluation step.

The premise behind it is that code-as-action beats the JSON tool-call dance. Instead of three to five round-trips to chain tools through JSON, the model emits one Python block with nested calls and comprehensions, which smolagents claims cuts LLM calls by around thirty percent on GAIA-style tasks. The catch is the threat model gets worse, not better: a raw-Python exchange call has no schema layer to audit. So smolagents pairs the AST executor with six interchangeable backends switchable by a single kwarg — `CodeAgent(..., executor_type="e2b")` selects between `LocalPythonExecutor`, `E2BExecutor`, `DockerExecutor`, `WasmExecutor`, `ModalExecutor`, and `BlaxelExecutor`. The local AST path is process-level isolation, not a real sandbox; the production answer is to push execution into E2B, Docker, or Modal. Letta does the same, dispatching per-tool to E2B or Modal with a local fallback.

Now the uncomfortable column. CrewAI, LangGraph, Pydantic AI, and Agno all run tools **in-process by default** unless you wire a sandbox yourself. That is the largest unaddressed risk across the OSS-pure frameworks: an agent that can install a skill, set an environment variable, and execute a tool is one prompt away from remote code execution on the host process. The vendor SDKs are, surprisingly, ahead here, and the reason is structural. They bundle hosted sandboxes because they own the hosting. OpenAI describes its own offering in exactly those terms:

> Sandbox Agents run in an isolated, Unix-like execution environment with a filesystem, shell, and installed packages. You can persist and restore state with snapshots.
>
> — OpenAI, [Agents — sandboxes](https://openai.github.io/openai-agents-python/), 2026

Google ADK 2.1 added sandboxes created from templates and snapshots. AWS Strands deploys into Bedrock AgentCore. The Claude Agent SDK inherits the Claude Code harness with permission modes over bash and file access. Sandboxing is becoming a platform feature, not a library feature, the first clean data point for the convergence story.

# Wheel three: skills versus MCP, the wheel that standardized

This is the wheel the field actually agreed on, and it agreed twice. First, on capability access: the Model Context Protocol, [introduced by Anthropic](https://modelcontextprotocol.io/introduction), is now supported natively by every framework in the roster. Letta, smolagents, Agno (in both directions — consuming servers and exposing the agent as one), CrewAI, Microsoft Agent Framework, LangGraph, Pydantic AI, the OpenAI Agents SDK, the Claude Agent SDK, Google ADK, AWS Strands. There is no holdout. In 2026, MCP is not a differentiator; it is the cost of entry.

The second agreement is quieter and more interesting. Anthropic's [Agent Skills format](https://www.anthropic.com/news/skills) is a `SKILL.md` file with progressive disclosure, where the model sees the frontmatter at startup, the full body when the skill matches, and `references/` files only as needed. It has been independently reimplemented by at least three other frameworks. Agno ships a `SKILL.md` loader with the three canonical tools. CrewAI added one at `lib/crewai/src/crewai/skills/`. Letta's coding agent adopted the same format. Four implementations of one spec is how you know a standard stuck.

The settled distinction is worth stating plainly, because the field spent a year confusing the two. Skills teach an agent *how* to do something; MCP gives an agent the *ability* to do something. A trading data feed, an exchange API, an on-chain action: those are MCP servers. The risk policy for evaluating a signal, the playbook for handling a refund: those are skills. They draw on different budgets, where a skill spends words in the context window and an MCP server spends tool-schema tokens. Production agents use both, which is why the "skills versus MCP" framing was always a false binary. This wheel did not get reinvented eleven times. It got standardized into two complementary formats, and that is the exception that proves how rare standardization is everywhere else.

# Wheel four: governance, where only Letta built a policy language

Every framework has some notion of stopping an agent before it does something irreversible. Almost all of them implement it as a hook or a callback. Exactly one implements it as a declarative policy engine. Letta's `letta/schemas/tool_rule.py` is a discriminated union of nine rule types: `RequiresApprovalToolRule`, `MaxCountPerStepToolRule`, `TerminalToolRule`, `ChildToolRule`, `ConditionalToolRule`, `RequiredBeforeExitToolRule`, plus the init, continue, and parent variants. You declare the constraints and the runtime enforces them. That is governance as a language, not governance as a place to write an `if` statement.

The rest of the field clusters into two tiers. The first-class-but-imperative group ships real human-in-the-loop machinery: LangGraph has interrupt-and-resume plus time-travel, the OpenAI Agents SDK has guardrails and approvals, the Microsoft Agent Framework has workflow approvals, Google ADK has callbacks, the Claude Agent SDK has permission modes and hooks. Agno's `@approval` decorator plus its prompt-injection and PII guardrails is the simplest production-grade version. The weaker group treats governance as a pattern you assemble: smolagents relies on reviewing the generated code, CrewAI has hooks but no rule system, Pydantic AI routes approval through its durable-execution layer, and Strands offers HITL patterns rather than an engine.

The verdict: governance is moderately reinvented. Nearly everyone has *some* approval gate, which is why it grades better than memory across the field. But only Letta treats "what is this agent allowed to do" as a thing you specify rather than a thing you code. As agents get more autonomy, the ability to set keys, install skills, and commit to git, the gap between a rule engine and a scattering of callbacks stops being academic.

![Two-panel hand-drawn contrast: on the left a single labeled rule-engine gate with nine policy slots, on the right scattered if-statement hooks bolted onto a pipeline, the engine outlined in red](/post-images/2026-06-02-oss-agent-runtimes-five-wheels/governance-gate.jpg)

# Wheel five: transport, the most fragmented wheel of all

Transport is the layer that connects a human to the loop: the Telegram bot, the Slack app, the web chat, the agent-to-agent handoff. It is the wheel everyone reinvents and nobody enjoys, and the open-source field handles it worst. smolagents, LangGraph, CrewAI's core, and Pydantic AI leave it entirely to you. Letta exposes an API and a development environment but no chat-app connectors. The single standout is Agno, whose `os/interfaces/` directory ships Telegram, Slack, WhatsApp, AGUI, and A2A in one package, the Telegram interface alone running roughly 1,594 lines, which is why Agno reads less like a library and more like an operating system for agents.

The vendor SDKs solve transport the way they solve sandboxing: by owning the surface. OpenAI routes it through ChatKit and Agent Builder, Google through Agent Engine, Microsoft through Foundry, AWS and Anthropic through their own consoles. You do not hand-roll a Telegram bridge on those platforms because the platform is the bridge. The pattern is the same one sandboxing showed: the OSS frameworks fragment, each gluing its own connectors, while the vendors consolidate transport into hosting.

And then there is the cross-vendor exception. A2A, the Agent2Agent protocol that Google built in April 2025 and donated to the Linux Foundation that June, reached a production v1.0 and, per the [Linux Foundation's April 9, 2026 announcement](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms), now spans more than 150 organizations with enterprise production use in its first year. Native A2A support landed in the Microsoft Agent Framework, Google ADK, AWS Strands, Agno, and Pydantic AI. Transport for *humans* stays fragmented; transport between *agents* standardized into a protocol that all four major vendors adopted. That split is the whole story in one wheel.

# The matrix

Lay the eleven frameworks against the five wheels and the shape of the field resolves. The cells anchored to verified file paths, those for Letta, smolagents, Agno, and CrewAI, are firmer than the vendor-SDK cells, which are graded from documentation rather than source and should be read as "claimed" rather than "confirmed."

| Framework | Memory | Sandboxing | MCP | Governance | Transport |
|---|---|---|---|---|---|
| 🟢 Letta | ✅ benchmark | ✅ E2B/Modal | ✅ | ✅ 9-type ToolRule | 🟡 API only |
| 🟡 smolagents | ❌ in-context | ✅ AST + 6 backends | ✅ | 🟡 code review | ❌ |
| 🟢 Agno | ✅ services + blocks | 🟡 opt-in | ✅ both ways | ✅ @approval | ✅ TG/Slack/WA |
| 🟡 CrewAI | 🟡 unified_memory | ❌ in-process | ✅ | 🟡 hooks | 🟡 add-ons |
| 🟡 Microsoft AF | 🟡 thread/Foundry | 🟡 Foundry | ✅ | ✅ workflow | 🟡 A2A + Foundry |
| 🟢 LangGraph | 🟡 checkpoints | ❌ in-process | ✅ | ✅ interrupt/HITL | ❌ |
| 🟡 Pydantic AI | ❌ durable state | ❌ DIY | ✅ | 🟡 durable approval | 🟡 A2A extra |
| 🟡 OpenAI SDK | 🟡 sessions | ✅ Sandbox Agents | ✅ | ✅ guardrails | 🟡 ChatKit |
| 🔴 Claude SDK | 🟡 session/Skills | ✅ Code harness | ✅ | ✅ permission modes | 🟡 terminal/IDE |
| 🟡 Google ADK | 🟡 session services | ✅ template/snapshot | ✅ | ✅ callbacks | 🟡 A2A + Engine |
| 🔴 AWS Strands | 🟡 session state | ✅ AgentCore | ✅ | 🟡 HITL patterns | 🟡 A2A + AgentCore |

Read down the MCP column and it is solid green, the one wheel everyone got. Read down memory and governance and the green nearly vanishes outside Letta and Agno. Read sandboxing and transport and notice the vendor SDKs carry checks the OSS-pure frameworks do not, because those wheels are cheaper to provide when you also own the datacenter.

![Hand-drawn grid of eleven agent frameworks scored across five columns, the MCP column filled solid while memory and governance columns sit mostly empty, one red column highlighting the standardized wheel](/post-images/2026-06-02-oss-agent-runtimes-five-wheels/wheel-matrix.jpg)

# The vendor cohort is one year old and consolidating fast

The five vendor SDKs deserve a column of their own, because they are the variable the older frameworks did not have to price in a year ago. They are consolidating on a visible cadence. Microsoft folded AutoGen and Semantic Kernel into the Microsoft Agent Framework, whose .NET track reached a 1.0 GA in April 2026 while its Python track runs independently past 1.7. [Google ADK hit a 2.0 GA](https://github.com/google/adk-python) on May 19, 2026 with a graph-based workflow runtime. AWS Strands reached 1.0 on May 21. LangGraph, not a vendor but the OSS heavyweight, [shipped 1.0 in October 2025](https://changelog.langchain.com/announcements/langgraph-1-0-is-now-generally-available), billed as the first stable major release in the durable-agent space and cited in production at Uber and LinkedIn.

Against that, two of the largest labs ship pointedly unstable SDKs. The OpenAI Agents SDK sits at 0.17.4 and the Claude Agent SDK at 0.2.87, both still 0.x, both marketed as production-ready, both declining to commit to a stable API surface. Anthropic at least did the honest renaming: the Claude Code SDK [became the Claude Agent SDK](https://docs.claude.com/en/api/agent-sdk/migration-guide) in a September 2025 commit titled, with no ceremony, "Rename claude_code to claude_agent." The company was explicit about why:

> The Claude Code SDK has been renamed to the Claude Agent SDK. This change reflects the SDK's broader capabilities for building AI agents beyond just coding tasks.
>
> — Anthropic, [Claude Agent SDK migration guide](https://docs.claude.com/en/api/agent-sdk/migration-guide), Sep 2025

The reason is that the same harness running Claude Code, file ops and bash and subagents and skills and checkpoints, is now exposed as a library. The honesty about the rename and the reticence about the version number come from the same place: these are the harnesses the labs run internally, shipped outward before they are frozen.

There is a billing wrinkle worth flagging for anyone planning a production deployment on Anthropic's SDK: starting June 15, 2026, Agent SDK and `claude -p` usage on subscription plans draws from a separate metered Agent SDK credit pool. The cost model for building on a lab's harness is itself still moving.

![Hand-drawn timeline of 2026 agent-SDK GA milestones — LangGraph, Microsoft .NET, Google ADK, AWS Strands marked stable, OpenAI and Anthropic marked 0.x in red](/post-images/2026-06-02-oss-agent-runtimes-five-wheels/vendor-cohort-timeline.jpg)

# Three layers, three trajectories

The five-wheels frame holds, but unevenly, and the unevenness is the finding. Memory and governance are *under*-built: the field reaches for durable state and scattered callbacks rather than treating curated memory and declarative policy as architecture, and only Letta does both. Sandboxing and transport are *over*-reinvented by the OSS-pure frameworks, where everyone hand-rolls a Telegram bridge and runs tools in-process, while the vendor SDKs quietly absorb both into their platforms. Skills-and-MCP is the one wheel that standardized instead of fragmenting, into two complementary formats the whole field adopted.

Stack those observations and a cleaner three-layer picture appears than "there are too many agent frameworks." The protocols converged: MCP is universal, A2A reached a production v1 with 150-plus organizations and all four major vendor SDKs on board, and `SKILL.md` has four independent implementations. The runtimes fragmented: eleven of them and counting, each making a defensible bet on one wheel and punting the rest. And the hosting consolidated: OpenAI Sandbox Agents, Bedrock AgentCore, Foundry, Agent Engine — the vendors are turning the expensive wheels into platform features that a library cannot match.

If you are choosing a runtime today, that map is the decision tool. Need real memory for an agent that runs for weeks: Letta, and accept the Postgres-and-Redis weight. Need code-as-action with serious isolation: smolagents into E2B. Need the batteries and the chat connectors in one box: Agno. Need durable graph orchestration with production references: LangGraph. Building inside a cloud you already pay for: the matching vendor SDK, and price in the 0.x risk if it says OpenAI or Anthropic on the tin. Pick the wheel you cannot afford to get wrong, choose the framework that treats that wheel as architecture rather than an afterthought, and assume you will bolt on the other four. That assumption is the truest thing the field will tell you, and none of the marketing pages say it out loud.

## Sources

- [Letta — letta-ai/letta (GitHub)](https://github.com/letta-ai/letta)
- [Smolagents — huggingface/smolagents (GitHub)](https://github.com/huggingface/smolagents)
- [Agno — agno-agi/agno (GitHub)](https://github.com/agno-agi/agno)
- [CrewAI — crewAIInc/crewAI (GitHub)](https://github.com/crewAIInc/crewAI)
- [LangGraph — langchain-ai/langgraph (GitHub)](https://github.com/langchain-ai/langgraph)
- [LangGraph 1.0 is now generally available](https://changelog.langchain.com/announcements/langgraph-1-0-is-now-generally-available)
- [Pydantic AI — pydantic/pydantic-ai (GitHub)](https://github.com/pydantic/pydantic-ai)
- [Pydantic AI — durable execution overview](https://ai.pydantic.dev/durable_execution/overview/)
- [OpenAI Agents SDK — documentation](https://openai.github.io/openai-agents-python/)
- [OpenAI Agents SDK — MCP support](https://openai.github.io/openai-agents-python/mcp/)
- [Anthropic — Building agents with the Claude Agent SDK](https://www.anthropic.com/engineering/building-agents-with-the-claude-agent-sdk)
- [Claude Agent SDK — migration guide (renamed from Claude Code SDK)](https://docs.claude.com/en/api/agent-sdk/migration-guide)
- [Microsoft Agent Framework — version 1.0](https://devblogs.microsoft.com/foundry/microsoft-agent-framework-1-0-ga/)
- [Google ADK — google/adk-python (GitHub)](https://github.com/google/adk-python)
- [AWS — Introducing Strands Agents, an open source AI agents SDK](https://aws.amazon.com/blogs/opensource/introducing-strands-agents-an-open-source-ai-agents-sdk/)
- [Linux Foundation — A2A Protocol surpasses 150 organizations](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms)
- [Anthropic — Agent Skills](https://www.anthropic.com/news/skills)
- [Model Context Protocol — introduction](https://modelcontextprotocol.io/introduction)

---

Canonical: https://www.thedeepfeed.ai/posts/2026-06-02-oss-agent-runtimes-five-wheels/
Site: https://www.thedeepfeed.ai
Full corpus: https://www.thedeepfeed.ai/llms-full.txt