Pipeline Triggers
Configure automated pipeline execution with cron schedules, webhooks, events, and file watchers.
Triggers define when a pipeline runs. You can combine multiple trigger types or run pipelines manually.
Manual Trigger
The simplest trigger — run a pipeline on demand via the desktop app or MCP tools.
pipeline_run id="my-pipeline"No configuration needed. Every pipeline supports manual execution regardless of other triggers.
Schedule (Cron)
Run pipelines on a recurring schedule using standard cron expressions.
{
"type": "schedule",
"cron": "0 9 * * 1-5",
"timezone": "America/New_York"
}Common Cron Patterns
| Pattern | Schedule |
|---|---|
0 9 * * 1-5 | Every weekday at 9am |
0 */2 * * * | Every 2 hours |
0 0 * * 0 | Every Sunday at midnight |
*/30 * * * * | Every 30 minutes |
0 18 * * 5 | Every Friday at 6pm |
Use Cases
- Daily standup report — Aggregate tasks, generate summary, post to Slack
- Hourly health check — Hit your API, alert on failures
- Weekly code review — Scan for stale PRs, notify team
Webhook
Expose an HTTP endpoint that starts a pipeline when called. The request body is passed as the trigger payload.
{
"type": "webhook",
"path": "/hooks/deploy",
"method": "POST",
"secret": "your-webhook-secret"
}| Field | Description |
|---|---|
path | URL path for the webhook (e.g., /hooks/deploy) |
method | HTTP method to listen for (GET or POST) |
secret | Optional shared secret for request verification |
Use Cases
- GitHub PR webhook — Trigger code review pipeline on new PRs
- Deployment webhook — Run post-deploy checks after CI/CD
- Form submission — Process incoming data from external services
Example: GitHub PR Review
- Create a pipeline with a webhook trigger at
/hooks/github-pr - Add GitHub webhook pointing to
http://your-server:3000/hooks/github-pr - Pipeline receives PR data → Agent reviews → Posts results back
Event
Listen to internal EventBus events. Triggers when a matching event is emitted within Agents Machine.
{
"type": "event",
"eventName": "memory:stored",
"filter": "category == 'architecture'"
}| Field | Description |
|---|---|
eventName | Internal event name to listen for |
filter | Optional expression to filter events |
Available Events
| Event | Emitted When |
|---|---|
memory:stored | New memory is saved |
task:created | Kanban task is created |
task:updated | Kanban task status changes |
agent:completed | Agent finishes execution |
skill:invoked | Skill is executed |
session:checkpoint | Session checkpoint is saved |
Use Cases
- Auto-tag memories — When a memory is stored, run classification agent
- Task notifications — When a task moves to "done", notify the team
- Audit logging — When a secret is accessed, log the event
File Change
Watch filesystem paths and trigger when files are created, modified, or deleted.
{
"type": "file_change",
"glob": "src/**/*.ts",
"debounceMs": 2000
}| Field | Description |
|---|---|
glob | File pattern to watch (glob syntax) |
debounceMs | Debounce delay to batch rapid changes (default: 1000ms) |
Use Cases
- Auto-review on save — Watch source files, run code review agent on changes
- Documentation sync — Watch markdown files, update memory when docs change
- Test runner — Watch test files, run tests on modification
Combining Triggers
A pipeline can have multiple triggers. For example, a code review pipeline might be:
- Webhook — Triggered by GitHub on new PRs
- Schedule — Daily scan of all open PRs at 9am
- Manual — On-demand review when needed
The trigger type is recorded in each pipeline run for audit purposes.