# Roster and Slugs (/web/agents/roster-and-slugs)



The roster is where Mogplex stores reusable agent definitions.

Those definitions are then referenced by [Triggers](/web/triggers),
[Assignments](/web/assignments), and [Automations](/web/automations).

Think of the roster as the durable identity layer for agents, not just a place
to keep prompt snippets.

## What actually lives in the roster [#what-actually-lives-in-the-roster]

The current roster mixes a few different kinds of agent entries:

* **Default** preset agents that ship with Mogplex
* **Customized** forks of those presets
* fully **Custom** agents you create yourself

That distinction matters because the editor treats them differently:

* preset agents are reusable defaults
* presets can be customized without mutating the shipped version
* custom and customized agents can be edited or deleted directly

In practice, this gives you a safe path:

1. start from a preset if one is close
2. fork it when you need your own version
3. keep the fork as the repo or team-specific identity you actually route to

## What fields matter operationally [#what-fields-matter-operationally]

The fields that matter most in the current editor are:

* **Name** for humans scanning the roster
* **Description** for selection and search
* **Category** for grouping and navigation
* **Model** for capability, cost, and latency behavior
* **System prompt** for the durable behavior contract
* **Slug** for targeted GitHub mention routing

Slug is mostly routing metadata rather than the main thing you manage in the
roster editor day to day, but it still matters when GitHub mentions need to
resolve to a specific agent.

Two validation details are worth knowing:

* category is required when creating or saving an agent
* the editor only lets you pick from enabled models, even though older agents
  can still carry legacy model ids

## Presets, customizations, and legacy models [#presets-customizations-and-legacy-models]

The roster UI exposes a few badges that reflect real product state:

* **Default** means a preset with no fork yet
* **Has customization** means a preset already has a forked version
* **Custom** means a user-created agent
* **Customized** means a fork of a preset
* **Needs category** means the agent no longer maps cleanly to a current
  category
* **Legacy model** means the agent still points at a hidden or stale model id

Legacy models are especially important operationally.

Mogplex can still load an older agent that references a hidden model, but the
editor treats that as something you should replace rather than keep building on.

## Categories are not cosmetic [#categories-are-not-cosmetic]

Categories are part of how the roster stays usable once you have more than a
few agents.

The roster supports:

* built-in categories such as Next.js, Performance, API, Security, Frontend,
  and PR Review
* custom categories you create yourself
* search across names and descriptions
* a **Needs Category** bucket for custom agents that no longer map to a current
  category

Deleting a custom category does not delete the agents using it. Those agents
fall back into **Needs Category** so you can reassign them cleanly.

## Where slugs matter [#where-slugs-matter]

If you only remember one thing, remember this:

GitHub mention routing uses the agent slug, not the display name.

That means:

* `@mogplex` targets the default mention route
* `@mogplex/<slug>` targets a specific route by slug

Examples:

* `@mogplex/triage`
* `@mogplex/frontend-review`
* `@mogplex/ci-fixer`

## Triggers vs Automations [#triggers-vs-automations]

Slugs matter in both routing surfaces, but not in exactly the same way.

### Triggers [#triggers]

For mention [Triggers](/web/triggers), Mogplex will backfill a missing slug
from the agent name when you bind the trigger.

That makes trigger-based targeted mention routing a little more forgiving than
it looks at first glance.

### Automations [#automations]

For mention-entry [Automations](/web/automations), Mogplex routes targeted
mentions against the slug on an **entry agent** connected directly to the start
node.

If that entry agent has no slug, targeted mention routing has nothing stable to
match against.

In practice:

* mention automations should use entry agents with clear slugs
* downstream agents do not control mention matching
* default mention automations are safer than targeted ones when your roster is
  still being cleaned up

## Slug hygiene [#slug-hygiene]

A good slug is:

* short
* lowercase
* easy to predict
* tied to the job, not a temporary initiative

Prefer:

* `triage`
* `security-review`
* `bundle-size`
* `release-manager`

Avoid:

* sentence-like slugs
* unstable slugs tied to one sprint or experiment
* ambiguous names like `agent-2`

## Base agent vs flow override [#base-agent-vs-flow-override]

This is the other common confusion point.

The roster entry is the reusable identity.

An automation node can still override:

* model
* system prompt
* timeout
* max steps

That override changes the behavior of that node only. It does not mutate the
base agent the rest of the product sees.

## Rule of thumb [#rule-of-thumb]

Use the roster to define stable reusable identities.

Use categories to keep those identities navigable.

Use slugs when you want humans to be able to call those identities directly
from GitHub.