Run
Jobs
A job is the durable handoff between Mobius and a worker. It records one customer-hosted action or model request while it waits, runs, and returns a result.
Jobs are mostly a diagnostic concept. Operators usually care about the run and its result. Open the job when a run says it is waiting for a worker and you need to understand the handoff.
How jobs fit into a run
A loop step or agent asks for an action or model. If a worker owns that capability, Mobius creates a job. A compatible worker claims it, performs the work, and reports the result back to the step.
The run shows the business process. The job shows the infrastructure boundary. That separation keeps worker connection and retry details out of the loop definition while preserving enough evidence to diagnose the handoff.
When to inspect a job
Look past the run into the job when:
- No worker has claimed the work.
- A worker repeatedly disconnects or retries the same work.
- The action or model route appears incompatible with the online pool.
- You need to distinguish worker failure from loop or agent failure.
Start with the run timeline and the waiting step. It identifies the required action or model and links the job to the larger process.
The job lifecycle in plain language
A job waits for a compatible worker, belongs to one worker while it is being performed, and finishes with a result or failure. If a worker disappears, Mobius can make the work available to another compatible worker.
That recovery keeps a crashed process from owning work forever. It does not guarantee that an external side effect happened only once. Customer-owned actions should use stable external identifiers or their own deduplication when retries could repeat a change.
Diagnose the handoff
When a job waits too long, check these boundaries in order:
- Is any worker connected?
- Does an online worker advertise the required action or model?
- Is it in the right queue or managed environment?
- Does it have free capacity?
- If it claimed the job, did the worker return an actionable error?
This sequence usually explains the problem without requiring protocol-level inspection.
Use the CLI command reference for terminal diagnosis. Worker implementers can use the interactive API reference for exact status, lease, heartbeat, and reporting behavior.