Assignments

Assignments are the repo-to-agent routing layer for repeatable work.

Instead of listening to a GitHub App installation broadly like Triggers, Assignments bind a specific repo to a specific agent and a specific work type. That makes the repo, not the installation, the durable unit of routing.

Think of an assignment as a standing contract:

for this repo, run this kind of work with this agent.

Use Assignments when

• one repo should always have the same review or triage behavior
• the repo itself is the source of truth for what should run
• you want standing work without building a workflow graph
• you need recurring cron-driven work tied to one repo

If the source of truth is a GitHub event across an installation, use Triggers. If the routing needs branching, joins, delays, or multiple steps, use Automations.

Why Assignments exists

Assignments is the middle ground between lightweight triggers and full workflow graphs.

It keeps durable repo-owned work close to the repo itself:

• standing PR review
• push review
• issue triage
• CI failure response
• scheduled maintenance or refactor work

Supported assignment types

Current assignment types are:

• PR Review (pr_review)
• Push Review (push_review)
• Issue Triage (issue_triage)
• CI Failure (ci_failure)
• Cron (cron)
• Cron Refactor (cron_refactor)

The Projects surface can create some of these directly from a repo card, which is usually the fastest path when you already know the repo that owns the work.

Creation model

Every assignment is a three-part mapping:

1. choose the repo
2. choose the agent
3. choose the assignment type

If you choose a built-in preset agent, Mogplex resolves it to an owned agent before saving the assignment. It reuses your existing fork of that preset when one already exists, or creates a fork in your account automatically.

That behavior is why assignment creation can appear to “materialize” a custom agent even though you started from a preset.

What the page shows after creation

Each assignment row is both a routing rule and a small operational console.

It can show:

• the repo and agent pair
• assignment type
• last run status and timestamp
• failed, running, pending, suppressed, and deferred counts
• the latest error string
• the latest pressure reason when start was intentionally held
• inline Repair, Cancel, and Requeue controls when the latest job supports them

That means Assignments is not just where you define repeatable work. It is also the first place to see whether that work is healthy.

Recommended workflow

1. Create the assignment from the target repo and agent.
2. Let the first run happen naturally from its source event or schedule.
3. Read the assignment row first for status, pressure, and last error.
4. Use Repair, Cancel, or Requeue only when the current job state supports it.
5. Move into Observability when you need call-level, tool-level, or sandbox-linked detail.

What healthy assignment operations look like

• the repo and assignment type still match the work you actually want
• the agent is durable and owned, not an accidental temporary experiment
• the row shows recent status clearly enough that you do not need to open deeper runtime views for every check
• repairs or requeues are the exception, not the default operating mode

Good fits

• a standing PR review agent for one repo
• a repo-specific CI failure investigator
• an issue triage agent for a busy service repo
• a scheduled maintenance or refactor job
• a push review agent for a sensitive branch or codebase

Common mistakes

• using Assignments for cross-installation event routing
• using Assignments when the logic really needs branching or multi-step flow control
• treating the assignment row as the full debugging surface instead of the summary surface

Read the signals correctly

• Failed usually means the latest job did start and ended badly.
• Pending means work is queued but not running yet.
• Suppressed means Mogplex intentionally declined to start that work.
• Deferred means the system delayed start because of pressure or fleet controls.
• Pressure: ... means you should inspect the reason before retrying blindly.

If you need to understand model choice, tool calls, sandbox linkage, or cost, continue into Observability.