Operational Rules

Operational Rules guide how jobs and agents do their work. Rules are selected by relevance unless Always inject is enabled. Example: Without Always inject, 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.

​

Always inject

Use Always inject sparingly, mainly for security rules such as requiring approval before changing production systems. Keep them few and concise: their full text occupies the agent’s context on every request. Leave task-specific procedures on relevance-based selection. Enable Always inject to include the current rule text in every Job and Task LLM request, including action verification. It bypasses relevance scoring and per-agent exclusions within its organization or tenant. Rule-scoring requests are excluded. Edits apply on the next request, including in running tasks. If the rules cannot load, the request stops. Always inject ensures delivery, not model compliance. Gateway intake before a job exists uses its configured inbound prompt. New organizations start without prefilled rules.

​

How matching works

Rules without Always inject are judged against the task by name and description, and reach the agent when they apply. 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 or delete 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. The list shows each rule’s name, description, Always inject setting, scope and creation date. Click a row to open its rule. On the rule page, edit its name, description, content and Always inject setting, then select Save Changes, or delete the rule. To apply an earlier version, select it in the version selector and choose Restore Version.

​

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

The task’s matching trace shows relevance-based selection. It does not track each delivery of always-injected rules.

​

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.