# Assignments (/web/assignments)



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

Instead of listening to a GitHub App installation broadly like
[Triggers](/web/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 [#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](/web/triggers). If the routing needs branching, joins, delays, or
multiple steps, use [Automations](/web/automations).

## Why Assignments exists [#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 [#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 [#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 [#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 [#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](/web/observability) when you need call-level,
   tool-level, or sandbox-linked detail.

## What healthy assignment operations look like [#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 [#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 [#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 [#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](/web/observability).