Product overview

The technical workflow layer

Flow is a local-first AI orchestration platform that keeps inference data on the workstation while AI advises and a deterministic engine executes. It sits below enterprise BPM and above ad-hoc scripts, turning the processes that live in human memory and undocumented scripts into visual, executable, reviewable flows.

The problem

Fragmented tools, invisible knowledge

Engineers in technical environments work across many separate systems. They move between CLI tools, log viewers, job schedulers, and monitoring dashboards. The processes that tie this work together often exist only in human memory, undocumented scripts, and legacy knowledge. As a result, onboarding takes a long time, every failure point has to be interpreted by hand again, and the organization has no clear view of what teams are doing.

Flow addresses this at the workflow layer. Engineers design flows on a node-based canvas, run them through a deterministic orchestration engine, and get AI-assisted interpretation and validation at the point of need. Flow is useful even without AI. As a visual orchestration platform, it reduces context switching and lets teams share flow templates with each other.

How a flow runs

Canvas, engine, and local reasoning

This pattern, AI-assisted interpretation embedded within deterministic execution, is what Flow calls Reasoning-Augmented Orchestration. It rests on three properties: zero egress by construction, deterministic execution authority, and a standardized node contract that lets new domains arrive as models rather than platform rebuilds.

01

Design

Compose action, utility, AI, agentic, and service nodes on the canvas. You can also describe the flow and review the graph that is generated for you. Every flow is also a Flow DSL text document.

02

Execute

The Rust orchestration engine runs the graph deterministically. It runs independent branches at the same time, applies per-node retries and timeouts, routes along pass, fail, and always edges, and confirms destructive actions with a gate before risky steps.

03

Interpret

AI nodes run local models to validate inputs and interpret outputs at the point of need. Models recommend, and the engine executes. If inference fails, the flow continues with the AI step skipped. It is never blocked.

Flow architecture: domain boundaries and local inference
Flow domain boundaries and local inference architecture.
Competitive landscape

Where Flow sits

Flow operates at the technical workflow layer. It sits below enterprise BPM systems and complements them. Flow is designed to integrate with those systems rather than replace them.

Category Limitation Flow advantage
CLI + scripts Non-visual, no audit trail, no AI Visual, traceable, AI-assisted
AI coding and terminal assistants Chat over repos and shells; no flow composition or run governance Flows as governed, reviewable, reusable artifacts
Workflow tools (n8n, Airflow) Local AI and approval gates are opt-in assemblies, not defaults Managed local inference and engine-only execution by default
AIOps and runbook automation Built around incident detection and response A design surface for everyday engineer flows
IBM watsonx (mainframe) On-prem AI requires a platform estate; assistant surface, not flow design Desktop-scale install; visual flows with local inference by default
Adoption path
Phase 1

Individual

Flow installs local-first and has no infrastructure dependency. Its zero-egress architecture removes the need for cloud data processing agreements and external inference approvals.

Phase 2

Team

Individual flows become shared assets through the template repository, versioned flows, and lightweight governance. DSL files go through normal code review, including pull requests, code owners, and branches.

Phase 3

Organization

Flow becomes a cross-team operational platform that integrates with CI/CD, QA, and operational flows. The governance service, RBAC, and audit logging support it at this scale.

See the full architecture

Isolation boundaries, the execution model, adapters, and the DSL are documented end to end.