Draw the flow.
Ship the graph.

No — and the distinction is the whole project. Tools like n8n, Dify, Langflow and Flowise own their executor: your flow runs inside their engine or not at all. OpenStateGraph is a compiler with a single target. It turns the canvas into workflow.json, and workflow.json into a LangGraph StateGraph. There is no engine of ours in the loop at runtime.

The practical consequence: checkpointing, time travel, interrupt(), Send fan-out and streaming are LangGraph's, not reimplementations that lag behind it.

No. The compiled graph is an ordinary Python object. Import it from a script, test it with pytest, wrap it in your own FastAPI app, deploy it wherever Python runs. The editor is an authoring tool, not a dependency of the thing you author.

Delete this repository and your workflow package still runs. That is the test we hold ourselves to: the compiler is not portable; the output is.

The three ways to consume it — fork/checkout, artifact, MCP — are written up with exact commands in docs/adoption.md.

Yes, and the honest answer has three parts — because people test this claim, and one slogan would be wrong in at least one of them.

workflow.json needs us. It is our format; nothing else reads it. A package needs us too, because tools/, functions/, middlewares/, skills/ and knowledge/ are wired by our discovery conventions — and that wiring is the difference between a workflow that answers and one that only looks like it does. Compile the document by hand and the agent is drawn with three tools, bound to none, and answers confidently from memory instead of from your database. load_workflow exists because of exactly that failure, and it reports whatever it could not resolve on .warnings.

The compiled graph does not need us. workflow.graph is a plain LangGraph StateGraph — .stream(), .astream_events(), .get_state(), interrupt and resume, your own checkpointer — with nothing of ours in the call stack. So the dependency buys you the format, the compiler and the package conventions; it is not a runtime tax, and there is a full escape hatch with no proprietary object in the way.

Footprint, measured in a clean virtualenv rather than estimated: 36 distributions for the core, 38 with a provider — essentially all of them LangChain's and LangGraph's own closure, which you would install anyway to write the StateGraph by hand. The long version, including what we deliberately do not own and when not to use us at all, is in docs/what-is-this.md.

Yes — that is what the MCP layer is for, and the inversion is deliberate. Your model composes; this server is the ground truth and the artifact factory. A client calls get_node_vocabulary() for the exact node types, port ids and binding rules, composes a document, then calls compile_workflow(). The verdict is deterministic and calls no model of ours: an invalid document returns findings and no artifacts, so the client iterates against compiler evidence rather than its own confidence.

A valid one returns the workflow.json envelope to commit to your repository, the compiled Mermaid topology, a run snippet and the package layout. Clients like Claude render that Mermaid as a diagram locally, so asking for a workflow in a chat window gives you a picture of the compiled StateGraph — with the graph never leaving your machine.

The trust boundary holds: no publish tool, no delete tool, no credentials over the wire, writes validated server-side and always as drafts. A human clicks Publish. Worked example in docs/mcp.md; the honest limits — starting with no authentication layer — in docs/decisions/mcp-layer.md.

Anything LangChain's init_chat_model can resolve — Anthropic, OpenAI, Google, Bedrock, Ollama cloud and the rest. A model is a string on a node, so switching provider is an edit, not a migration.

Keys stay server-side, read from the backend's environment (ANTHROPIC_API_KEY, OPENAI_API_KEY); with none set, the backend defaults to Ollama cloud with no configuration. Keys are never baked into workflow.json, so the document is safe to commit.

You register it; you never edit the engine. Every extension point is a registry — node types, executors, model providers, connection rules, validation rules, canvas features, card bodies — so a new capability lands without touching core/.

A node type is one file (model, field schema, ports, executor) plus its registry entry; a tool is a BaseTool subclass discovered by convention inside a workflow's tools/ directory. You can also skip this repository altogether: publish your own distribution declaring [project.entry-points."openstategraph.tools"] and your tool registers in every workflow the moment someone pip installs it — no fork, no merge to carry. See docs/building-an-atom.md →

Per-workflow knowledge, built from your real sources and stored as markdown in the package's knowledge/ directory. It is chunked deliberately: one index line per topic is cheap enough to carry in every prompt, and the full document is fetched only once an agent commits to that direction.

It is generated, then owned by you — the first keystroke claims a document, and a stale badge tells you when the source behind it moved. In chinook-assistant it is eleven docs, one per table, so the model knows what InvoiceLine means before it writes a join.

MIT, for the whole project. Use it commercially, fork it, embed it in a product, keep your changes private — no contributor licence agreement, no open-core tier, no feature held back for a paid edition. Third-party notices are listed in THIRD_PARTY_NOTICES.md; the models you call keep their own terms.

Local-first. Workflows are files on your disk, runs execute on your machine, and there is no OpenStateGraph service to phone home to — the page you are reading makes no network requests either. The only traffic leaving your machine is the model call you configured.

One deliberate consequence: graph previews use LangGraph's draw_mermaid(), which returns text, rather than draw_mermaid_png(), which would post your graph to a third-party rendering API. We never send a user's graph to a stranger.

Because it is the one runtime whose primitives a canvas maps onto honestly: nodes and conditional edges, subgraphs, typed shared state with reducers, Send fan-out, durable checkpoints. Drawing a box on a canvas means something exact there.

And only LangGraph because a multi-runtime abstraction would be unbindable, not merely leaky — no competing framework accepts a serialisable graph, so the interface would have nothing to bind to. Portability is preserved where it is cheap instead: workflow.json stays vendor-neutral, expressions are a JSON AST rather than host-language lambdas, reducers are a named enum, and no LangGraph type name leaks into the document.