Langflow

The trait that decides it is shared visibility. Dragging boxes and wires means a product manager or a data analyst can look at what the agent does and argue about it with you, which is worth more than elegance on most teams. Getting from nothing to a working prototype takes an afternoon, and you keep it running on your own machine.

It gets uncomfortable when the canvas grows past a screen and the wires start crossing. Pick it for prototypes and shared understanding. Pick Dify when you want the finished app around the flow instead of the flow itself.

The risk is reviewability. What the builder produces is a serialised graph, and a serialised graph does not diff into anything a reviewer can reason about. Two engineers editing the same flow produce a conflict resolved by choosing a whole file. Approval degrades into opening the tool and eyeballing the picture, which is not a control.

Treat the flow file as a binary asset and put the review burden on a demo, not a diff. What it does right: any flow publishes as an API, so the canvas is a starting point rather than a dead end you have to rewrite.

1. The diagram is a front end over a Python runtime, so nodes are executed objects rather than generated code, which keeps behaviour identical between the editor and a deployment. 2. Wiring covers models, vector stores and tools, making retrieval an explicit node rather than hidden middleware. 3. A finished graph can be published so its steps become callable tools for outside clients.

No benchmark accompanies any of this, so throughput and accuracy claims are absent rather than unverified. One observation: a builder whose steps become somebody else's tools has inverted the usual dependency.

Distribution is not the problem here. More than 150,000 stars and a project running since February 2023 give this the reach most funded competitors are still buying. The problem is that everything published is free: self-hosting costs nothing and the hosted account costs nothing, so the monetisation is either upstream in somebody's larger platform or not yet written down.

Moat: mindshare and integration breadth, which is real but rentable. Likely path: the visual layer becomes the on-ramp for a database or cloud vendor's paid stack rather than a standalone business. Position: adopt freely, expect the commercial layer to arrive above you.

Cost is the easy part: nothing, for sixty engineers, plus whatever the model endpoints bill. The hard part is that it does not run unattended, so a flow cannot be executed as a gate in the pipeline and regressions are found by a person clicking. Anything that reaches customers this way reaches them untested by us.

Single sign-on, audit trails and retention policy are not documented for the self-hosted deployment, and support is a community repository, not a contract. Onboarding is genuinely cheap, a couple of hours. Approved with conditions: prototypes and internal tools, nothing customer-facing.

MIT, and a single docker run puts the whole thing on a port I chose, on hardware I own. Local endpoints are supported, so my own models serve the nodes and nothing has to leave the network. That combination is rarer than the marketing on this board suggests.

The part I actually care about is that it works both directions on MCP: it consumes my servers as tools and it exposes its own steps as tools to my other clients. Plus an OpenAPI surface for the things that speak neither. That is composable in the sense I mean it, not the sense a landing page means it.