> ## 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](https://mintcdn.com/2501/Nw-5R3i4HUHiTxUb/images/specialties_list.png?fit=max\&auto=format\&n=Nw-5R3i4HUHiTxUb\&q=85\&s=b856ff6288ecd613e4a98dc000b53ea9)

Specialties list: each row shows a specialty's name, its description, how many agents use it, its mode, its scope, and when it was created, with when it was last updated under the date. Click a row to open the specialty.

## Separation of Concerns

To maximize accuracy, use different tools for different purposes:

* **Specialties**: Define workflows, provide context, establish best practices
* **[Operational Rules](https://docs.2501.ai/0.20/configure/operational-rules.md)**: Enforce specific tool usage or behavioral requirements
* **[Blacklist](https://docs.2501.ai/0.20/configure/blacklist.md)**: 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.

### Description

Context about the specialty's purpose and scope. Agents read the full description - not just the name - when deciding how to plan and assign tasks, so a clear description improves routing accuracy for specialties where the name alone is ambiguous.

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 Organization**, so only that org's agents can use it. Pick **Scoped to Tenant** in the **Scope** selector to make it available to all organizations. Selecting the tenant scope requires tenant-level access; without it the selector stays on **Scoped to Organization**.

### Execution Mode

A specialty follows the [execution mode](https://docs.2501.ai/0.20/core-concepts/agents.md#execution-modes-plan-and-auto) of its organization. To give its agents their own mode, an Admin selects **Plan** or **Auto** instead of **Inherit organization**. A specialty in Plan or Auto keeps its mode when the organization changes mode.

An agent in Plan only reads, and each change it needs waits in a plan until a person approves it. This is useful for safely deploying large fleets of agents (e.g., 1000 Oracle DB agents) where you want read-only analysis by default, and a person's approval before any change. A specialty overridden with Plan keeps it when the mode of the organization changes.

Only an Admin changes the mode: a User who can edit the specialty sees its mode but cannot change it. A ticket can still force Auto on all the agents of one job with `@2501:auto`, when an Admin allows it for the organization. In the v1 API, the override Plan is `investigate_only`, the override Auto is `auto`, and `null` follows the organization.

### 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](https://docs.2501.ai/0.20/configure/prompting.md).

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


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