Blueprints, jobs, and runs
Use the right identifier when launching, monitoring, or controlling work.
| Resource | What it represents | Use it for |
|---|---|---|
| Blueprint | A reusable package of workflow, execution, contracts, configuration, and dependencies | Validation and launch |
| Job | A durable configured definition | Starting runs and managing persistent job data |
| Run | One execution of a job | Status, logs, artifacts, pause, resume, and cancellation |
| Operation | An accepted asynchronous administrative action | Tracking preparation or removal to completion |
Keep both IDs returned by a launch. runtime_run_id is internal diagnostic metadata; use the public run_id in HTTP URLs.
mn job show <job-id>
mn job start <job-id>
mn run list --job <job-id>
mn run show <run-id>A workflow step describes work and its dependencies. Agents execute that work through declared runners. HostLocal uses host permissions; Docker and OpenShell have their own mount, environment, and network boundaries. Read Security before supplying real inputs.
One job and its workers execute on one owner runtime node. Connecting more nodes adds placement choices for independent jobs; it does not split an individual run across them or automatically take over an unavailable owner.
Use Quickstart for a complete launch procedure and Monitor for logs, outputs, and human requests.