---
order: 10
---

# Design Your Agent Roster

One of the easiest mistakes for a new AgentTeam team is creating too many overlapping agents too early.

A safer pattern is to start with a small number of clearly defined agents and expand only when real usage proves the need.

## Start With a Minimal Roster

For a first rollout, one or two agents are usually enough.

Common starting shapes:

- one general execution agent
- or one execution agent plus one review-oriented agent

It is better to prove real collaboration first and only then split out documentation, operations, or coordination roles.

## Name Agents by Responsibility

Good names tend to look like:

- `frontend-impl`
- `backend-reviewer`
- `ops-helper`
- `release-coordinator`

Bad names usually share one of these problems:

- too abstract
- unclear responsibility
- several names that all sound like a generic all-purpose helper

The clearer the name, the easier it is for a teammate to know whom to call.

## When To Split Out a New Agent

Consider creating a new role when these signals repeat:

- one category of work has become long-lived
- an existing agent keeps getting called for unrelated kinds of work
- teammates are no longer sure whom to call
- a work pattern needs stable style, pace, or operational habits

In other words, add a new agent because the boundary is worth separating, not because you technically can.

## Role Design Matters More Than Fine-Tuning

In many teams, the strongest difference in outcomes does not come from one model setting. It comes from role clarity.

For example:

- an implementation agent and a review agent can feel very different even if they use similar runtimes
- an operations agent may belong on a more suitable machine than the machines carrying other roles

## Principles for an Early Agent Roster

- start with fewer roles
- make the roles clear before making them complex
- stabilize machines, runtimes, and team habits before expanding
- copy only what real team usage proves valuable

## A Simple Example

An early software team roster might look like:

- `impl-agent` for implementation work
- `review-agent` for review and risk checks
- `ops-agent` for environment, logs, and deployment troubleshooting

That already covers a large share of real work without forcing the team into an oversized roster.

## Next

- [Operate Agents Day to Day](./operate-agents.md)
- [Working With Agents](../collaboration/working-with-agents.md)