Sign in
latestOpenAPI 3.1.02026-08-223321,1001.6 MB

2134ebffd1ef

workers

Deploy Worker

Explicitly deploy a worker.

The body is discriminated on platform: a Slack deploy names the channel to bind to, a web deploy names the worker instead, because web mints its own handle and has no channel to pick. Slack is the default variant, so a body written before platform existed still parses.

State-changing, so it goes through the standard AuthorizedUserDep chain (authenticated + CSRF-validated). The organization comes from the authenticated user, never the request body, so a caller cannot deploy into another org's channel — and the deploying identity likewise comes from the session, so the announcement can't be attributed to someone else.

post/workers

Request body

OR

Response

Successful Response

idstring required
resource_idstring required
display_namestring required
platform'slack' | 'teams' | 'web' required

A supported chat platform.

Values align with integration_instances.type so a chat install's platform and its integration row stay in lockstep.

agent_typestring required
mode'incident' | 'alerts' required

The kind of channel the agent lives in — its standing mission.

Drives the swappable mode block in the system prompt (and, later, the toolset). incident and alerts have mode blocks today; escalation and others land as localized drop-ins (their standing block + tooling) when that work begins.

custom_instructionstring nullable
created_atstring date-time required
updated_atstring date-time required
stopped_atstring date-time nullable required
status'critical' | 'attention' | 'working' | 'stable' required

The worker's present-tense status top-line, shown as a pill on the /workers list. Only these agent-picked values are ever stored in the status column; a null column means none has been emitted yet (the UI renders that as starting), and the terminal stopped state is derived from stopped_at — neither is stored here, so there is no second source of truth.

The agent-facing definitions live on the status field in prompts.py (the only copy the model reads); keep this summary in sync with it.

Values: CRITICAL: Immediate coordinated response is warranted because user-facing impact is severe or escalating. ATTENTION: A specific person or team should act now, but immediate coordinated incident response is not warranted. STABLE: Resting floor — no specific person or team needs to act now and no coordinated incident response is warranted. WORKING: Legacy — no longer emittable, see EmittableWorkerStatus.

status_messagestring nullable required
status_updated_atstring date-time nullable required