Seven frameworks and the row that's missing.

2026-05-29 · by Dennis Gubsky · ~8 min read

A friend sent me an 11,500-word survey of the 2026 agent-framework landscape — seven contenders, sober decision matrix, the usual head-to-head tables on multi-agent handoff, state management, observability, security posture. The piece ranks DSPy, Claude Agent SDK, OpenAI Agents SDK, CrewAI, the new Microsoft Agent Framework (the merger of AutoGen + Semantic Kernel), LangGraph, and Google ADK. It's careful. It cites real benchmarks and real CVEs. It's also one of several similar surveys we read this month — Alice Labs, Firecrawl, MorphLLM, Turing — and they all share a structural assumption that none of them ever quite names.

The decision matrix the survey hands operators is concrete:

Useful. Each of those seven is a real, well-engineered piece of software, and the matrix gets the comparative strengths roughly right. The trouble is what the matrix cannot say, because every row shares a hidden premise.

The premise the survey never names

Look at where each of those seven runtimes actually lives at execution time.

• CrewAI, LangGraph, DSPy — Python libraries that you import into your application. The runtime runs inside your app's process, in your app's language.
• Claude Agent SDK — TypeScript/Python library bundled with the Claude Code binary as an optional dependency; the loop runs in your process, on your machine.
• OpenAI Agents SDK — Python/TS library, in-process; OR move to OpenAI's hosted Agent Builder + ChatKit, where the runtime runs in OpenAI's cloud.
• Microsoft Agent Framework — .NET / Python library in your process; OR Azure Foundry Agent Service, where the runtime runs in Microsoft's cloud.
• Google ADK — Python / TS / Go / Java library in your process; OR Vertex AI Agent Engine Runtime, where the runtime runs in Google's cloud.

Two shapes, one binary choice. Either the agent runtime lives inside your application's process (and your app picks up the framework's language, dependency tree, restart semantics, observability story, and security posture), or the agent runtime lives inside the vendor's cloud (and your app sends prompts over the wire while the vendor owns the loop, the durability, the OTEL exhaust, and the bill). Pick one.

The survey ranks the seven frameworks within that binary. It doesn't ask whether the binary itself is the right primitive.

The eighth shape

Loomcycle is what you get if you reject the binary. The agent runtime is a single Go binary, under 40 megabytes on disk, running in its own process on the same machine (or pod, or cluster) as your application. Your app stays in whatever language it was written in. The runtime is a sidecar: out of your process, on your infrastructure, accessible over HTTP, gRPC, MCP, or via the TypeScript adapter.

The sidecar choice is so structural that it inverts most of the survey's framework-vs-framework gaps into where-the-runtime-lives consequences. Walk through them:

What moves when the runtime moves out of the app

Observability becomes a deployment concern, not a per-framework SDK choice. The survey notes that Claude Agent SDK ships no built-in observability, CrewAI gates it behind a paid enterprise console, and DSPy has none "by design." That's not a feature gap; it's a consequence of being a library — the library can't make decisions about your traces stack, because it doesn't own a process. Loomcycle owns its process, so it ships three drop-in OTEL profiles out of the box (a self-hosted Grafana / Tempo / Prometheus / Loki stack, Honeycomb wiring, Datadog APM wiring) plus a bearer-authed /metrics Prometheus endpoint. Pick your backend; no vendor SDK in the loop.

Durable execution survives application restarts because it's not in the application. The survey gives LangGraph the durability crown — and they're right; LangGraph's checkpointing is real and well-engineered. But the design constraint is that LangGraph's checkpoint stores live alongside your app's state, share its restart semantics, and reload through the same Python interpreter. When the agent runtime is a separate process, "durable across application restarts" becomes the default rather than a feature. Pause / Resume / Snapshot is shipped in loomcycle as a runtime-wide quiesce + cross-version-portable JSON snapshot; multi-replica HA is shipped end-to-end with cross-replica cancel, cluster-wide pause/resume, and advisory-locked singleton sweepers.

Per-tenant fairness is a runtime invariant, not a framework feature. Every one of the seven frameworks shares a process with the application it's serving — which means "per-tenant fairness on the run-admitting semaphore" is a thing the application has to enforce above the framework. The survey doesn't list it as a framework axis because no framework can really claim it. Loomcycle's run-admitting semaphore is per-tenant by construction, cluster-wide; one tenant's burst can't starve another's quiet baseline.

