Skip to main content
Specialties let you specialize agents for specific tasks. Every agent needs a specialty to run—if you don’t select one during initialization, it defaults to SYSOPS.

​
Purpose of Specialties

While 2501 agents are built for autonomous system operations, specialization improves execution accuracy and reliability. Instead of operating generically, specialized agents follow domain-specific guidelines tailored to your infrastructure. Example: An agent with an AWS CLI specialty can manage EC2 instances with specific guidance on CLI usage patterns, error handling, and decision-making logic (like determining appropriate CPU upgrades when asked to “upgrade my sandbox machine”). Specialties work well for:
  • Providing context for proprietary or lesser-known tools
  • Establishing workflows without full MCP integrations
  • Documenting internal conventions and procedures
Specialities

​
Separation of Concerns

To maximize accuracy, use different tools for different purposes:
  • Specialties: Define workflows, provide context, establish best practices
  • Operational Rules: Enforce specific tool usage or behavioral requirements
  • Blacklist: Prevent execution of prohibited commands

​
Managing Specialties

Go to Command Center → Specialties and click Create Specialty to add a new one.

​
Name

The display name for your specialty. Use naming conventions that reflect the service domain or agent role. Example: TERRAFORM_SPECIALIST

​
Key

A read-only identifier automatically generated from the name. Use this key in CLI commands to assign specialties during agent initialization.

​
Description

Optional context about the specialty’s purpose and scope. Example: Handles Terraform infrastructure files for sandbox environments

​
Organization

By default, specialties are available to all organizations. Select a specific organization to restrict usage to only that org’s agents.

​
Investigate-Only Mode

A specialty can be pinned to investigate-only, meaning any agent using it will always run in read-only mode regardless of what the ticket or gateway requests. This acts as a ceiling — even if a ticket is tagged @2501:remediate, agents with an investigate-only specialty will only diagnose and report. This is useful for safely deploying large fleets of agents (e.g., 1000 Oracle DB agents) where you want read-only analysis by default. You can then selectively enable remediation for specific groups by changing this single setting on the specialty. When a ticket requested remediation but investigate-only specialties prevented it, the job resolution is flagged as partial rather than a failure. See Agents — Investigate vs Remediate for the full priority chain.

​
Prompt

The specialty definition itself. Use structured formats like Markdown or XML for clarity. Important: Changes to a specialty immediately affect all agents using it. To test modifications safely, create a new specialty for testing, assign it to a test agent, validate the behavior, then update the production specialty. For guidance on effective agent prompting, refer to our Prompting Guide.

​
Best Practices

Keep specialty prompts focused and domain-specific. Document expected behaviors and decision criteria with clear examples for complex workflows. Test specialty changes on isolated agents before rolling them out to production. For critical systems, consider version-controlling your specialty definitions.