Agents

An agent in Command Center is not a compiled component — it is a Markdown file in .claude/agents/ you can open, read, and change. The Agents view is the in-app surface for that folder: browse the roster, inspect any agent's contract, edit it in place, clone it, or write a new one. Changes take effect on the agent's next run — no restart, no rebuild.

Open it from the sidebar, in the Agents section: Agents.

Agents is a Pro surface — see Tiers: Pro & Ultra. Without an active subscription the view still appears in the sidebar and renders a lock instead of the roster.

Browse and inspect

The view lists the roster — 48 definition files — as cards, grouped into collapsible categories that match how the roster is actually used:

Each card shows the agent's name, a short description, and a model pill — which model it runs on.

Select an agent to open it:

• A frontmatter panel shows the agent's contract at a glance — its name, description, tool access, model, and any pre-attached skills.
• The body opens in an editor with a rendered/raw toggle. The body is the agent's entire method, in plain language: why it exists, how it works, what it returns, and its rules.

This is the fastest way to answer "what will this agent actually do?" — read it. There is no hidden behavior beyond the file.

Understand the contract

Four frontmatter fields do most of the work:

• description — when to use this agent. This is what dispatch matches on, so it doubles as the agent's job advertisement.
• tools — an exclusive allowlist: the agent may use exactly what is listed, nothing else. Omit the line entirely and the agent inherits all tools. Tighten it to scope an agent down; if you remove the line's shared-memory entries, the agent loses access to shared memory.
• model — the cost/quality dial, one word. Judgment-heavy agents (auditors, researchers, planners) run the stronger model; mechanical workers run the cheaper one. Editing this single word retunes an agent's economics.
• skills — skills the agent can invoke during its work.

An agent file names a model, not an engine. Which agent CLI executes the run is decided at the surface that launches it — a terminal pane, a routine, a pipeline stage — and is covered under choosing an agent engine. The file's job is to say how much thinking the work deserves.

One formatting rule worth knowing before you edit: the frontmatter is strict YAML, and a colon followed by a space inside a description value breaks parsing. Write — (a dash) instead of : in descriptions.

Two special files in the same folder are fleet role files — the mission commander and mission worker definitions. They are not dispatched like other agents; they are injected into fleet terminal panes as the session's operating posture. Edit them to change how your fleets behave — same file format, same hot-reload.

Edit an agent

1. Select the agent and switch the editor to edit mode.
2. Change what you need — tighten a rule, adjust the return format, swap the model, extend the tool list.
3. Save. The change is live the next time the agent spawns. Agents are read fresh at every run, so there is nothing to restart.

Because edits are this cheap, the productive habit is iterative: run an agent, judge the output, adjust its file, run again.

Create or clone an agent

The fastest path to a custom specialist is cloning: the shipped roster is a set of proven templates, and the create dialog can prefill from an existing agent.

1. Click New agent (or Clone on an existing one).
2. Set the name and description, pick the model, and scope the tool list.
3. Write the body: why the agent exists, its workflow as numbered steps, the exact return format, and its rules. The strongest agents are boringly explicit.
4. Save. The agent is registered by existing — it is dispatchable immediately.

Deleting an agent is permanent. The confirmation dialog says so, and it means it: the file is removed from disk, not moved to the system trash, and there is no undo inside Command Center. Two habits cover you — clone before you experiment, so the original survives whatever you do to the copy, and keep your workspace under version control, which is the only real recovery path for a deleted agent. (Skills behave differently: deleting there is recoverable. Do not carry the assumption across.)

When agents run

The same roster is used four ways, and choosing between them is the main orchestration decision:

Dispatched agents are cheap and parallel — fan out several at once for research or audits. Fleet sessions are full persistent sessions and cost accordingly; never stand one up for what a single dispatched agent returns in one burst.

How far any of these may reach without asking you — and which switch stops each outward action — is the subject of Autonomy and controls.

Where to go next

• The agent roster — the full catalog, agent by agent
• Skills — reusable procedures agents invoke
• Autonomy and controls — what a dispatched agent may do unattended
• The operator model — competence comes from files, not memory