Move your Make scenarios to LiveGraph

A Make scenario is a reliable linear pipe. LiveGraph is for the runs where a hop needs judgment — and where a wrong hop needs steering, not a re-run.

How the move works

There's no Make file importer, and we'd rather say that than half-convert your scenario. The honest path is generate, not import:

Export the blueprint. In the Scenario Builder, the three-dot menu → Export blueprint downloads the scenario as JSON — modules, settings, and mapped values.
Paste it into the describe box when you create a graph here — or describe what the scenario does in words. LiveGraph generates the equivalent node/edge structure.
Review the generated graph. It lands as an ordinary editable graph — tighten prompts, rewire edges, then run it.

What a scenario maps to

Make	LiveGraph
Trigger module (schedule / webhook / watch)	Runs start from schedules, webhooks, chat, or the canvas Run button
App modules in sequence	Worker nodes, each with the tools it needs — `http_request`, MCP servers, file access — scoped per node
Router + route filters	A router node — `auto` edges where the model picks the branch, or `explicit` edges for fixed routing
Iterator / aggregator	Fan-out and join nodes — map over items, then merge the results
Text / AI modules	Worker nodes with prompts and a per-node model — any provider, not one vendor
Error handlers / ignore / break routes	A reviewer or fallback node routed like any other edge — visible on the canvas, not a hidden branch

What carries over

The route. Module order and where the router fans out — the blueprint spells it out, so the generated graph follows it.
Branch logic. Filter conditions become router instructions or explicit edges — review the generated routing prompt before trusting it.
Trigger intent. Schedules stay schedules, webhooks stay webhooks — same firing model.

What doesn't move

Connections. Make's OAuth connections stay in Make — every app a node touches gets re-authorized here as an MCP server or HTTP endpoint, scoped to that node.
The module catalog. This is the honest caveat: Make's thousands of ready-made app modules don't port. Tools here are MCP servers or named http_request endpoints — wired by hand, a few minutes each.
Data mapping and functions. The blueprint's mapped values and Make's function syntax have no counterpart — a node's inputs are described in words and wired on edges, not templated per field.
Scenario inputs/outputs between scenarios. A "call a scenario" chain becomes one graph with more nodes, or a graph that dispatches to another — redesigned, not translated.

An honest fit check

If a scenario is deterministic plumbing — trigger, transform, post, done — Make is genuinely good at it and moving buys you nothing. LiveGraph earns the move when a step needs judgment (which branch, which specialist, is this output good enough) and when a run going sideways needs a person to redirect it. On LiveGraph you watch each hop live, a run parks at an approval gate until someone says yes, and dragging an edge mid-run steers the run you're watching — Make's answer to a bad run is stop, edit, re-run.

Start

Create an account, paste your simplest scenario's blueprint into the describe box, and run it once — or watch the live demo first: a real multi-agent graph running in your browser, no signup.

How the move works

There's no Make file importer, and we'd rather say that than half-convert your scenario. The honest path is generate, not import:

Export the blueprint. In the Scenario Builder, the three-dot menu → Export blueprint downloads the scenario as JSON — modules, settings, and mapped values.

Paste it into the describe box when you create a graph here — or describe what the scenario does in words. LiveGraph generates the equivalent node/edge structure.

Review the generated graph. It lands as an ordinary editable graph — tighten prompts, rewire edges, then run it.

What a scenario maps to

Make	LiveGraph
Trigger module (schedule / webhook / watch)	Runs start from schedules, webhooks, chat, or the canvas Run button
App modules in sequence	Worker nodes, each with the tools it needs — `http_request`, MCP servers, file access — scoped per node
Router + route filters	A router node — `auto` edges where the model picks the branch, or `explicit` edges for fixed routing
Iterator / aggregator	Fan-out and join nodes — map over items, then merge the results
Text / AI modules	Worker nodes with prompts and a per-node model — any provider, not one vendor
Error handlers / ignore / break routes	A reviewer or fallback node routed like any other edge — visible on the canvas, not a hidden branch

What carries over

The route. Module order and where the router fans out — the blueprint spells it out, so the generated graph follows it.

Branch logic. Filter conditions become router instructions or explicit edges — review the generated routing prompt before trusting it.

Trigger intent. Schedules stay schedules, webhooks stay webhooks — same firing model.

What doesn't move

Connections. Make's OAuth connections stay in Make — every app a node touches gets re-authorized here as an MCP server or HTTP endpoint, scoped to that node.

The module catalog. This is the honest caveat: Make's thousands of ready-made app modules don't port. Tools here are MCP servers or named http_request endpoints — wired by hand, a few minutes each.

Data mapping and functions. The blueprint's mapped values and Make's function syntax have no counterpart — a node's inputs are described in words and wired on edges, not templated per field.

Scenario inputs/outputs between scenarios. A "call a scenario" chain becomes one graph with more nodes, or a graph that dispatches to another — redesigned, not translated.

An honest fit check