# Overview (/web/agents) The Agents area is the reusable behavior layer for Mogplex. The top-level `/agents` route redirects to `/agents/roster`, and the product sub-nav is split into: * `/agents/roster` * `/agents/skills` * `/agents/rules` * `/agents/context` ## What lives here [#what-lives-here] * **Roster** for built-in agents, custom agents, preset forks, model selection, categories, and prompt editing * **Skills** for reusable workflow or capability packages * **Rules** for shared instruction blocks and policy constraints * **Context** for reusable memory and background knowledge This area defines the reusable ingredients. Other surfaces bind those agents to repos, events, or workflow graphs later. ## What the roster actually does [#what-the-roster-actually-does] The roster is not just a static list of prompts. It merges: * built-in preset agents * your owned custom agents * forks of presets you have customized From there you can: * create a new custom agent * fork a preset and customize it without mutating the original preset * edit name, description, model, category, and system prompt * search across the roster by name or description * group agents into built-in or custom categories * create and delete custom categories * replace agents pinned to hidden legacy models with visible models from your enabled catalog Some other product surfaces can also create owned forks behind the scenes. For example, assigning a built-in preset agent to repo-bound work can resolve to an owned fork so that the routing layer points at a real agent record in your account. ## Categories and model availability [#categories-and-model-availability] Two product behaviors are easy to miss: * Categories are validated. Custom agents can be forced into a real category, and deleting a category moves those agents into a "needs category" state. * Model choice is constrained by your enabled model catalog. An agent can still exist on a hidden legacy model, but future edits should generally move it to a visible model. That means the roster is both an authoring surface and a hygiene surface for long-lived agents. ## Slugs and mention routing [#slugs-and-mention-routing] For GitHub mentions, Mogplex routes against the agent slug, not the display name. That means: * `@mogplex` uses whichever mention route is marked default * `@mogplex/` targets a specific agent route by slug Examples: * `@mogplex/triage` * `@mogplex/frontend-review` * `@mogplex/ci-fixer` The slug is the durable handle when you wire mention-based [Triggers](/web/triggers) or mention-entry [Automations](/web/automations). Keep it short, lowercase, and predictable from the job the agent does. ## Skills, rules, and context are separate on purpose [#skills-rules-and-context-are-separate-on-purpose] The non-roster tabs exist because Mogplex treats reusable behavior as more than just a system prompt. * **Skills** hold reusable procedures, tools, prompts, and workflows. * **Rules** hold account-level instruction files shared across agents. * **Context** holds reusable memory and background knowledge. That split lets you keep the reusable agent definition stable while still evolving the shared knowledge it depends on. ## How Agents relates to the rest of the product [#how-agents-relates-to-the-rest-of-the-product] Think of the reusable agent definition as the base layer: * define the reusable behavior in **Agents** * bind it to a repo in [Assignments](/web/assignments) * bind it to GitHub events in [Triggers](/web/triggers) * orchestrate multiple steps around it in [Automations](/web/automations) Flow nodes inside Automations can still override parts of the reusable definition, such as model choice, role, step count, or timeout, without rewriting the master agent. ## Start here when [#start-here-when] * you need a reusable agent before wiring routing * you want to fork a preset instead of building from scratch * mention routing needs a predictable slug * several repos or automations should share the same core behavior * model or category hygiene has drifted and you want to clean it up centrally ## In this section [#in-this-section] * [Roster and Slugs](/web/agents/roster-and-slugs) for agent identity, presets, forks, and mention handles * [Skills, Rules, and Context](/web/agents/skills-rules-context) for the shared libraries that shape agent behavior If you already know the repo and just need to attach recurring work, start from [Projects](/web/spaces), [Assignments](/web/assignments), or [Triggers](/web/triggers) instead.