Sign in

v5

OpenAPI 3.1.02026-07-31129337684.6 KB
Workflow Execution

Pump Companions

Advance any due background work for a paused interactive run, WITHOUT consuming a user turn: due fork companions, then any armed conditional-edge evaluations on parked threads. A scheduler (or the client) calls this on an interval while has_background_work is True to realize background progress for the request/response Interactive REST driver. Returns the events produced — which may include MAIN-thread assistant output if a waiting condition matched — and whether more background work remains.

post/workflows/v1/workflows/{workflow_id}/runs/{run_id}/pump-companions

Path parameters

workflow_idstring required
Example:5eb7cf5a86d9755df3a6c593
run_idstring required

Response

Successful Response

run_idstring required

Session identifier (= MongoDB ObjectId of the underlying WorkflowRun record). Include in all subsequent POST requests to continue this session.

status'not_started' | 'started' | 'running' | 'failed' | 'completed' | 'paused' | 'waiting_for_user_input' | 'cancelled' | 'aborted_looping_risk' required
turn_numberinteger required

The turn that this response corresponds to (1-indexed).

eventsobject[] required

All events emitted by the workflow runtime during this turn. Includes start/end-node events, LLM events, show-state events, and the terminal pause/end/error event.

is_waiting_for_inputboolean required

True when the workflow paused and is waiting for user input in the next POST request.

is_completedboolean required

True when the workflow has reached a terminal state (completed, failed, cancelled, or aborted).

errorstring nullable

Present when status is FAILED. Human-readable error message.

next_input_hintobject nullable

Serialised BusyWaitForUserMessageEvent payload when is_waiting_for_input=True. Describes what the workflow expects as input in the next turn.

has_active_companionsboolean

True when fork-companion threads are still running background work (e.g. a polling self-loop) after this turn. A scheduler/client can call the pump-companions endpoint on an interval to advance them while the main thread waits for the next user input.

has_background_workboolean

True when ANY background work remains after this turn: an active fork companion, or a parked thread with an armed conditional-edge evaluation (see EvaluateWhileWaitingConfig). This is the flag a scheduler/client should poll the pump-companions endpoint on — it is a superset of has_active_companions, which is retained for backward compatibility. Note that a pump may now return MAIN-thread assistant output, when a waiting condition matched and the workflow advanced without a user turn.