Skip to main content
The Runs API orchestrates multi-agent workflows through the WattSwarm run queue. A run groups multiple agent steps (each backed by an executor) that all operate on the same shared inputs. Once a run finishes, the kernel aggregates the individual results — resolving ties and null outputs according to the configured policy — and produces a single final_decision. Runs are the recommended way to leverage multiple independent agents for higher-confidence swarm decisions.

POST /api/run/submit

Submits a RunSubmitSpec and registers the run in the queue. By default the run starts in CREATED state; pass "kickoff": true in the envelope form to also transition all steps to QUEUED immediately.
The endpoint accepts the spec either as a bare RunSubmitSpec object or wrapped in an envelope:
string
required
Stable identifier for this run. Use a UUID or a deterministic slug.
string
Task type string passed to each executor step. Defaults to "generic.v1".
object
JSON inputs shared across all agent steps in the run.
object[]
required
List of agent step specifications.
object
Retry policy applied to failed steps.
object
Controls how individual step results are combined into a final decision.
Complete RunSubmitSpec example:
Example request:
Example response:

POST /api/run/kickoff/:run_id

Transitions the run and all its constituent steps from CREATED to QUEUED, making them eligible for executor pickup. Call this after /api/run/submit if you did not pass "kickoff": true at submit time, or if you want to delay execution start.
Path parameters:
string
required
The run identifier returned by /api/run/submit.
Example request:
Example response:

GET /api/run/watch/:run_id

Polls the current status of a run, including step-level counts broken down by state. Call this endpoint periodically until status reaches SUCCEEDED, FAILED, or CANCELLED.
Path parameters:
string
required
The run identifier.
Example request:
Example response:
Response fields:
string
The run identifier.
string
Overall run status: CREATED, QUEUED, LEASED, SUCCEEDED, FAILED, or CANCELLED.
object
Step-level counts by state. remote_dispatched tracks steps sent to remote nodes awaiting gossip results.

GET /api/run/result/:run_id

Returns the aggregated final result of a completed run, including the final decision, final answer, and per-step conclusions.
Path parameters:
string
required
The run identifier.
Example request:
Example response:
string | null
The aggregated decision value. null if the run did not produce a conclusive result.
string | null
The long-form answer string, if the executor returned one.
object[]
Per-step outcome details including conclusion, confidence, and attempt number.
string[]
List of resolution strategies that were applied (e.g. "quorum_match", "confidence_weighted", "stochastic").

GET /api/run/events/:run_id

Returns the structured event log for a run. Useful for debugging step transitions, retries, and aggregation decisions.
Path parameters:
string
required
The run identifier.
Query parameters:
integer
Maximum number of events to return. Defaults to 50; minimum 1.
Example request:
Example response:

POST /api/run/cancel/:run_id

Cancels an active run. Any steps in QUEUED or CREATED state are moved to CANCELLED. Steps currently leased are allowed to finish but their results are discarded.
Path parameters:
string
required
The run identifier.
Example request:
Example response:

POST /api/run/retry/:run_id

Retries a failed run by re-queuing its failed steps from the beginning. Steps that already succeeded are not re-executed.
Path parameters:
string
required
The run identifier.
Example request:
Example response:

POST /api/knowledge/export

Exports a knowledge bundle from the kernel store. A knowledge bundle contains the decision records, evidence references, and reuse metrics accumulated for a given task type or specific task ID. Provide exactly one of task_type or task_id.
string
Export all knowledge records associated with this task type string (e.g. "generic.qa.v1"). Mutually exclusive with task_id.
string
Export knowledge records for a single specific task. Mutually exclusive with task_type.
Example request:
Example response:
Knowledge bundles are useful for fine-tuning prompts, auditing swarm consensus quality, and bootstrapping new nodes with historical decision context.