Comparison matrix
Where xFlow sits in the agent and workflow framework landscape. One row per system, the same axes throughout, deep pages for the closest peers (Mastra, LangGraph), shortlist for choosing between them. Frameworks with a fundamentally different scope (SDK-only, DSPy-style compilers, code-emitting agents) are listed too — they're not direct competitors but they're choices teams realistically make.
Per-system narrative
Twelve systems, one paragraph each.
Each card states the framework's shape, what it's best at, and the one structural delta vs xFlow that matters most. Deep pages exist for Mastra and LangGraph; the others get the matrix-row treatment because the structural delta is the same shape in each case.
Mastra
TypeScriptBatteries-included TS agent + workflow framework: Agent class, workflow combinators (.then / .parallel / .branch / .dountil / .foreach), memory, evals, voice, telemetry, deployable runtime.
Best fit
TS-first product teams that want an opinionated, integrated stack for agents + workflows with strong observability and DX.
Structural delta vs xFlow
Workflows are TS code (composed via combinators), not data. Steps and tools are opaque host-language functions. No registry / id@version, no multi-substrate runtime, no multi-writer claims, no browser placement, no signed log, no whole-flow optimizer. Federation with xFlow is the realistic shape.
LangGraph
BothPregel-like superstep graph runtime over typed state with channels, conditional edges, and a Checkpointer interface. ToolNode for action calls. The dominant agent-graph framework in the LangChain ecosystem.
Best fit
Single-process agent loops, LangChain-native tooling, server-only execution, linear-ish flows.
Structural delta vs xFlow
Graph is built imperatively in code; nodes are arbitrary host-language functions. No registry, no multi-substrate, no signing, no IR for whole-flow optimization. See deep page.
CrewAI
PythonMulti-agent role-playing framework: Agents (role / goal / backstory) collaborate on Tasks within a Crew. Two top-level shapes: Crew (sequential / hierarchical processes) and Flows (more deterministic step orchestration).
Best fit
Multi-agent collaboration scenarios where the agent ROLES are the modeling unit and you want a quick path to a working demo.
Structural delta vs xFlow
Agents and tasks are Python objects; flows are Python code. No graph-as-data, no registry, no multi-substrate, no signing. Optimization story is pre-prompt tuning and tool selection, no whole-flow optimizer.
AutoGen (Microsoft)
PythonMulti-agent conversation framework. v0.4 redesigned around an actor model: agents are async actors that pass messages; AgentChat sits on top with prebuilt patterns (round-robin, selector, magnetic).
Best fit
Research-grade multi-agent experimentation, code-execution-heavy agents, Microsoft-stack integration.
Structural delta vs xFlow
Agent topology is built in Python code; messages flow at runtime. No graph-as-data, no registry, no multi-substrate. The actor model is closer in spirit to xSync, but events aren't signed and there's no flow IR.
LlamaIndex Workflows
BothEvent-driven step framework. Steps are decorated functions; events flow between steps; the runtime walks the event graph. Built around RAG primitives but works as a general workflow engine.
Best fit
RAG-heavy applications already in the LlamaIndex ecosystem; event-driven workflows where the natural primitive is 'this step emits these event types.'
Structural delta vs xFlow
Workflow is the connectivity of `@step` decorators in Python code. No graph-as-data export, no registry, no multi-substrate. Strong RAG-side ecosystem; weaker on cross-runtime portability.
DSPy
PythonDeclarative module composition (Predict / ChainOfThought / ReAct) with a compiler that optimizes prompts and demonstrations against a metric and dataset. Optimizers include BootstrapFewShot, MIPRO, GEPA.
Best fit
Programs where you can define a metric and a labeled dataset and want a compiler to do prompt and demonstration search instead of hand-tuning.
Structural delta vs xFlow
DSPy is the *most aligned* peer to xFlow's optimization thesis — it's where 'compiler over a typed program' actually lands today. The delta is scope: DSPy operates on a program of LLM modules; xFlow operates on a workflow IR with arbitrary actions. xFlow's `xflow.optimize` is meant to be DSPy-of-flows; the two are complementary, not competitive. See `/docs/optimization`.
Pydantic AI
PythonType-safe Python agent framework. Pydantic models for IO contracts, tool calling, streaming, structured outputs, multi-model. More like a typed wrapper around model SDKs than a full workflow framework.
Best fit
Python teams that want type safety and Pydantic-native ergonomics around LLM calls, with light agent / tool orchestration.
Structural delta vs xFlow
Agent and tool layer only — no workflow primitive at all. No graph, no registry, no multi-substrate. Sits one layer below xFlow / Mastra / LangGraph; would be the action-implementation layer in an xFlow setup.
Vercel AI SDK
TypeScriptTS-first model-agnostic SDK: generateText / streamText / generateObject / streamObject, tool() with zod, multi-step generations with automatic tool calling, provider abstraction across OpenAI / Anthropic / Google / etc.
Best fit
TS apps that want a clean unified surface for LLM calls + tools + streaming, with the Vercel-native deployment story.
Structural delta vs xFlow
Excellent SDK, not a workflow framework. Tool calls are local. Multi-step generation handles agent loops in-line; no graph, no registry, no multi-substrate. Natural action-layer choice inside an xFlow definition. Composes well with Mastra and LangGraph also.
OpenAI Agents SDK
BothMulti-agent orchestration with handoffs, tools, guardrails, sessions, and built-in tracing. Lightweight and intentionally minimal; agents hand off control to other agents.
Best fit
Teams already on OpenAI infra that want a small SDK for multi-agent flows with tracing and handoffs out of the box.
Structural delta vs xFlow
Agent topology is code; handoffs happen at runtime. No graph-as-data, no registry, no multi-substrate, no signing. Forward-direction overlap with xFlow's action layer (handoffs ≈ action invocations) is real but unwired.
Claude Agent SDK (Anthropic)
BothAnthropic's official agent SDK (TS + Python). The same SDK Claude Code is built on. Provides agent loops, tool use, computer use, file-system-based session continuity, and prompt caching primitives.
Best fit
Claude-first agents, particularly long-running agents that benefit from prompt caching and session persistence; the natural choice for tooling that runs alongside Claude Code.
Structural delta vs xFlow
Agent layer (model + tools + session) only — no workflow primitive. Great fit as an xFlow action implementation. xCoder consumes this SDK as its host-agent layer.
smolagents (HuggingFace)
PythonCode-first agent framework: LLM emits Python code which is executed in a sandbox. ReAct-style multi-step agents. Lightweight; ~1k lines of code; HF ecosystem integration.
Best fit
Agents whose tool use benefits from full Python expressiveness rather than discrete tool() calls — data manipulation, scientific code, anything where a tool DSL is awkward.
Structural delta vs xFlow
The agent IS the codegen + sandbox loop. Workflow is implicit in the LLM's emitted code. Direct opposite end of the spectrum from xFlow — xFlow keeps the structure as data; smolagents keeps the structure as model-emitted code. Different bets; both can be valid.
AWS Strands Agents
PythonModel-driven agent framework from AWS: a small set of primitives (Agent, Tool, Session) with tight Bedrock integration. Recent entrant; AWS-native.
Best fit
Teams already on AWS Bedrock that want a model-driven framework with first-party AWS integration and minimal lock-in to a particular orchestration style.
Structural delta vs xFlow
Agent + tool layer; no workflow IR, no registry, no multi-substrate. Closest in spirit to OpenAI Agents SDK and Claude Agent SDK — provider-aligned minimal SDKs. Composes as an xFlow action layer.
Axis matrix
The same ten axes across every system.
✅ structural strength · ⚠️ partial or qualified · ❌ structurally limited. xFlow's two ⚠️ marks (whole-flow optimizer and verifiable execution) reflect that the IR makes those tractable but the implementations are forward direction — see /docs/optimization for what ships today vs what the IR enables.
| System | Graph is data | id@version registry | Statechart richness | Durable persistence | Signed event log | Multi-substrate runtime | Multi-writer / placement | Browser as peer | Whole-flow optimizer | Path to verifiable execution |
|---|---|---|---|---|---|---|---|---|---|---|
| Mastra | ❌ | ❌ | ⚠️ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| LangGraph | ❌ | ❌ | ⚠️ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| CrewAI | ❌ | ❌ | ❌ | ⚠️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| AutoGen (Microsoft) | ❌ | ❌ | ❌ | ⚠️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| LlamaIndex Workflows | ❌ | ❌ | ⚠️ | ⚠️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| DSPy | ⚠️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ⚠️ | ❌ |
| Pydantic AI | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| Vercel AI SDK | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| OpenAI Agents SDK | ❌ | ❌ | ❌ | ⚠️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| Claude Agent SDK (Anthropic) | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| smolagents (HuggingFace) | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| AWS Strands Agents | ❌ | ❌ | ❌ | ⚠️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| xFlow.WTF | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⚠️ | ⚠️ |
Structural uniqueness
What no one else combines.
The matrix above isn't just a feature comparison — it's a survey of where four design choices intersect. As of today, no other shipping system combines all four: full statechart semantics, a content-addressed dynamic registry, a service-action layer with stable id@version contracts, and a substrate-pluggable runtime that runs the same definition in CLI / browser / server / worker.
The four-way intersection
Each system in the matrix above scores high on one or two of these axes; xFlow is the only one that scores yes on all four.
Full statecharts
Parallel regions with formal join, hierarchical macro-states, history (shallow + deep), guards, SCXML interop. Step Functions has state machines but not the full language; XState has the language but not a runtime wrapper.
Dynamic content-addressed registry
Definitions resolve by id@version from a signed bucket layout. npm has the registry shape but no flow semantics; AWS has ARNs but not portable; Camunda has a deployment registry but JVM-bound and BPMN-only.
Service actions by stable id
Action layer is symbolic (action:id@version), placement-aware, claim-aware, and signature-verifiable. LangGraph, Mastra, and others use in-process functions; the addressable + signable property is the gate to optimization and provability.
Universal substrate-pluggable runtime
One definition runs on memory · sqlite · postgres · xSync · S3WORM today, with WASM-component and ZK targets forward direction. Every other system in the matrix is single-runtime — adopt the framework, deploy its server.
Closest two-axis combinations in the field
For honesty: each of these systems gets two of the four axes right. None reach all four.
| System | Statecharts | Registry | Service actions by id | Universal wrapper |
|---|---|---|---|---|
| AWS Step Functions | ✅ ASL | ⚠️ ARNs (AWS-only) | ✅ Lambda/Service tasks | ❌ AWS-only |
| Camunda 8 / Zeebe | ⚠️ BPMN-adjacent | ✅ deployment registry | ✅ service tasks | ❌ JVM-only |
| XState / SCION-CORE | ✅ | ❌ | ⚠️ in-process actors | ❌ |
| OpenServ BRAID | ⚠️ Mermaid GRD per problem | ❌ ephemeral | ✅ executes through GRD | ❌ single tool |
| Vercel WDK + npm | ❌ flat DAG | ⚠️ npm | ⚠️ steps | ❌ server-only |
| Apache Camel / Spring Integration | ❌ routes | ✅ component registry | ✅ | ❌ JVM-only |
| xFlow.WTF | ✅ xState v5 + SCXML | ✅ fs / http / s3worm | ✅ action:id@version (signed) | ✅ memory / sqlite / pg / xSync / S3WORM |
The honest read. Statecharts are old and mature. Dynamic registries are well understood (npm, OCI, content-addressed stores). Service-action layers exist in many shapes. Substrate-pluggable execution is a known pattern. The gap is that no shipping system has put all four in one place. xFlow is that combination.
That gap is also the moat. Each of these axes individually is hard but not impossible to add to a competing system; the four together require designing from the IR up. See /docs/optimization for what the four-way combination unlocks downstream.
Decision shortlist
Pick by what you're optimizing for.
The matrix above shows where each system structurally lands. The shortlist below is the reverse lookup — given a center of gravity, which framework is the natural pick?
Mastra
TS-first product team, server-side execution, want batteries-included evals + memory + voice + telemetry, single-runtime deployment is fine.
LangGraph
Python or TS, single-process agent loop, LangChain-native tooling, deep checkpointer and HITL primitives are load-bearing.
CrewAI / AutoGen
Multi-agent role-play / collaboration is the natural model. Pick CrewAI for ergonomics, AutoGen for the actor-model substrate.
LlamaIndex Workflows
RAG-heavy app already in the LlamaIndex ecosystem; event-driven workflow shape fits.
DSPy
You have a metric and a dataset and want a compiler to optimize prompts and demonstrations. Complementary to xFlow at the action layer.
Vercel AI SDK / OpenAI Agents SDK / Claude Agent SDK / Pydantic AI / AWS Strands
You want a clean SDK at the agent + tool layer rather than a workflow framework. Compose with xFlow / Mastra / LangGraph above for orchestration.
smolagents
Tool use benefits from full Python expressiveness; you're comfortable with code-emitting agents in a sandbox.
xFlow
Multi-product family, cross-substrate, multi-writer, signed audit, optimization-and-provability-curious. Federation with the above is the realistic shape.
Realistic shape
Federation, not winner-takes-all.
Most teams don't pick one. They use an agent SDK at the model + tool layer (Vercel AI SDK / Claude Agent SDK / OpenAI Agents SDK / Pydantic AI), a workflow framework above it (Mastra / LangGraph / xFlow), and an optimization layer where it pays (DSPy at the prompt level; xflow.optimize at the flow level). The matrix above is for understanding the choices; this page is not arguing for one stack.
Where xFlow pulls its weight: definition distribution as data, statechart richness, multi-substrate execution, multi-writer participation, signed audit, and the optimization / provability story over a typed IR.
Where xFlow does not compete: batteries-included agent ergonomics (Mastra wins), Pregel-style superstep checkpoint semantics (LangGraph wins), backend long-running deterministic replay at Temporal scale (Temporal wins), DSPy-style prompt-and-demonstration optimization at the module level (DSPy wins).
The realistic stack for many teams: Mastra or LangGraph at the workflow ergonomics layer, Claude Agent SDK / Vercel AI SDK at the action layer, xFlow at the registry + multi-substrate + signed-log layer, DSPy or xflow.optimize at the optimization layer. None of these is exclusive.