Assign an AI agent to a workflow run when you start it. If a step fails mid-change, the supervisor diagnoses the hurdle, researches the vendor documentation, patches that run — never the definition — and resumes it from where it stopped, so a change window ends in a completed change instead of a reschedule.
It's 11:40 p.m. in a scheduled change window. The workflow you rehearsed and got approved is a quarter of the way through, and a step goes red. The pair reports something you weren't expecting, the script that has run fine forty times stops, and everyone on the bridge is looking at the one person who is supposed to know what to do — who is, right now, a deer in headlights. Fixing a script by hand at midnight, on production, with the clock running, is how changes get rescheduled and windows get lost.
A Run Supervisor is the engineer who isn't frozen. It is an AI agent you assign to a workflow run when you start it. It does nothing unless a step fails. When one does, it reads the devices, researches the vendor documentation, proposes the smallest patch that lets the change complete — a corrected parameter, a missing prerequisite step, a documented recovery — applies it to that run (never to the workflow definition), and the run picks up where it stopped. The change completes in‑window. What it learned can be saved as a draft for the next time.
Assigned per run, not per workflow. The supervisor is a choice in the Run dialog. A run with no supervisor behaves exactly as it always has — it fails, and a person retries or fixes by hand. Nothing watches a run you didn't ask it to.
The agent's autonomy setting decides how much it may do on its own — see Governance below.
Normally a failed step ends the run as failed. With a supervisor assigned, the executor hands the run to the agent instead, and every stage appears as rows on the run page:
knowledge_search narrowed to the device family, then vendor_doc_fetch on the best result). See Dynamic Agent Workflows — Research on the fly.| Patch | What it does |
|---|---|
| retry | Re‑run the failed step, optionally with corrected configuration — a fixed parameter, a longer timeout, a corrected script in the same config key the step uses. |
| insert_before | Run one or more real catalogue steps first (a missing prerequisite), then the failed step again, then continue. |
| replace | Replace the failed step with one or more catalogue steps, then continue. |
| skip | Skip the failed step — only when it is verifiably unnecessary, and it must say why. |
| ask | A question for you, when the decision is genuinely yours (a target, a window, a go/no‑go). The run pauses until you answer. |
| abort | Stop, because continuing would be unsafe. The run fails with the diagnosis attached. |
Inserted steps are always governed catalogue steps (f5.*, netscaler.*, palo.*, …) with the same configuration keys the failed step uses — never free‑form device commands. The supervisor may not insert a reboot, failover or reload to work around a failure.
3. Govern. Depending on the agent's autonomy, the patch is applied automatically or the run pauses with the proposal and an Apply patch and resume button.
4. Resume. The patched run continues from the patched node — the inserted step runs, the failed step re‑runs, and the rest of the workflow proceeds exactly as designed. Nothing that already succeeded is repeated.
max_interventions in the agent's Advanced config), per run (the Max interventions this run box that appears in the Run dialog once a supervisor is chosen), or platform-wide with the SUPERVISOR_MAX_INTERVENTIONS environment variable. Each intervention's own probe budget is the agent's Max steps, capped at 14 unless max_intervention_steps (Advanced config) or SUPERVISOR_MAX_INTERVENTION_STEPS raises the cap (ceiling 40). The run page shows n of N interventions.A static change‑window workflow on the bigip1 / bigip2 pair: pre‑change gate — config In Sync on both units → save UCS on both → confirm Active/Standby → snapshot VS & pool health. The run was started with the Change Window Supervisor agent (read + knowledge tools, propose + approve).
The gate failed at once: the pair reported Changes Pending — a configuration change on the active unit had never been synced. Without a supervisor, that is the deer‑in‑headlights moment. With one:
tmsh show cm sync-status on the device (TMOS itself said: Recommended action: Synchronize bigip2 to group ha), then researched the condition in F5's Managing Configuration Synchronization guide ("If the sync status is yellow (Changes Pending)… you must ensure that a config sync operation occurs for the relevant device group.").f5.save_sync targeted at the active unit. Rationale, in its own words: "bigip2 (ACTIVE) holds the latest configuration and shows 'Changes Pending'. F5 vendor documentation and the device's own recommended action both direct a sync from bigip2 to the HA device group… No reboot, failover, or operator decision is required."From the failure to the proposal took about a minute; from the failure to a completed change, about four (most of it the backups). The person on the bridge clicked once.
The supervisor is bounded by its tools, its research and its budget, and it is instructed to prefer stopping over guessing. If it produces no usable patch, answers abort, or exhausts its interventions, the run fails exactly as an unsupervised run would — with the full diagnosis attached, which is usually most of the work a person would have had to do at midnight anyway.