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

# Scoping Agents

> Why focused agents beat general-purpose ones — and how to scope them

A general-purpose "do-anything infrastructure agent" is too broad. Such an agent will solve a disk-full ticket, but it might solve it by **increasing the disk size by 500%** — quick, technically correct, no problem for a while. That's not the answer you want.

A specialized agent — properly scoped — knows the right way: logrotate first, compress, identify what's actually writing logs, propose extension only when appropriate.

## Scoping is security too

For AIOps on critical infrastructure, it is **always worth** reviewing specialties, operational rules, and task histories regularly. Two hours spent tightening a specialty can save 50 hours of post-hoc cleanup the next time that ticket type recurs.

## Three knobs to scope with

| Knob                                                     | What it controls                                      | When to tune                                           |
| -------------------------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------ |
| [**Specialty**](/0.8/prompting/specialty)                | How the agent thinks about a domain                   | Whenever the agent enters a new tech vertical          |
| [**Operational Rules**](/0.8/prompting/operational-rule) | Hard constraints + procedures specific to your env    | When you discover a "we always do it this way" pattern |
| [**Gateway prompt**](/0.8/prompting/gateway)             | Which agent gets which ticket, and how tasks sequence | When tickets cross multiple hosts or need a fixed flow |

## Worked patterns

### Many disk-full tickets

* **Specialty: Disk Manager (Linux)** — knows about logrotate, compress, mount points, when extension is safe vs not.
* **Specialty: Disk Manager (Windows)** — separate from Linux to keep command syntax sharp.
* **Operational Rule** — log rotation policy + maximum disk extension allowed in your env.

Why split Linux and Windows: each gets the right commands, fewer "this command doesn't exist on Windows" moments.

### Reverse proxy changes (HAProxy, nginx, Traefik)

* **Specialty: Reverse Proxy** — covers redirections, SSL, ACLs for technologies with similar config syntax.
* As scope grows complex, **split**:
  * Specialty: SSL Certificate Manager
  * Specialty: ACL & Routing Manager

Splitting at the first sign of bloat keeps each specialty tight and easier to maintain.

## Anti-patterns

* **One specialty per ticket type.** Too narrow. Specialties should cover a *technology* or *domain*, not a single task.
* **One specialty for everything in a cloud.** Too broad. Split by service family (storage, compute, networking, identity).
* **Putting environment specifics in a specialty.** That's what Operational Rules are for.