Automations & Triggers

Automations remove the human from the starting of work. An automation binds a trigger to a task template: when the trigger fires, a task is created from the template — its title and description filled from the trigger's payload — and runs like any other task, including pausing for approvals where configured.

Webhook automations

Every automation gets a public, tokenized webhook URL. Any system that can send an HTTP POST can create tasks in your project:

POST /api/project/automation/trigger/<token>
Content-Type: application/json

{ "customer": "Acme", "ticketId": "SUP-4211", "severity": "high" }

The payload's fields are available to the task template, so the created task arrives with full context ("Triage SUP-4211 for Acme — severity high…").

Typical sources: form submissions, monitoring alerts, e-commerce events, internal systems — anything with an outbound webhook.

Integration triggers

Automations can also listen to connected tools. GitHub triggers are supported today:

• Pull request opened / closed — the classic automated-PR-review setup: PR opens → task is created → the agent clones the repo, reviews the diff, and posts comments via the GitHub action.
• Issue created — turn new issues into triage or first-draft tasks automatically.

External events

Triggers start tasks; external events let a running task wait for the outside world. Mid-run, the agent can:

1. Mint a callback URL (tokenized, public) for this specific wait.
2. Hand that URL to an external system — pass it to a CI pipeline, a third-party API's webhook parameter, an internal approval system.
3. Suspend — for up to seven days — consuming nothing while parked.
4. Resume automatically when the event is POSTed to the callback URL (or when the timeout expires), continuing with the delivered payload.

This is the primitive for long-running, multi-system workflows:

Submit the batch job to the processing service with our callback URL,
wait for the completion event, then validate the results and
report any failed records.

A run waiting on an external event is not an error state and sends no nagging notifications — it's a normal, resumable pause, just like waiting for a human.

Composing the three

A complete unattended workflow usually combines all the moving parts:

Piece	Role
Automation (webhook / GitHub trigger)	When work starts
Task template	What the work is
Skills	How the work is done
Actions	Which systems it touches
Approvals	Where a human signs off
External events	What outside signals it waits for

Example — automated PR review, end to end: a GitHub pull request opened trigger creates a task from the GitHub PR review template; the agent clones the branch (token from project env vars), reviews the diff guided by your code-review skill, and posts inline comments through the GitHub action. Anything beyond commenting — merging, pushing a fix — pauses for approval, and you get the email.