> ## 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. # Specialties > Configure your agent for specific task domains 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 Specialties list ## Separation of Concerns To maximize accuracy, use different tools for different purposes: * **Specialties**: Define workflows, provide context, establish best practices * **[Operational Rules](/0.7/configure/operational-rules)**: Enforce specific tool usage or behavioral requirements * **[Blacklist](/0.7/configure/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` ### Scope A specialty is scoped to either a single organization or the whole tenant. By default it is **scoped to the current organization**, so only that org's agents can use it. Toggle the scope to **tenant** to make it available to all organizations. ### 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](/0.7/core-concepts/agents#execution-modes-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](/0.7/configure/prompting). ## 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.