Skip to main content
A run is one execution of a coworker. These three tools are how you test a coworker without first inventing a routine for it, and how you find out why the answer was not what you expected.

send_message

Talks to a coworker and waits for its answer.
string
required
string
required
string
Continue an earlier conversation. Omit to start a new one.
number
How long to wait for the answer. Default 120, maximum 600.
If the coworker is still working when the wait runs out, the call returns status: "running" with a runId, a note, and the run carries on in the background. Poll get_run for the result.
Response
A coworker can pause mid-run to ask you something or request an approval. When that happens the run finishes with the question waiting in the app, and output carries the coworker last message. See Human in the loop.

list_runs

Recent executions of a coworker, newest first.
string
required
number
Default 20, maximum 200.
Each run carries the same fields as the response above, without output. Use it to see whether a scheduled task or a webhook actually did anything. The trigger field tells you where the run came from: chat, api, schedule:<slug> or trigger:<slug>.

get_run

One execution: its status, output, error, token usage and cost.
string
required
string
required
boolean
Also return every tool the coworker called, with its input and its result. Each input and result keeps its first 2,000 characters; a longer one ends with … [truncated] N more chars elided to save context, and the full payload is not available over the API.
Response with includeToolCalls
Run statuses are running, done, error and cancelled. costUsd is the model cost of that run, and is null while it is still running.