Get Worker
Path parameters
Response
Successful Response
A supported chat platform.
Values align with integration_instances.type so a chat install's platform and its integration row stay in lockstep.
The kind of channel the agent lives in — its standing mission.
Drives the swappable mode block in the system prompt (and, later, the toolset). escalation and others land as localized drop-ins (their standing block + tooling) when that work begins.
incident and alerts each state a mission the worker owns whatever the operator writes. custom states none: it supplies only the conduct floor the identity block forward-references, and the operator's custom_instruction is what gives the worker something to do. A channel that is neither working an incident nor triaging alert fires gets this one rather than being told it is in an incident (PRD-3766). The value is what customer-facing surfaces render, so it reads as the operator's own word for it rather than as an internal category.
A member's name is persisted, in resident_agent_workflow.mode and resident_agent_template.mode — plain varchars with no DB-side value set — and read back through this enum, so adding a member is one deploy but removing or renaming one orphans every row holding it. It also makes a member forward-only: code that predates it raises on a row that carries it, rather than degrading. So a new member wants its read deployed everywhere before anything can write it — either landing the member ahead of the paths that create it, or gating creation while it rolls out.
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.