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.

Budgets

A budget caps what a workflow may spend, so a runaway agent or a busy trigger can't burn through tokens or time. Set one at the top of the definition for each run and for the whole workflow per month, and on any llm or agent step for that step alone.

budget:
  tokens: 200000
  cost_usd: 2.50
  iterations: 40
  duration: 15m
  monthly_tokens: 5000000
  monthly_cost_usd: 50

steps:
  - key: triage
    kind: agent
    budget: { tokens: 50000, cost_usd: 0.50, duration: 5m }

Key	Limits	Where
tokens	Input and output tokens	Run, step
cost_usd	Murmurator AI spend, in dollars	Run, step
iterations	Agent turns across every agent step in the run	Run
duration	Time since the run or step started, such as 90s, 15m or 2h (up to 24h)	Run, step
monthly_tokens	Tokens across all of the workflow's runs this month	Workflow
monthly_cost_usd	Murmurator AI spend across all of the workflow's runs this month	Workflow

• Every key is optional. To cap a single agent's turns, use its max_iterations.
• Budgets are checked before each model request and each agent tool call. The request that crosses a limit is allowed to finish; the next one is refused.
• A step over its own budget fails, and the steps that depend on it are skipped. A run over its run or monthly budget stops: the step in progress fails, the remaining steps are skipped, and the run shows which limit it hit.
• Months are calendar months in UTC.
• Cost budgets only count Murmurator AI models, the only ones Murmurator knows the price of. Steps on your own models are limited by token budgets.

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.