> ## Documentation Index
> Fetch the complete documentation index at: https://docs.celerflow.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflows

> A named DAG of steps built in chat, deployed to your team, and run on demand or on a schedule.

A workflow is a directed acyclic graph (DAG) of steps. You describe what you want in plain English; the [Planner](https://docs.celerflow.ai/concepts/planner.md) 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](https://docs.celerflow.ai/concepts/platform-agents.md) 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

| State | Meaning |
| - | - |
| `draft` | Built in chat, not yet deployed |
| `ready` | Validated and ready to deploy |
| `deploying` | Deploy command queued with Trigger.dev |
| `active` | Live and accepting runs |
| `running` | A run is currently in progress |
| `completed` | Most recent run finished successfully |
| `failed` | Most recent run ended in error |

## 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](https://docs.celerflow.ai/concepts/triggers.md) 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](https://docs.celerflow.ai/concepts/triggers.md) for how each one is configured and secured.

## Building and running

* To build a workflow from scratch, see the [Planner](https://docs.celerflow.ai/concepts/planner.md) and the [Building a workflow](https://docs.celerflow.ai/dashboard/building-a-workflow.md) UI walkthrough.
* To inspect past runs, see [Runs & executions](https://docs.celerflow.ai/concepts/runs.md) and the [Executions](https://docs.celerflow.ai/dashboard/executions.md) dashboard.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.