Overview

Automations are the workflow graph surface in the web app.

Use them when one GitHub event should lead to multiple steps, branches, or publish-controlled behavior instead of a simple one-event-to-one-agent route.

Why you move up to Automations

Automations exists for the moment when simple routing stops being enough.

If you need to say any of these, you are in automation territory:

• “only do the edit if the review node found a real issue”
• “split this work across multiple agents and join it later”
• “hold the route as a draft until we publish”
• “delay the next step until later”

In this section

• Agent Roles for the exact difference between triage, review, and edit
• Publishing and Routing for draft vs published behavior, activation, and the webhook routing model

Mental model

Each automation is installation-scoped and starts from exactly one GitHub event on the start node.

From there the graph fans out through the canvas.

Current node types include:

• Agent nodes for review, edit, or triage work
• Condition nodes for true/false branching on event data
• Parallel split and Join nodes for fan-out and fan-in
• Delay nodes for scheduled waits inside the workflow

Two implementation details matter in practice:

• Agent-node overrides only change that node inside the current automation. They do not mutate the base agent in Agents.
• For @mention automations, Mogplex routes targeted mentions against the entry agent slug. That means the slug on an agent node connected directly to the start node, not a later downstream node.

This is the key split:

• Agents owns reusable definitions
• Automations owns orchestration around those definitions

What the editor gives you beyond simple routing

The automation editor is more than a canvas.

It also gives you:

• draft editing with autosave
• manual save when you want an explicit checkpoint
• publish and activate controls separate from drafting
• duplicate, pause, and delete actions
• recent runs for the selected automation
• assistant-generated graph suggestions you can apply back into the draft

That combination is the main reason to choose Automations over Triggers.

Build from the start node outward

The cleanest way to author an automation is:

1. pick the start event first
2. define the first agent role correctly
3. add conditions, delays, or parallel branches only where they change the outcome
4. publish only when the draft matches the route you want live

Most workflow confusion comes from choosing the graph shape too early before the entry event and entry role are actually clear.

Pick the Right Agent Role

The role on an agent node changes how Mogplex expects that node to behave.

Mogplex also picks a default role when you insert a new agent node:

• triage for mention, issue_opened, and issue_comment
• review for pr_opened, pr_comment, push, and ci_failure

Triage vs Review

This is the most common point of confusion.

Use triage when the agent should understand context first and respond in the language of the thread or event. Typical cases:

• a GitHub mention asking for help on a PR thread
• a new issue that needs labeling, reproduction guidance, or next steps
• an issue comment that should wake a repo assistant and continue the conversation

Use review when the agent should inspect changed code and produce findings about it. Typical cases:

• a pull request opens and you want review comments
• a push lands on the default branch and you want a branch-level review
• a CI failure should trigger code-oriented analysis before a fix step

Use edit when you want the graph to apply changes only after an earlier node has already decided that code should be mutated.

Mention routing

Mention-driven automations use exact GitHub comment syntax.

• @mogplex creates a bare mention event
• @mogplex/<agent-slug> creates a targeted mention event

Example:

@mogplex/triage summarize this issue and suggest the next step.

Rules:

• Bare @mogplex only routes to mention automations whose start node is marked Default mention target.
• Targeted mentions only route to mention automations whose entry agent slug matches the text after /.
• The slash matters. @mogplex triage is just a bare mention plus text, not a targeted mention.
• PR or issue comments without @mogplex use the pr_comment or issue_comment event types instead of mention.

For the exact mention rules across Triggers and Automations, see GitHub Mention Routing.

Drafting and publish lifecycle

Automations keep a draft graph, autosave as you edit, and expose a separate publish step.

Publishing does two things:

• saves the latest workflow version
• activates webhook routing against the published version

That lets you keep changing a draft without immediately changing live routing.

If an automation already has a published version, draft edits stay local to the editor until you publish again. That separation is what makes the canvas safe for iterative changes on a live route.

Good starter patterns

• pr_opened -> review -> condition -> edit or end
• issue_opened -> triage -> condition -> parallel follow-up agents
• mention -> triage -> delay -> follow-up response

These patterns are intentionally small. If you cannot explain the workflow in one sentence, sketch the sentence before you sketch the graph.

Getting started

1. Connect GitHub and make sure the repo owner is covered by a GitHub App installation.
2. Open the Automations canvas and create a flow for the installation you want.
3. Pick the start event first, then choose the role for each entry agent.
4. If the start event is @mention, decide whether this should be the default mention target or a slug-targeted route.
5. Publish the automation when the draft is ready.

What a healthy automation setup looks like

• the installation you need is available
• the start event is explicit
• the entry agent role matches the job
• node-level overrides are deliberate, not accidental
• the published version is the one you actually intend to run

Use Automations vs Triggers

Use Triggers when one GitHub event should wake one agent with minimal setup.

Use Automations when you need branching, parallel work, delays, draft/publish separation, or a workflow that spans multiple steps.