Work Items
A Work Item is a free-text instruction like “set the priority of every open request based on its description”, handed to an operator agent. The operator reads whatever its permissions allow, decides what should change, and closes in exactly one of two ways: one plan changeset that a human reviews and approves before anything is written, or a finding explaining why nothing needs to change (or why it could not proceed). It is the inbox for ad-hoc AI work: every instruction gets a first-class record with a live status, an audit trail, and a governed write path.
When you’d use it
- Ad-hoc bulk work: “review these records and fix X” without authoring a rule, workflow, or judgment first.
- One-off cleanups: re-prioritize, re-categorize, or annotate a set of records from a single sentence.
- Exploration with teeth: let the AI investigate AND propose the fix — but keep the apply behind your approval.
If the same instruction recurs, graduate it: a judgment for per-record evaluation, a standing goal for continuous reconciliation, or a business rule the crystallizer may already have drafted for you.
The operator autonomy mode
Work items dispatch only to agents with autonomy_mode: operator. An operator gets the investigator’s free loop (no forced tool calls, a generous iteration budget) over a read-only tool surface. Direct write tools are stripped at run time, not approval-gated, so the only way an operator changes anything is its emit_plan changeset — which rides the same plan review, approval-policy, and step-kind allow-list governance as every other plan. output_config on an operator carries only allowed_step_kinds, the fence on what its plans may contain.
If the run exhausts its budget before planning, the platform forces a finding — an honest partial answer, never a half-baked plan.
What you manage
Work items live at AI → Work Items (/admin/work-items): submit an instruction against an operator agent, watch its live status, read the finding, and review/approve the proposed changeset in place. The live status is derived from the linked run and plan:
| Status | Meaning |
|---|---|
running | the operator is reading and deciding |
awaiting_approval | a plan changeset is proposed — review it |
executing | approved; the platform is applying the steps |
completed | applied, or closed with a finding (nothing to change) |
rejected / failed / cancelled | the reviewer declined, the run failed honestly, or you cancelled |
Over chat or MCP the same surface is two tools: submit_work_item (confirm-gated) and get_work_item (read-only poll).
Permissions
Viewing the inbox needs platform.workitems.read; submitting and cancelling need platform.workitems.write. What the operator can read is its own service account’s RBAC — a work item over a table the agent cannot read closes with a finding saying exactly that. Approving the changeset is the reviewer’s authority, checked at approval time.