Skip to main content
Whenever you change a specialty, add an operational rule, or attach a new MCP, you want to know the change is better - not worse. Three layers, from quickest to most rigorous.

1. Individual task

You don’t have to wait for a real ticket. Create a new specialty, attach it to an agent, and send a task directly:
“Add 4GB of RAM on the machine SNDX-EUW3-DOCKER”
Read the commands the agent ran, how it handled unexpected problems, and how it reached a resolution. Compare against an agent using the previous specialty. Quick, cheap, and surfaces obvious regressions immediately.

2. Read-only / investigate mode

By default, agents run in remediate mode. Adding @2501:investigate to a ticket keeps its tasks read-only. An investigate-only specialty also defaults to read-only, but a @2501:remediate ticket tag overrides that setting for the job. While a task is in investigate mode, the secondary engine checks commands for changes to the system. Use this for a plan-then-apply flow:
  1. Tag the task @2501:investigate.
  2. Ask: “Craft me a plan of actions to resolve this issue.”
  3. Read the agent’s plan, its inspections, the constraints it cited from operational rules.
  4. Tweak the prompt or rules if needed.
  5. Re-run as a remediation task once confident.
This is the safest way to introduce a new behavior to a critical system.

3. Benchmarking

The most rigorous path: stage a realistic incident on a test machine you can afford to break, then run the agent against it many times and grade every run. Benchmark reports three results per run: An agent can fix a problem the wrong way, or follow every rule and still leave the system broken. Grading the machine itself, and the agent’s behavior separately, catches both. The Benchmarks page in Command Center surfaces pass rate, compliance, and trends over time, so you can see whether your latest specialty edit improved things or regressed.

When to use which