What is an Agent?
A 2501 agent is an AI-powered operator capable of understanding context by analyzing tasks and interpreting system states, planning execution by breaking down complex operations into logical steps, taking action through commands and file modifications, adapting dynamically based on outputs and errors, and operating autonomously to complete multi-step tasks without constant intervention. Unlike traditional automation scripts, agents reason about their environment and make informed decisions rather than following rigid procedural logic. The Agents list shows each agent’s Host or Central and its plugins under its name. The first plugin appears by name, with a count of additional plugins. Hover to see them all. The list also shows the status, specialty, main and secondary engines, and creation and update dates. Filter the list by the Hosts’ technologies, applications or tags. Click a row to open the agent.Agent Architecture
Engine Pair
Every agent uses two LLMs in tandem:- Main Engine: Handles direct task execution, file manipulation, and command execution
- Secondary Engine: Checks the work - validating each proposed action against the host’s rules and the incident, and reviewing interactive commands
Specialty Configuration
Agents are assigned a Specialty that provides domain-specific guidance and workflows, ranging from general-purpose (SYSOPS) to highly specialized configurations like TERRAFORM_SPECIALIST or AWS_CLI_EXPERT.
Operational Constraints
Agents operate within boundaries defined by Operational Rules (organization-wide mandatory procedures), Blacklists (prohibited commands), and Credentials (secure access to systems).Credential Access Control
Each agent has an explicit credential allowlist - a list of credentials it may reference by name during task execution. Configure the list from the agent create or edit form. Only credentials on the allowlist are advertised to the agent; secret values are never exposed. Named credential placeholders in commands (e.g.{{secret:my-api-key}}) resolve only when the referenced credential appears on the agent’s allowlist. An empty allowlist means no named credentials are available to the agent.
Memory and Context
Agents maintain task history within their context window, allowing them to reference previous operations, build on prior work, and maintain continuity across related tasks. When context limits are approached, tasks can be archived to clear memory while preserving agent configuration.Execution Modes: Plan and Auto
An execution mode decides if a person approves the changes of an agent before 2501 makes them. Each agent is in one of two modes:- Auto: The agent diagnoses issues and applies fixes without approval: commands, file changes, service restarts, etc. Operational rules, blacklists and access restrictions still apply.
- Plan: The agent only reads. Its tasks diagnose and report, and every command that would change the system is blocked. When a change is needed, the job posts a plan of the changes, and 2501 makes them only after a person approves it.
The mode of a task depends on the mode of the job and the mode of its agent:
If several mode commands appear in the description and comments, the last one that counts wins, and a later comment without one does not clear it.
@2501:auto counts only when an Admin allows it for the organization. Otherwise 2501 says so in the ticket and ignores the command. The commands of earlier versions still work: @2501:investigate is @2501:plan, and @2501:remediate is @2501:auto. A new mode takes effect at the next task boundary: the running task keeps its mode, including after recovery, and pending tasks are canceled and replanned.
A job stops after its first turn that reads through an agent in Plan. When a change is still needed, the job posts a plan with every change that is left, in the ticket and on the job page, and waits. A person approves it with @2501:approve-plan or Approve plan, or asks for changes with a @2501 comment or Request changes. See Jobs: Plans.
The mode belongs to the agent, not to the host: a host with an agent in Plan and an agent in Auto can change through the agent in Auto. To protect a host, give all of its agents a specialty in Plan.
A task that you create outside a job takes the mode of its agent. The New Task form shows that mode, and whether the specialty or the organization sets it. To change it, change the mode of the specialty.
In the Command Center, a read-only task shows a Read-only badge, and a job whose mode was forced shows a Plan or Auto badge in the jobs list. In the v1 API, a read-only task has read_only: true, and keeps the deprecated execution_mode: "investigate".
Agent Lifecycle
Creation
Agents are created in Command Center or through the API. In Command Center, Agents > Create Agent opens a dedicated creation page. Assign a host, select main and secondary engines, choose a specialty, assign plugins, and configure connection credentials.
Configuration
After creation, select an agent from the inventory to open its detail page. From there you can change its identity and engine assignments, configure host authentication, control the credentials available during tasks, and assign plugins. The same page shows recent tasks with live statuses and provides task creation and archival actions.Task Execution
Agents receive tasks through natural language instructions. The main engine gathers context, plans the approach, and works through it one action at a time; the secondary engine checks each proposed action before it runs. The agent adapts as it learns from output, verifies its own change before reporting it done, and reports completion or escalates issues.Memory Management
As agents work, their context window fills with task history. Manage memory by archiving completed tasks individually or using Archive Tasks on the agent’s page to clear the agent’s task memory. Archive Tasks archives the finished tasks of finished jobs: the tasks of a job that is still running stay in memory until the job ends. An archived task leaves the agent’s memory and the task lists, but stays in its job’s plan and history.Modification and Deletion
Agents can be edited or removed in Command Center or through the API.
Agent Organization
Organization Scoping
Agents belong to specific organizations, with available specialties, operational rules, blacklisted commands, and accessible credentials. This scoping enables different teams or environments to maintain separate operational standards while sharing infrastructure.Agent Naming
Choose agent names that indicate purpose or responsibility (e.g.,aws-prod-manager, db-backup-agent), target environment (e.g., staging-deployer, prod-monitor), or specialty domain (e.g., terraform-provisioner, k8s-operator).