Triggers
A trigger is a rule that fires an agent automatically in response to an event, a schedule, or an inbound webhook. No manual Run click required.
Every agent can have one or more triggers. Triggers don't change what the agent does. They control when it runs and what input it receives.
Trigger types
| Trigger type | The agent fires when | Typical use |
|---|---|---|
| Event | Something happens inside SixDegree (ticket breaches SLA, opportunity advances, etc.) | "When a ticket breaches SLA, find the incident behind it and post to #support-leads." |
| Scheduled | A cron expression ticks | "Every weekday at 9am, list accounts that renew in the next 30 days with an open escalation." |
| Webhook | An external system POSTs to a unique URL | "When Stripe reports a payment failure, gather the account's support and usage signal." |
Screenshot needed: Agent detail page with an Add Trigger button visible, plus the three-tab modal letting you pick Event / Scheduled / Webhook.
:::
Event triggers
Event triggers react to things that happen inside the platform: discovery (new tickets, accounts, opportunities found by a molecule) and lifecycle changes on entities you already track.
Picking Event opens a two-part form:
| Field | What to enter |
|---|---|
| Event type | A dropdown of every event the platform can emit, e.g. zendesk.ticket.sla_breached, entity.created |
| Filter | One or more match conditions that narrow the scope, e.g. priority = urgent, account.tier = enterprise |
The agent fires only when every filter line matches. Non-matching events are discarded at zero cost.
Start with a broad event type and no filters to confirm the trigger fires, then add filter conditions to narrow it down.
Screenshot needed: Event trigger form with the event-type dropdown open showing a few familiar event names, and a couple of filter rows underneath.
:::
Scheduled triggers
Scheduled triggers fire on a standard 5-field cron expression. The dashboard also offers quick presets for common intervals.
# Format: minute hour day-of-month month day-of-week
0 9 * * MON-FRI # Weekdays at 9am
*/15 * * * * # Every 15 minutes
0 0 * * 0 # Sunday at midnight
When SixDegree runs across multiple replicas, exactly one fires per tick. There is no double-execution during deploys or rolling restarts.
Screenshot needed: Scheduled trigger form with the cron expression field, the human-readable "next fires at…" preview, and the timezone selector.
:::
Webhook triggers
Webhook triggers expose a unique public URL. When an external system POSTs to that URL, SixDegree verifies the signature and fires the agent with the request body as input.
Creating a webhook trigger produces two values:
| Value | What to do with it |
|---|---|
| URL | Paste into the external system's webhook destination field |
| Signing secret | Paste into the external system's secret/HMAC field |
SixDegree stores the secret encrypted at rest and rejects any request that arrives without a valid signature.
The signing secret is shown only once at creation time. Copy it immediately. If you lose it, delete the trigger and create a new one. The URL will change, so update the external system as well.
Screenshot needed: Webhook trigger create-success screen showing the unique URL and the (one-time-display) signing secret with a Copy button, plus brief instructions for Stripe / GitHub / generic systems.
:::
How an agent sees its trigger input
The trigger passes data into the agent's goal at runtime using {{placeholder}} syntax. The platform fills these in from the event body or webhook payload before the agent starts.
# Event trigger, using event fields in the goal
When ticket {{ticket.id}} for {{account.name}} breaches SLA,
find the incident behind it and the account's renewal at risk, then post to #support-leads.
# Webhook trigger, using payload fields
A payment of ${{payload.amount}} failed for customer {{payload.customer_id}}.
Look up that account's support and usage signal and post a brief summary.
A single saved agent can react to thousands of distinct events without repeating the same prompt.
Fire history
Every trigger fire is logged. The trigger detail page shows recent fires with:
| Column | What it shows |
|---|---|
| Time | When the trigger fired |
| Status | Succeeded, failed, cancelled, or blocked on approval |
| Duration | Wall-clock time from fire to completion |
| Cost | LLM token cost for that run |
| Task link | Jump to the full task transcript |
Screenshot needed: Trigger detail page with the fire-history table. Columns for time, status, duration, cost, and a link to the resulting task.
:::
Molecule-shipped triggers
Molecules can ship default triggers alongside default agents. Installing a Stripe molecule, for example, may add a trigger that fires on payment failures out of the box. Your edits to those triggers persist across molecule upgrades.
Triggers vs. rules
Rules and triggers both respond to things happening in the graph. The distinction matters for cost and purpose:
| Rule | Trigger | |
|---|---|---|
| Reacts to | Discovery and entity lifecycle events | Events, schedules, or webhooks |
| Output | A new relationship drawn in the graph | An AI agent task runs |
| Cost | Negligible (a CEL expression evaluation) | LLM tokens, billed per run |
If you need to connect two entities automatically, use a rule. If you need the AI to reason about something and take action, use a trigger.
Use rules to maintain your graph and triggers to act on your graph. They work together.
Next steps
- Save Your First Agent: includes a scheduled trigger walkthrough
- Agents: what triggers fire and how agents are structured
- Approvals: gating writes that triggered agents propose
- Rules: the cheaper alternative when you only need a graph connection
- Molecules: the source of events that event triggers react to