Running Automations

The beta has two sequential execution paths: one for the editable canvas and one for deployed scripts. Both run each tool the same way, but they do not share a scheduler.

Canvas Runs

The Automations tab's Run action:

  1. Collects every tool card.
  2. Keeps only tool-to-tool connections.
  3. Requires at least one connection.
  4. Sorts all tools into a runnable order.
  5. Starts with empty input.
  6. Runs every sorted tool.
  7. Passes each tool's output to the next tool.

Document cards do not participate.

Canvas execution is suitable only for tools that can start without external input or acquire their own data.

Deployed Script Runs

A deployed run:

  1. Loads the script.
  2. Chooses initial input.
  3. Iterates the pre-sorted tool list.
  4. Loads each live tool definition.
  5. Runs it.
  6. Passes the result forward.
  7. Returns the last result as the final output.

The saved connections are not evaluated at runtime — only the order they produced at deploy time.

A Tool containing one configured RunPythonScript step runs like any other automation node. It returns the normal structured process result, which becomes input to the next Tool. Use one Tool per interpreter, script, and argument configuration when several scripts form a workflow.

Input Priority

A deployed run chooses input in this order:

  1. Explicit input supplied by the caller
  2. Usable saved file or folder bindings
  3. Empty input

Power Strip drops and browser capture supply explicit input, so they override saved bindings.

Running from the Power Strip Automation sidecar without a drop passes no explicit input, so the runner uses saved bindings when present.

Missing saved paths are logged and skipped. If none remain usable, execution continues with empty input.

Power Strip Paths

A deployed automation can be bound to a Power Strip Automation command.

  • Open its sidecar to inspect the pipeline and run it.
  • Drop files, folders, or text on the command to provide explicit input.
  • Use Run Automation as a browser command to capture the active Chrome page and supply it as input.

These runs are desktop-side. The Chrome extension does not own the automation runtime.

Branches Are Flattened

Connections determine only a legal order.

For A connected to B and C, both B and C run. For B and C both connected to D, D receives only the output of whichever tool happened immediately before D in the flattened order.

There is no independent branch state and no merge.

Failure Behavior

Current failure reporting has important gaps:

  • A missing tool definition is logged and skipped.
  • If a tool throws an error, the deployed runner stops and reports failure.
  • If a tool returns a normal failure result instead of throwing, the automation loop does not inspect it. The tool may be logged as done and the run continues.
  • Canvas execution catches errors per tool and continues to later tools.
  • There is no automation-level cancellation, retry, timeout, or rollback. A positive timeout configured inside a Python-backed Tool still applies to that individual process.

A reported automation success means the sequential loop completed, not necessarily that every tool succeeded.

For beta-critical workflows, make each tool's final step produce an observable artifact or validation result and verify it after the run.

Result

A deployed run reports:

  • Script ID and name
  • Overall success or failure
  • Start and finish timestamps
  • A text log
  • The final output

There is no per-tool output store, branch history, durable run history, or resume token.