# Overview (/web/automations) 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 [#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 [#in-this-section] * [Agent Roles](/web/automations/agent-roles) for the exact difference between `triage`, `review`, and `edit` * [Publishing and Routing](/web/automations/publishing-and-routing) for draft vs published behavior, activation, and the webhook routing model ## Mental 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](/web/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](/web/agents) owns reusable definitions * Automations owns orchestration around those definitions ## What the editor gives you beyond simple routing [#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](/web/triggers). ## Build from the start node outward [#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 [#pick-the-right-agent-role] The role on an agent node changes how Mogplex expects that node to behave. | Role | Use it when | Best entry events | Special behavior | | -------- | -------------------------------------------------------------------------------------------------- | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | `triage` | The agent should read the event or thread, classify it, answer, label, or decide what happens next | `mention`, `issue_opened`, `issue_comment` | Best for conversational or operational response work. No review autofix behavior. | | `review` | The agent should inspect code changes and report findings | `pr_opened`, `pr_comment`, `push`, `ci_failure` | Can emit structured review findings. This is the only role that exposes auto-fix in the flow editor. | | `edit` | The graph has already decided to mutate code and this node should apply the change | Follow-up step after `review` or a condition branch | Use it as an explicit mutation step instead of overloading a reviewer. | 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 [#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-routing] Mention-driven automations use exact GitHub comment syntax. * `@mogplex` creates a bare `mention` event * `@mogplex/` creates a targeted `mention` event Example: ```text @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](/web/guides/github-mention-routing). ## Drafting and publish lifecycle [#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 [#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 [#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 [#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-automations-vs-triggers] Use [Triggers](/web/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.