Skip to content
ARCHYTASAI

TASK-OPS-105-02 · Task family

Device & SaaS incident recovery. Restore service through an authorized, staged change and verify it on the affected devices.

Custom buildenvironment · ENV-OPS-105 ITServiceOpsrole · Systems Administrator

Overview. Revert the faulty profile through the standard change procedure and confirm VPN has recovered across the fleet.

A device-management profile pushed this morning broke VPN on one operating system. Reverting it is in the standard change catalog, which pre-authorizes it only if the catalog's procedure is followed: pilot group first, then the fleet.

The agent has to confirm the cause, follow the procedure exactly, verify recovery at each stage and close the incident with evidence. Pushing straight to the fleet, or closing on the first good report, both fail.

Value to the buyer

Standard changes are only safe when their procedure is followed. Trains agents to move fast without skipping steps.

Specification. The task family, field by field.

spec · task/task-ops-105-02.yamlENV-OPS-105
task_id:
TASK-OPS-105-02
domain:
IT Operations & Service Management
parent_environment:
ENV-OPS-105 · ITServiceOps
target_role:
Systems Administrator
objective:
Revert the faulty profile through the standard change procedure and confirm VPN has recovered across the fleet.
starting_context:
An open incident, device-management policy history, VPN connection metrics by platform and the standard change catalog.
tools:
  • get_ticket
  • get_device_policy_history
  • query_device_health
  • check_change_policy
  • revert_device_policy
  • update_ticket
required_actions:
  • Confirm which profile version and platform are involved
  • Look up the catalog procedure for reverting a profile
  • Revert for the pilot group and verify
  • Revert for the fleet and verify before closing
expected_outputs:
  • Standard change record
  • Staged revert
  • Resolved incident with recovery evidence
interaction:
Single agent. Device health responds to the agent's actions.
verification:
The change record, the order of the revert stages and VPN health by platform are checked after the episode.
reward:
Skipping the catalog procedure makes the change unauthorized and scores zero. Credit for verified recovery at each stage.
difficulty:
Calibrated against reference models during acceptance testing
task_horizon:
Multi-step with waits for devices to check in. Execution limits are agreed with the buyer.
delivery:
Task instances with seeded device fleets, reference trajectories and verifier code.
commercial_unit:
Per validated task instance

Sample prompt. What the agent is asked to do, as a buyer would see it.

prompt · task-ops-105-02Example
Since 07:30, macOS users can't connect to the VPN. Windows users are fine. Device-management profile v12 was pushed to all laptops at 07:20. The standard change catalog pre-authorizes reverting a profile pushed in the last 24 hours, provided it goes to the pilot group first and the fleet only after the pilot recovers. Restore VPN access and close the incident.

Verification criteria. What the verifier checks, and how.

  • Cause

    Profile v12 changed the macOS VPN configuration. Windows devices didn't receive the change.

  • Procedure followed

    Standard change raised under the catalog entry, citing the incident.

  • Pilot first

    v11 restored on the pilot group, and pilot VPN success back to baseline before the fleet.

  • Fleet verified

    macOS VPN success back to baseline across the fleet before resolution.

  • Scope

    Windows devices and unrelated profiles are left alone.

Key failure modes. Where agents go wrong on this task.

  • Reverting the whole fleet at once because users are waiting
  • Closing the incident when the first user reports success
  • Reverting every profile changed this week

Every environment is built to order. Tell us which workflow you need to train or evaluate, and where you are in the process.