Everything Dagweave does.

Pick each step from a searchable list and wire up the dependencies. Retries, timeouts and node selectors are fields on the step. Conditions are checked as you type, and you can try one on sample values before a run.

Pull manifests from a GitHub repo, a live cluster through the connector, or a paste. Retry strategies and artifact repository refs come in intact.

S3, Postgres, kubectl, Helm, docker builds, LLM calls, ready to drop on the canvas. Starter blueprints too, plus a marketplace for WorkflowTemplates your own team writes.

A standard Argo Workflows manifest, in a repo you own, as a commit or a pull request. Already keep WorkflowTemplates in Git? Link the folder. Stop using Dagweave and your workflows keep running.

Point any assistant that speaks MCP at Dagweave and ask for a workflow. It drafts, we tell it exactly what is broken with the draft, and what reaches you is a graph rather than a manifest you have to read line by line.

Enrol the cluster once. After that anyone with a Dagweave account can dispatch to it, without a kubeconfig of their own.

Enrol prod, staging and every region. The workflow exists once, and each trigger names the cluster it fires at.

Start a run from a button, a schedule, a GitHub push, an SNS topic or a signed webhook. Status comes back onto the canvas you built it on, node by node, and you can check it from your phone.

CronWorkflow children, argo submit, whatever fires overnight. They turn up in a section of their own, and nothing had to move first.

Reports, plots, CSVs and logs draw in the run detail. The object stays in the store your cluster already writes to.

Run a workflow locally with the commands you already use with the argo CLI. Free to download, and no account needed.

A bar per step against the clock, with the wait before a pod started drawn apart from the work it did. Steps link out to the Jaeger or Tempo you already run.

Which mutex you are queued behind and which run is holding it. How long a pod has been unschedulable, and what nothing on the cluster would take.

One team's fan-out waits its turn instead of taking the cluster. Each waiting run says how many of your team's runs go before it.

One CPU and memory budget per step, and what it actually used against what it asked for, measured off your own runs.

Every connection the connector opens goes outward. Your firewall rules stay as they are. Runs can get their own namespace and service account, and nothing of yours is left standing on the cluster.

An HTTP API for nearly everything the app does, with scoped per-user tokens. An MCP server runs on the same routes, and the assistant in your editor can pull a failed run itself.

Shared teams, roles and a second factor on sign-in. Put people in groups, grant a group one workflow at a time, and scope what their runs can touch on your cluster.