Skip to content

AI tasks

An agent run is a single pass: it fires on a trigger, does what it can, and finishes. An AI task is the other shape: a long-running job you hand off and walk away from. Start an AI task for a service-recovery incident and it keeps working through investigation, action and verification after you close the browser, waiting for your approval at the step that needs it.

An AI task is not a separate actor. It is handled by an agent, and when Wisp hands a job to a specialist, the result shows up as a run or an AI task that says who it was done for.

A recipe is a task template. The Library is where recipes live. Each recipe is an ordered list of steps and states which of them change anything. Starting an AI task means choosing a recipe and filling in what it needs.

With the feature on, a Start an AI task button appears on the device page and on alert detail. Choose it, name the service that needs recovering, confirm, and Breeze opens the task’s own page and starts work. Starting one needs ai_agents:write and a multi-factor confirmation, the same bar as moving an agent to Act mode.

The task page is the record of the whole hand-off: the task’s current state and phase, what it is waiting on if it is waiting, each operation it has performed, its final outcome, Handled by (the agent doing the work), and links to the underlying agent runs so you can read the detail of any single step. The device page also carries an AI Tasks feed so you can see task activity in the device’s own timeline.

Reading tasks needs ai_agents:read. A task belonging to an organization or site you cannot see is reported as not found rather than as forbidden, so the route never confirms that someone else’s task exists.

The one shipped recipe walks five ordered steps: investigate, execute, observe, verify, document. Only the execute step changes anything, and it is always supervised: the AI task raises a service-restart request into your existing Approvals page and waits there. There is no path in this recipe where an AI task restarts a service without a human approving it.

A service you have listed as a protected resource is refused at start time, before any request reaches Approvals, so a domain controller’s critical services can never become a pending approval someone might wave through.

Two background workers ship with the feature: a task coordinator that ticks every 15 seconds, and a publisher that drains task events every 5 seconds. Both are registered whether or not the flags are on, deliberately, so that a task already in flight when you turn the feature off still finishes cleanly rather than stranding an approval. With the flags off no new task is ever admitted, so neither worker has anything to do. No new queue is added.