Automations
Automations start or update runs when an outside event occurs, so nobody has to open a blank chat box first.
Two operating modes
| Mode | What happens | Good fit |
|---|---|---|
| Fresh run | Each matching event creates a new run from a saved instruction and the event payload | Weekly reports, ticket investigations, document intake, one-time reconciliations |
| Persistent monitor | A named run wakes with its scoped prior state and continues the same operation | Queue triage, exception monitoring, account watchlists, long-running operations |
Choosing the wrong mode is a common early mistake. Queue triage as a fresh run per event loses the context that makes the second duplicate recognizable as a duplicate.
The four parts
| Part | Question it answers |
|---|---|
| Trigger | What event starts or updates the work? |
| Conditions | Which events should act, and which should be ignored? |
| Action | Start a run, update a persistent run, triage a queue, or notify a reviewer? |
| Control | Which identity, connections, limits, proof, and review owner apply? |
Triggers and actions
Triggers can come from GitHub events, Slack messages and reactions, Linear updates, recurring or one-time schedules, and incoming webhooks. One automation may use several triggers when any matching event should start the same workflow.
| Action | Behavior |
|---|---|
| Start a run | Create a new session with the event payload attached as context |
| Update a persistent run | Send the event to a long-running monitor that already holds relevant state |
| Triage a queue | Watch incoming work, remove noise and duplicates, investigate actionable items, and route the result |
| Notify a reviewer | Send a status message when the automation succeeds, fails, or needs a decision |
Configure it
Build an automation on the Automations page, start from a template, or describe the behavior in plain language and review the generated configuration. Opulent can discover the available trigger schema, then list, get, create, update, pause, or delete automations through the same native management layer. Confirm:
- The trigger and its conditions.
- The action and the prompt.
- The Skill, tags, model, and connected repositories or systems.
- The native tools, MCP servers, repositories, and Slack channels the run may use.
- The compute, concurrency, and invocation limits.
- The network policy.
- The run identity, review owner, and notification behavior.
- The evidence required before the invocation can report success.
Explicit allowlists and network policy control what the run can reach. Limits keep a noisy event source from creating too many sessions, and credential values are redacted from agent-visible configuration so the automation record cannot become a secret-distribution path.
Monitor and control
Activity history records each invocation, whether it ran or was skipped, the session it created or updated, and any error. The named review owner receives exceptions and decides what counts as accepted. Disabling an automation stops new work without deleting its configuration.