Run in the background
Available now Background runs detach from one MCP request.
If the workflow can outlive one tool request, use a background run. The server persists the run record during admission and then returns a runId.
Start the run
Section titled “Start the run”Send this payload through the workflow tool:
workflow tool · background run request
{ "action": "run", "scriptPath": "/absolute/path/to/first-inspection.workflow.js", "args": { "request": "Find the source that defines the CLI commands." }, "maxAgents": 1, "tokenBudget": 8000, "background": true}Keep the returned runId. The accepted response has status: "running" and the resolved limits.
Background admission does not start a remote run. The run remains in the current MCP server process.
Await the run
Section titled “Await the run”Send a bounded await request:
workflow tool · bounded await request
{ "action": "await", "runId": "mabc1234-k9x2pq", "waitMs": 20000, "lastN": 10, "logLines": 20}Replace the example run ID with the returned runId.
The request returns when the run becomes terminal or the wait reaches its bound. A wait timeout reports the current status.
If the status is pending or running, send a new await request. Do not set waitMs above 25000.
At terminal status, the await response includes outcome. A completed outcome contains the authored result without changes.
Inspect without waiting
Section titled “Inspect without waiting”Send an inspect request for the current snapshot:
workflow tool · inspect request
{ "action": "inspect", "runId": "mabc1234-k9x2pq", "lastN": 10, "labelGlob": "*", "logLines": 20}Inspection does not change the run. Before an await, stop, or resume request, inspect the run.
Current background limit
Section titled “Current background limit”One MCP server process accepts a maximum of four active or starting background runs. Before you retry a rejected admission, await an existing run.
If the server process exits, in-flight work stops. You can use completed journal entries in a new resume run.