Overview

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

• 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

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

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

For GitHub mentions, Mogplex routes against the agent slug, not the display name.

That means:

• @mogplex uses whichever mention route is marked default
• @mogplex/<slug> 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 or mention-entry Automations. Keep it short, lowercase, and predictable from the job the agent does.

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

Think of the reusable agent definition as the base layer:

• define the reusable behavior in Agents
• bind it to a repo in Assignments
• bind it to GitHub events in Triggers
• orchestrate multiple steps around it in 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

• 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

• Roster and Slugs for agent identity, presets, forks, and mention handles
• Skills, Rules, and 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, Assignments, or Triggers instead.