Product
An orchestration layer around AI at work
A workflow engine that calls models where judgment is required, runs deterministic steps everywhere else, and keeps the boundary between the two in a definition anyone on the team can read.
68 seconds, narrated · Filmed in a demo account
The definition
One document that says what the automation may do
A workflow is YAML with a trigger, optional inputs, an optional budget and a list of steps. Steps run in dependency order, each one only after everything it depends on succeeded and only when its condition is met. Nothing about what it may reach is implied.
- Model output can be constrained to a JSON schema the next step relies on
- Agent steps get a named tool list and an iteration limit, 10 by default and 50 at most
- Conditions branch on values in the run, not on a judgement made at run time
- Budgets cap tokens, cost, agent turns and duration, per run and per calendar month
Execution
A dependable engine under every workflow
Triggers fire from GitHub, Slack, Linear, Stripe and other connection events, from schedules, from webhooks or from a click. Each run is pinned to the exact version it started with, and survives the worker it started on going away.
- Manual, schedule, webhook and connection event triggers
- Conditional branches, with dependents skipped and the reason recorded
- Crash-safe: interrupted runs resume at the step boundary they reached
- Per-step input, output, logs, errors and token counts, streaming in live
Connections
Scope access once, and every workflow inherits it
Add GitHub, Slack, Linear, Stripe, Shopify, Zendesk, Jira, PagerDuty, databases, email and dozens more with encrypted credentials. Each exposes typed tools your workflows and agents can call, and the limits you set live on the connection rather than being repeated in every prompt.
- Allow-lists for repositories, channels, teams, paths and recipients
- Read-only SQL with statement timeouts and row caps until you opt in to writes
- Webhook deliveries verified against the provider's own signature
- Decide per connection whether its tools appear on the MCP server at all
The assistant
The fast way to write one, not the reason to have one
Describe the outcome and the assistant reads your connections and models, drafts the steps, validates them against the account, tests JavaScript in the sandbox and saves a version. The value is the workflow it produces, which you read and own afterwards.
- Asks clarifying questions instead of guessing channels or repositories
- Refuses to reference connections, tools or models the account does not have
- Every save is a version with a summary, an author and a diff
- Diagnoses failed runs: “why did the last run fail?”
Workspaces
A folder of its own, and a coding agent in it
A run can clone a repository into a sandboxed workspace, hand the job to a coding agent that edits files and runs commands on its own, then run your test suite over the result and open a pull request only if it passed. The folder is deleted when the run finishes.
- Describe the job the way you would to a developer
- Pick the agent: opencode or codex, on your own models
- Your tests decide whether anything gets pushed
- Cloning and pushing obey the connection's allowed repositories
Example: Issue to pull request
Label an issue `automate`, get a pull request with passing tests.
Models
Built-in models, or bring your own
Start instantly with Murmurator AI, billed per token, or add Anthropic, OpenAI, Gemini, OpenRouter, Mistral, DeepSeek, xAI or Ollama with your own keys. Steps name a model rather than a provider, so you can swap what sits behind a name without touching a workflow.
- Murmurator AI: prepaid per token, with auto-recharge and a monthly spend limit an owner sets
- Your own keys: no markup, billed by your provider under your agreement
- Per-step token usage and cost on every run
Teams
Shared by default, owned by the account
A workflow belongs to the account, not to the person who wrote it. Invite your team with roles, improve a process once, and everyone gets the improvement. Every change lands in version history with who made it and where it came from.
- Owner, admin and member roles, with connections and models managed centrally
- Changes attributed to a person, the assistant or an agent over MCP
- Multiple accounts per person
- Runs in flight keep the version they started on
Step kinds
Two kinds reason. Two do exactly what you wrote.
Every step is one of four kinds, and you choose per step which side of the line it sits on.
Tool
Deterministic. Call one tool on one connection: post to Slack, query Postgres, comment on a pull request, or change code in a workspace.
LLM
Reasoning. One model call, optionally constrained to a JSON schema so the next step can rely on its shape.
Agent
Reasoning, with a leash. A model chooses which of its listed tools to call, bounded by an iteration limit and a budget.
JavaScript
Deterministic. Sandboxed code with typed inputs and declared outputs, checked on every run.
Turn one person's AI process into the company's.
Murmurator is invite-only. Already invited? Sign in and build something real.