The substrate becomes versionable. Agent definitions, skills, MCP server bindings, schedules — in the seven, all of those live as code or YAML in your repository, and the agent gets whatever the repository has at startup. In loomcycle they live as content-addressed substrate primitives with append-only version history: AgentDef (v0.8.5), SkillDef (v0.8.22), MCPServerDef (v0.9.2), ScheduleDef (v0.12.7). An agent can fork its own definition, lineage is preserved, and the active pointer is mutable at runtime. The substrate-pattern-of-substrates is what makes "the agent learns to be a different agent" a first-class capability rather than a development workflow.

Scheduled autonomous runs are a first-class substrate, not a cron wrapper. None of the seven frameworks the survey covers ships scheduled-run primitives — because a library doesn't have a place to put a long-lived scheduler. Loomcycle's sweeper fires on a cron, builds a real RunInput, dispatches on_complete hooks via channel / memory / MCP, and forks per-user with credentials that never reach the agent. Shipped in v0.12.7; stress-tested to 50,000 cascading fires.

Per-user credentials cross the trust boundary without touching the agent. The survey treats secrets handling as a security topic — sandboxing, OWASP scoring, eval()-as-RCE incidents — and that's correct as far as it goes, but it stays at the surface. The deeper problem is that an in-process agent has the application's credentials by virtue of being in the same process. Loomcycle's per-run named credentials map (RFC F, shipped alongside the scheduled-runs primitive) substitutes user tokens at the HTTP boundary inside the substrate's MCP client, just before the request leaves the binary. Three different per-user MCP servers — jobs, Slack, Telegram — get the right bearer each, and the agent never sees a single one. The trust boundary is the process boundary.

MCP works both ways. The survey grants Claude Agent SDK the strongest MCP-client story — hundreds of MCP servers attachable as tools, native handshake, the lot. But MCP is a two-sided protocol: a runtime can both consume MCP servers as tool sources and expose itself as an MCP server that external clients (Claude Code, n8n, an external orchestrator) can drive. Loomcycle is on both sides at once, on the same auth surface, in the same process. The dual posture is rare; the survey doesn't include it as an axis because most frameworks can't claim it.

Your application doesn't pick up the runtime's language. If you adopt one of the seven, you adopt Python — or .NET, if you go Microsoft. Your service architecture inherits that choice. Loomcycle's sidecar shape means you talk to it the way you'd talk to any other backend service: HTTP, gRPC, MCP, the TS adapter, or the OpenAI-compatible front door (POST /v1/chat/completions works against the same binary that runs your agents). Your Go services stay Go. Your Rails app stays Rails. The agentic feature lights up next door.

When loomcycle is the wrong answer

Sidecar shape isn't free, and the survey's seven frameworks each beat loomcycle on something real. The honest picture:

• If you want declarative prompt optimization — DSPy's MIPROv2 and GEPA are state-of-the-art for compiling pipelines to better prompts and weights automatically. Loomcycle has no such optimizer. Pair the two: optimize with DSPy, run on loomcycle.
• If you want Claude Code's exact tool surface inside your own program — Claude Agent SDK is Claude Code as a library, with the same file/shell/Bash/Grep/WebFetch tools and the same 18-stage hook contract. Loomcycle has its own tool surface, but if you specifically want the Claude Code feel, the SDK is the path.
• If your team is .NET-first and the runtime needs to live next to your existing Azure governance posture — Microsoft Agent Framework's OWASP Agentic Top 10 toolkit is more aligned to that shape than loomcycle's Go sidecar.
• If you want a hosted runtime where someone else owns the durability + uptime — pick one of OpenAI's Agent Builder, Anthropic's Managed Agents, or Vertex AI Agent Engine. Loomcycle is the self-hosted shape. We are not foreclosing a hosted future, but it isn't today.
• If your fastest-time-to-prototype matters more than your eventual production posture — CrewAI's ~35-line minimal agent is genuinely fast, and our quickstart is more like ~5 minutes for a working two-agent loop, so the gap is real for the very first hour.

The eighth row

If a survey wanted to add one more row to the matrix, the honest version reads something like this:

That's not a feature list; it's a description of what changes when the runtime moves out of the application. We ship it as an open-source Go binary because that's the shape we needed and couldn't find — and because once you accept the sidecar premise, the rest of the gaps the surveys keep finding are easier to close than they look.

Companion reading: Three MCP tokens in one run (RFC F — per-run credentials, the trust boundary at the wire), Scheduled runs at 30,000 fires (RFC E — the new substrate primitive, plus the double-fire ceiling we caught at scale), When the agent is in one container and its definition is in another (the content-addressed substrate the whole framing rests on).