Competitive landscape

Flow is a developer- and engineer-centric workflow tool for technical operational workflows across mainframe, CI/CD, QA, and infrastructure domains. It operates at the technical workflow layer, below and complementary to enterprise BPM systems, and is designed to integrate with them rather than replace them.

Flow’s position is the combination. Every ingredient below exists somewhere in the market. No researched competitor ships all of them together as enforced product defaults in a desktop-scale install:

A visual canvas that round-trips to a PR-reviewable DSL. The graph and the text are the same artifact, with canonical serialization, so flows move through pull requests like code.
AI at the execution decision point, behind a hard boundary. Models generate flows, interpret failures, and plan fixes. Models never execute and never hold credentials. Only the deterministic engine executes. The boundary is architecture, not configuration.
Local inference as the managed default. A managed llama-server runtime and a governed Model Hub ship in the product. Zero egress is the default posture; cloud AI is an explicit, off-by-default carve-out.
Governance built in. Template, node, and model registries with approval lifecycles, audit logs, and sandboxed shell execution.

The closest competitor: n8n

n8n is the highest-profile player in Flow’s nearest category. It is self-hostable, node-based workflow automation under a fair-code license, which makes internal self-hosting free. It raised a $180M Series C in October 2025 at a $2.5B valuation, and a reported May 2026 SAP stake implied roughly $5.2B (secondary reports only). n8n self-reports 6x user and 10x revenue growth. Whatever the exact numbers, the signal is clear. Self-hosted, AI-centric workflow automation is a large, fast-moving market, which validates Flow’s category while raising the bar in it.

On local inference and the execution boundary, n8n is the closest comparison. Here is how it stands, by its own vendor-stated bounds:

Local inference exists, as an opt-in assembly. n8n curates a first-party Self-hosted AI Starter Kit, a Docker Compose bundle that pairs n8n with Ollama and Qdrant. n8n itself labels it “For testing only” and tells users to “secure and harden” it before production. Zero egress is left to per-workflow user discipline, since the docs say “just remember to use the Ollama node” while hundreds of integrations, including cloud LLM nodes, stay enabled by default. Production-grade air-gapped n8n with local models is a real pattern, but it is assembled from parts, namely enterprise self-hosting plus a customer-managed Ollama or vLLM endpoint. It is not a managed product default.
The approval gate exists, as a per-tool toggle. n8n productized a human-in-the-loop review step for AI agent tools in January 2026 and positions it explicitly for regulated industries. The model proposes a tool call, a human approves, the n8n engine executes, and credentials live on workflow nodes rather than with the LLM. The gate is opt-in per tool, so the builder must mark each tool for review.

Flow’s contrast with n8n is defaults, not capability. In Flow, local inference is the managed in-product default rather than a testing-grade kit, and the execution boundary (models never execute, never hold credentials) is architectural rather than a per-tool setting.

Self-hosted LLM app platforms: Dify and kin

Dify represents the self-hosted LLM application platforms, alongside LangFlow and Flowise. It officially supports locally deployed Ollama models as a model provider, and it markets the pattern on data-privacy grounds, with the promise of “keeping your data on your own machine”. The path is documented but it is DIY. The Ollama provider is a marketplace plugin, and installing it needs internet egress unless you side-load it. The default Docker Compose bundles no inference runtime, and Dify’s own FAQ documents the connection-refused failure mode that requires manual host-networking remediation.

These platforms also target a different workload. They build LLM applications, chatbots, and RAG pipelines, rather than orchestrating shell, filesystem, and CLI operations with run-safety rails. Against them, the meaningful difference is managed versus DIY. In Flow, the local runtime ships in the product and is the default.

The incumbent in the beachhead: IBM watsonx

IBM is already operating in Flow’s mainframe-operations beachhead, and its on-prem posture is real.

watsonx Code Assistant (including WCA for Z) installs fully on-premises on Red Hat OpenShift with IBM Software Hub, with air-gapped installation an explicitly documented path and model inference served on the customer’s own cluster.
watsonx Orchestrate has an official on-premises install. It is heavyweight by construction: an OpenShift cluster plus the Software Hub control plane, version-locked releases, and GPU minimums (a 70B-class model needs four or more GPUs). A Docker Compose developer edition exists but is expressly not for production.
watsonx Assistant for Z (announced October 2025, GA the same quarter) brings agentic AI to mainframe IT management. With the Spyre Accelerator (GA December 2025), inference runs entirely on IBM Z. In IBM’s words, requests, decisions, and actions “never leave the mainframe”. It is an operations assistant surface, not a visual flow builder.

This is the most instructive entry in the landscape. The incumbent agrees with Flow’s thesis that regulated mainframe operations demand zero-egress AI. The difference is form factor and entry cost. Flow is a desktop app an engineer installs, while watsonx is a platform estate a company deploys. The surface differs too. Flow offers visual, PR-reviewable flow design, where watsonx offers an assistant.

Comparison matrix

Researched vendors, verified June 2026:

	Visual composition	Local inference	AI at the execution decision	Footprint
Flow	Node canvas round-tripping to a canonical DSL	Managed in-product default (llama-server + Model Hub)	Flow generation, failure interpretation, monitor and self-heal; engine-only execution, models never hold credentials	Desktop app (Server and CLI editions share the core)
n8n	Node canvas, JSON workflow export	First-party starter kit labeled testing-only; production is self-assembled (air-gapped self-host + customer-managed model server)	AI agent tools with an opt-in per-tool human-review gate; engine executes approved calls	Self-hosted server (Docker) or vendor cloud
Dify	Visual LLM-app and workflow builder	Documented via an Ollama marketplace plugin; no bundled runtime; manual networking	Centered on LLM apps and RAG, not operational execution rails	Self-hosted server (Docker Compose) or vendor cloud
IBM watsonx (Z portfolio)	Assistant surface, not a flow canvas	Fully on-prem and air-gapped documented; on-cluster or on-Z (Spyre) inference	Agentic AI for mainframe IT management	OpenShift + IBM Software Hub estate

Adjacent categories, characterized at the category level:

Category	Typical posture	Flow’s difference
CLI + scripts	Non-visual, no audit trail, no AI	Visual, traceable, AI-assisted
AI coding and terminal assistants	Chat over repos and shells; no visual flow composition or run governance	Flows as governed, reusable, reviewable artifacts
AIOps and runbook automation	Built around incident detection and response for distributed estates	A design surface for the flows engineers run every day, before anything pages
RPA and enterprise BPM	Business-process layer, org-wide deployment	Technical workflow layer below BPM; feeds status and artifacts upward

The difference is the defaults

Where these properties exist elsewhere, they arrive as opt-in assemblies (per-tool approval gates, zero egress by user discipline), testing-grade kits, DIY plugins, or platform estates. Flow ships them as the defaults of one desktop install. The local runtime is managed and on by default, governance is built in, and the safety invariant is structural, so models never execute and never hold credentials. Even in autonomous runs, where fixes are auto-applied within a capped, fully logged loop, the engine-only execution boundary never moves.

Where Flow integrates rather than competes

Enterprise BPM. Flow runs at the technical workflow layer and can feed execution status and artifacts upward into BPM systems for business-process orchestration.
CI/CD platforms. Flow integrates with existing CI/CD rather than replacing it.
QA platforms. Flow integrates with existing test and defect tracking.

Sources

Primary sources this page was verified against (June 2026):