Workflows

A workflow is a directed acyclic graph (DAG) of steps. You describe what you want in plain English; the Planner assembles the graph; you confirm and deploy. From there, runs execute automatically.

​

Two phases: authoring and execution

CelerFlow deliberately separates building a workflow from running it.

• Authoring — A chat-driven loop. The Interview agent clarifies your goal and produces a Requirement Brief; once you confirm it, the Planner compiles a DAG you can review on the canvas. Everything here is conversational and revisable.
• Execution — After you deploy, the workflow enters a deterministic execution plane orchestrated by Trigger.dev and run on Railway. Runs no longer depend on chat context — the confirmed graph is the source of truth.

​

Anatomy of a workflow

Each step in the graph has three things:

• Agent — which platform agent handles this step (e.g. web_search_agent, summarize_agent).
• Inputs — values bound either from the trigger context / workflow_input (supplied at run time) or from a previous step’s output_key.
• Output key — a named result that downstream steps can bind to their inputs.

Steps are ordered by dependency. A step can’t run until all its upstream inputs are resolved. A step can also fan out over an array, running the same agent on each element with bounded concurrency and aggregating the results.

​

Lifecycle states

​

Redeploy behavior

When you refine a workflow in the same Planner session and deploy again, CelerFlow upgrades the existing workflow in place rather than creating a duplicate. The workflow_id is pinned via the URL, so reruns and history stay attached to the same record. If you start a completely new chat, a new workflow record is created.

​

How a deployed workflow starts

Once active, a workflow can be started in several ways:

• Manually — run it on demand or rerun a previous run from the detail page.
• On a schedule — a cron-style trigger runs it automatically.
• From a webhook — an external system POSTs a signed payload to a per-workflow URL.
• From the API — a call to the workflow’s API trigger with a cfk_ key.

See Triggers for how each one is configured and secured.

​

Building and running

• To build a workflow from scratch, see the Planner and the Building a workflow UI walkthrough.
• To inspect past runs, see Runs & executions and the Executions dashboard.