Flow engines

Four engines run flows. They share the file format, the node types, the routing, the retry policy and the execution model — everything on the preceding pages applies to all of them. What differs is which atoms each can call, and that follows from what each is for.

Engine	Runs	Reached by	Atoms
Automate	Build and deployment pipelines	`kis flow`	Common + infrastructure
AI Flow	Model orchestration and agents	The AI Flow block	Common + AI + streaming
Workflows	Long-running business processes	The Workflows block	Common
Datapipes	Bulk data movement	`kis datapipes`	Pipeline operations only

Automate

The general-purpose engine, and the one kis flow runs. It sees the common atom library — shell, SSH, files, archives, HTTP, databases, object storage, git, secrets — plus infrastructure operations for services, processes, ports, cron entries, OS users and Kubernetes.

This is the default choice for anything an operator would otherwise do by hand: building from trunk, tagging a release, restarting a fleet, taking a backup.

kis flow -f build.yaml -w 4

AI Flow

Model orchestration. It sees the common library plus atoms for chat completion, embeddings, intent detection, guardrails, reranking, vector search, retrieval-augmented answering, and the reasoning patterns built on them.

It also carries the streaming variants of the pipeline operations, so a flow can read a source and feed it into a model without leaving the engine.

AI Flow adds one idea the others do not have: a harness, a flow with cycles — bounded iteration, budget gates, and resumable trajectories. That is what an agent runs on. See AI Flow concepts.

Workflows

Long-running business processes: an expense approval, an onboarding with a manager gate, a refund that needs review. It sees the common library and nothing more, because a business process coordinates rather than computes.

Its distinguishing property is durability. A workflow can suspend at a wait: node, survive a restart of every service involved, and resume weeks later when a signal arrives. Most of its wall-clock time is spent doing nothing at all, which is exactly what it is built for.

Datapipes

Bulk data movement: read from a source, transform, write to a sink. Reached with kis datapipes.

kis datapipes -f pipeline.yaml -v batch=2026-06 -e env.yaml

Its operations are readers, writers and transforms — CSV, Excel, Parquet, databases, REST endpoints, entities in a datastore, plus aggregation, summing and reshaping.

The common library is not bound here. A datapipe has no shell:, no ssh:, no git:. That is a deliberate boundary rather than an omission: a pipeline that moves a million rows should not also be a place to run shell commands, and keeping the surface narrow is what lets the engine stream records rather than materialise them.

If a pipeline needs to shell out, the shape you want is a flow that calls the pipeline, not a pipeline that shells out.

Why the task sets differ

Each engine binds its own set of atom libraries. The libraries themselves are shared — the shell operation available to Automate is the same one AI Flow has — but which are bound is a property of the engine.

Three of the four bind the common library, so most of what you learn transfers. Datapipes is the exception, and the reason is worth understanding rather than working around: its execution model streams records through a pipeline, and the common atoms are units of work, not stages in a stream.

When a task name is not found, the message names the engine. Check the table above before assuming a typo.