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.

Browse and inspect

The view lists every agent as a card, grouped into collapsible categories (research, audit, engineering, writing, pipelines, and so on). Each card shows the agent's name, a short description, and a model pill — which Claude 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.

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 moves its file to the system trash, so a mistaken delete is recoverable.

When agents run — the three surfaces

The same roster is used three 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.

Where to go next

• The agent roster — the full catalog, agent by agent
• Skills — reusable procedures agents invoke
• The operator model — competence comes from files, not memory