Comparisons / Comparison
Murmurator vs Make
Both give you more than a straight line. The difference is what the structure is for — laying out data transformation visually, or bounding what a model is allowed to cause.
The short version
A visual graph, or a controlled one
Make
Make is the most visually expressive of the mainstream integration platforms. Where a linear builder shows a list, Make shows a graph, with branches, merges, iterators and aggregators as first-class elements on a canvas. For automations with real branching and data reshaping, people who think spatially often find it clearer than a code file.
Murmurator
Murmurator's structure exists for a different reason. Its graph is not primarily a drawing surface — it is the place the boundary between model reasoning and deterministic logic is written down, so that what the automation may do can be reviewed without running it.
Both are graphs. One is optimised for seeing how data moves; the other for seeing where judgment enters and what it is allowed to touch.
Be honest about this bit
When Make is the right answer
Make is a serious product with a clear thing it is best at, and for a lot of work that thing is exactly what you need.
- The automation is mostly data transformation, and seeing it laid out visually genuinely helps
- You need iterators and aggregators over collections, drawn rather than coded
- The people building and maintaining it prefer a canvas to a definition file
- No model is involved, or the model is a small convenience rather than the load-bearing step
- You want a wide connector catalogue with strong branching in the same tool
Make's metering counts credits per module execution, and loops consume them per iteration, so workflows that fan out over large collections are worth costing up front. Check their current pricing page rather than any comparison page, including this one.
Where we fit
Where Murmurator fits
If you find yourself drawing the diagram mostly so that a reviewer can see what the AI is allowed to do, that is the problem Murmurator was built for.
- The interesting step is a model forming a view, and the rest must not vary
- What the model may produce is declared as a schema and checked before anything acts on it
- Which branch runs is a condition on a value, not an inference at run time
- The definition is text, so a change is a diff with an author and a one-line summary
- The whole team runs the same workflow and sees the same runs
- Cost, tokens, agent turns and wall-clock time have ceilings per run and per month
The shape of it
What the structure is for
A visual automation graph
The shape describes how data flows and fans out. It is a genuinely good way to understand a transformation.
Murmurator
The shape describes where judgment is allowed and what it may cause. Reading it tells you what the automation can reach and what it may spend.
A model decides here The definition decides here
Side by side
Capability by capability
How to read this table. The Murmurator column is checked against this product's own documentation. The Make column is marked only where the answer is a stable, documented property; everywhere else it says varies and describes the shape of the answer, because their product is theirs to change and we would rather send you to their docs than guess. There are no scores here, and no winner.
| What you are choosing between | Murmurator | Make |
|---|---|---|
| Visual authoring | Workflows are read as a step graph in the app, but the definition is YAML and the assistant writes it from a description. There is no drag-and-drop canvas. | A visual canvas is the product's defining characteristic. |
| Branching, iteration and aggregation | Conditions on values, dependency-ordered steps, and sandboxed JavaScript with typed outputs for reshaping data. No visual iterator or aggregator. | Routers, iterators and aggregators are first-class elements. |
| Where it runs | Hosted by us. No self-hosted build. | Hosted. Self-hosting is not part of the product. |
| AI steps inside a workflow | llm and agent step kinds, with model, prompt, schema, tool list and budget declared in the definition. | AI modules exist. Check their current documentation. |
| Validated model output | A JSON schema on the step. Output outside the shape fails the step instead of flowing on. | Depends on how the scenario is assembled. |
| Guardrails on AI steps | Named tool lists, iteration caps, and token, cost and duration budgets per step, per run and per month. | Check their documentation. |
| Workflow versioning | Every save is a version with a summary, an author, its origin and a diff. Runs are pinned to the version they started with. | Check their current versioning behaviour. |
| Execution visibility | Per-step input, output, logs, error and token count, streaming live and kept afterwards. | Execution history is standard; detail and retention are theirs to document. |
| Cost model | A flat monthly plan per account, with no per-run fee. AI is either your own provider keys at no markup, or built-in models billed per token. | Credit-based metering per module execution, including per loop iteration. Check their pricing page for current rates. |
| Human approval | No approval step kind. A step posts the evidence and the run ends; a second workflow triggered by the reply carries out the action. | Check their docs for approval and break/wait behaviour. |
- Make help centre — the current answer for every Make row above
- Murmurator workflow reference — every Murmurator row is a feature documented here
- Integration platforms compared — our own longer survey of this category
Other comparisons
Read next
See how your AI process could become a controlled workflow.
14-day free trial with $5 of built-in AI included. No card, no per-run fees, cancel anytime.