Workflows

A workflow is an automation made of one trigger and a list of steps. The trigger decides when it runs — on a schedule, on a GitHub or Slack event, on a webhook call, or by hand. The steps decide what happens — calling tools on your connections, asking a model, running an agent, or reshaping data with JavaScript.

Under the hood each workflow is a short YAML definition. You rarely need to read it, but it's always one click away under Definition (YAML) and is described fully in the workflow reference.

trigger:
  kind: schedule
  cron: "0 9 * * 1-5"
  timezone: America/Toronto
steps:
  - key: prs
    kind: tool
    tool: github.list_pull_requests
    args: { repo: acme/api, state: open }
  - key: summary
    kind: llm
    model: fast
    prompt: "Summarize these pull requests for standup: {{ steps.prs.output }}"
  - key: post
    kind: tool
    tool: slack.post_message
    args: { channel: C01ENGINEER, text: "{{ steps.summary.output.text }}" }

Building with the assistant

Workflows are always written by the workflow assistant — you describe, it builds. Open any workflow and use the chat panel beside it. The assistant:

• reads your connections and models before using them, and won't reference anything that doesn't exist;
• asks when something essential is ambiguous (which repository, which channel, what to do on failure);
• writes the complete definition, validates it, fixes any errors, and saves a new version;
• tests JavaScript in the same sandbox runs use before saving it;
• explains what it built or changed in plain language;
• can run the workflow, read run results, and debug failures when you ask.

Things you can say:

You say	The assistant
"Also post the summary to #releases"	Adds a Slack step and saves a new version
"Only do this for PRs labelled needs-review"	Adds a condition to the relevant steps
"Use the smart model for the review"	Changes the step's model
"Why did the last run fail?"	Reads the run's steps, errors and logs and explains
"Run it for PR 1482 in acme/api"	Starts a manual run with those inputs
"Turn it on"	Enables the trigger

Start a fresh conversation any time with New chat; the workflow and its history are unaffected. Chatting with the assistant is included in every plan and is never billed as Murmurator AI usage; see AI models.

You can also build and edit workflows from your own agents — Claude, Cursor or anything that speaks MCP — using the same tools the assistant uses. See MCP server.

Drafts

A workflow you've just described is a draft until the assistant saves its first version. Drafts have no steps and can't run. If the assistant needs something from you first — say, a Slack connection that doesn't exist yet — the workflow stays a draft until you answer.

Versions

Every save creates a new, numbered version with a one-line summary of the change, who made it, and whether it came from the assistant or an MCP client. Open History on a workflow to see every version and a highlighted diff against the previous one.

Runs are pinned to the version that was current when they started. Editing a workflow never changes a run that's already in progress, and a run's page links to the exact version it used.

Enabling and disabling triggers

New workflows start with their trigger disabled, so nothing fires until you're ready. Use Enable trigger / Disable trigger on the workflow page, or ask the assistant.

• Enabled — the trigger fires automatically (schedules run, webhooks and events start runs).
• Disabled — nothing starts automatically. You can still press Run to start a manual run at any time.

A workflow can only be enabled when its definition is valid. The workflow list shows each workflow's status: draft, disabled or enabled.

Inputs

Workflows can declare inputs — values supplied when a run starts, like a repository name or an issue number. When you press Run, Murmurator shows a form for them; MCP clients pass them as inputs. Inputs can be required and can have defaults, which scheduled runs use.

inputs:
  repo: { type: string, required: true, description: "owner/name" }
  number: { type: integer, required: true }
  dry_run: { type: boolean, default: true }

Steps read them with templates like {{ inputs.repo }}. See Data flow.

Settings and deleting

Use the gear icon on a workflow to rename it or change its description. Deleting a workflow removes its versions, runs and conversations permanently.

Limits

• Up to 50 steps per workflow.
• Step keys are lowercase letters, numbers and underscores, starting with a letter, and unique within the workflow.
• Never put secrets in a definition — they belong on connections. The validator rejects definitions that reference connections or models your account doesn't have.