Skip to main content
Operational Rules are directives that guide how agents execute tasks. Instead of injecting every rule into every agent, 2501 matches rules to each task based on what the task does and which host it targets. This keeps rules relevant, avoids noise, and lets you scope a guardrail precisely. Example: A rule like “Always restart a service on the Linux web servers after editing its configuration” only surfaces on tasks that touch a Linux web server, rather than appearing for every agent in the organization.
Rules have no tags, and a host’s technologies, applications and tags play no part in which rules reach a task. What a rule says decides where it applies.

​
How matching works

Each rule is judged against the task by its name and description, and reaches the agent when it applies. A rule’s scope is what it says: name the systems, hosts and actions it covers.

​
Rules surface up front

For remediation tasks, the organization’s relevant rules and procedures are surfaced at the start of the task, ranked by relevance to the task description. The agent has the applicable guardrails in hand from the beginning rather than only when its intent happens to match exactly.

​
Managing Operational Rules

Go to Command Center → Operational Rules and click Create Rule to add a new entry. Open a rule from the list to edit it, or use the delete action on its row to remove it. Rules extracted from a Knowledge document show Imported from knowledge on their detail page, including the source section when available. Click View import to open the source document’s Knowledge page. This link is available when you have permission to read Knowledge.
Operational rule editor with version selector and Save Changes

Edit the rule's name and description, then save changes; earlier versions remain available in the version selector.

​
Name

A clear identifier for the rule. Example: Restart services after config changes

​
Description

The directive itself, the guidance an agent should follow when the rule applies. Write rules that are concise, specific, and focused on a single operational concern.
Overly strict or conflicting rules can prevent agents from completing tasks. Test new rules carefully before rolling them out broadly.
Example: Always restart processes after updating their configuration files

​
Scope: organization or tenant

By default, a rule is scoped to the current organization. Pick Scoped to Tenant in the Scope selector to make the rule available to all organizations. Selecting the tenant scope requires tenant-level access; without it the selector stays on Scoped to Organization.

​
Inspecting matches

Each task’s detail page shows a matching trace: which operational rules were applied to the task and which were skipped. Use this to confirm a rule is reaching the tasks you expect and to debug rules that are too broad or too narrow.

​
Best practices

Be specific in the text. Name the technologies, hosts and actions each rule actually applies to, so it surfaces only for the relevant hosts and actions. A rule left broad applies everywhere it can match, which adds noise and risks an irrelevant rule getting in the agent’s way. Keep rules outcome-focused rather than command-specific where you can, and review rule effectiveness regularly using the matching trace. Use Blacklist to hard-block prohibited commands, and Operational Rules to guide behavior. Combine with Specialties for domain workflows.