> ## Documentation Index
> Fetch the complete documentation index at: https://docs.2501.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing a Behavior

> Verify a new specialty, rule, or MCP before rolling it out to production

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. Plan mode

An agent in **Plan** only reads, and each change it needs waits in a plan for your approval. Add `@2501:plan` to a ticket to put all the agents of its job in Plan, or override the specialty with Plan. While a task only reads, the secondary engine checks commands for changes to the system.

Use this for a **plan-then-apply** flow:

1. Add `@2501:plan` to the ticket.
2. Read the plan that 2501 posts: what it found, each change it needs, and the constraints it cited from operational rules.
3. Tweak the prompt or rules if needed, or ask for a change to the plan with a `@2501` comment.
4. Approve the plan with `@2501:approve-plan` once confident. 2501 starts only the steps of the plan.

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](https://docs.2501.ai/0.20/benchmark/overview.md) reports three results per run:

| Result | Question |
| - | - |
| **Pass / Fail** | Did the run meet every required rule - typically a check of the machine's final state plus the policies the agent must respect? |
| **Compliance** | How many of your rules passed, required and optional - did the agent follow your process? |
| **Remediation** | Did the job resolve as `success`? |

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

| Situation | Use |
| - | - |
| Small specialty edit, trivial change | Individual task |
| New procedural operational rule | Plan mode + 1-2 individual tasks |
| New specialty for a critical domain | All three - task → plan → benchmark |
| Production rollout of a new ticket typology | Benchmark with multiple iterations before going live |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.