Describe the workflow.
Not the implementation.

The problem

You are thinking in dataflow. You are writing everything else.

A trigger feeds a step, the step calls an agent, the output feeds another step, maybe a retry, then a sink. That picture is simple. But the moment you open an editor, the language makes you manage machinery that has nothing to do with it.

When the language fits the domain, the code becomes a direct translation of intent. Everything else follows from that.

The core vocabulary

Eight concepts. No spare parts.

Every idea earns its place by being needed to describe how work flows through a graph. This is the core of the language; the rest is data, built-ins and host adapters.

type Issue = { number: int }

trigger issue_opened:
  kind: github
  config: { path: "/api/github/webhook", target: { one: { repo: "acme/widgets" } } }

step draft:
  runner: agent

runner agent:
  kind: opencode
  in:   open
  out:  open

in: { issue: in.issue }

prev feedback: review.result

sink result:
  kind: file
  config: { path: "out/result.json" }

external port credential
  (key: text) -> secret

Anatomy of a factory

One real file, read top to bottom.

A GitHub issue arrives, an agent drafts a reply, and a reviewer approves it or sends it back. The loop retries while the reply is not ready, and the result is posted back to the issue. Pick a part to see what it does. validated · v1.35

The real file: examples/reply.fct. It passes fct validate and fct sinks.

Beyond the loop

Small language. Sharp edges.

The retry is the execution model. These are the everyday features that keep the factory small: collections without loops, open-keyed data, absence that cannot be confused with null, and configuration that lives with the deployment.

labels: [text] = list::map(
  in.issue.labels, l -> l.name
)

type Labels = map(text, text)
team:  text = labels.team
owner: text? = map::at(labels, "owner")

type Issue = { milestone: text? }

sink save:
  when: start.issue.milestone is some
  in: { text: opt::value(start.issue.milestone) }

model: text = config(
  key: "agent.model",
  default: "opencode-go/deepseek-v4.1-flash"
)

Short excerpts from the validated factories; the anatomy above is the complete file.

The execution model

A run is a round of firings until nothing can fire.

Press play. The trigger admits a GitHub issue, the loop runs draft → review, the reviewer sends the draft back once, then approves. The progress sink fires inside the loop — once per pass — while comment waits downstream and posts once.

A simulated animation of reply.fct. The code and adapters are real; the run is illustrative.

Why a spec

Write the factory once. Host it anywhere.

The factory describes what should happen. The host supplies how: which trigger kinds exist, which runner backends run, where sinks write, how ports resolve. Those are adapter concerns — so they can compete without locking in your workflows.

The spec defines the concepts; implementations follow. Tooling — validators, diagrammers, editors — can be built against the interface, independently of any one host.