How to Automate Workflows with Event Triggers

Schedules handle recurring work — run this every Monday, check this every hour. But some work is reactive. A customer tweets about a bug. A pull request gets merged. A form submission comes in.

Event triggers let your AI agents start working the moment something happens, without anyone clicking a button.

Schedules vs. event triggers

Both schedules and event triggers create tasks automatically. The difference is timing:

• Schedules fire at fixed intervals — daily, weekly, every 6 hours. Good for reports, monitoring, and batch processing.
• Event triggers fire when an external event occurs — a GitHub issue is opened, a tweet mentions your brand, a webhook payload arrives. Good for reactive workflows where speed matters.

You can use both in the same project. A schedule for your weekly competitor digest, an event trigger for real-time GitHub issue triage.

How event triggers work

The flow is straightforward:

1. An external system sends an event (via webhook or integration)
2. Orqestr matches the event against your trigger rules
3. A task is created and assigned to the right agent
4. The agent executes, producing output you can review

The matching engine checks three things: the source (which integration sent it), the event type (e.g. issues.opened), and an optional filter (e.g. only when the label is "bug"). If all conditions match, a task is created.

Setting up your first event trigger

Step 1: Connect an integration

Event triggers need a connected integration to receive events from. Currently supported sources include:

• GitHub — issues, pull requests, pushes, releases, and more
• X (Twitter) — tweets, DMs, follows, likes (connect your X account)
• Custom webhooks — any system that can send HTTP POST requests

Connect the integration from your project's Integrations page.

Step 2: Create the trigger

Go to Tasks → Triggers in your project sidebar.

1. Click New Trigger
2. Give it a title (e.g. "Triage new GitHub issues")
3. Select the event source — choose the connected integration
4. Select the event type — a dropdown shows available events for the selected source
5. Optionally add a filter — narrow down which events should fire (e.g. only issues with a specific label)
6. Set priority and labels for the created tasks
7. Optionally assign an owner agent — the agent that should handle the task directly

Step 3: Choose the routing

You have two routing options:

• Through orchestration — the orchestrator reviews the task, refines it, and assigns it to the best agent. Good when you want the system to decide which agent handles it.
• Direct execution — skip orchestration and run the task immediately with the assigned owner agent. Good when you know exactly which agent should handle every event of this type. Enable this by checking Skip review and selecting an owner agent.

Step 4: Test it

Trigger a real event. Open a GitHub issue, post a tweet, or send a webhook. Check your task board — a new task should appear within seconds.

Practical examples

GitHub issue triage

Source: GitHub
Event: issues.opened
Agent: Triage agent with a system prompt like "Categorize new issues by type (bug, feature, question). Set priority based on severity. Add appropriate labels."

Every new issue gets automatically categorized and prioritized before a human ever looks at it.

Social media monitoring

Source: X (Twitter)
Event: tweet_create_events
Filter: Tweets mentioning your brand
Agent: Community agent that drafts reply suggestions

When someone mentions your brand on X, the agent analyzes the tweet, checks if it needs a response, and drafts one for your review.

Deployment notifications

Source: Custom webhook from your CI/CD
Event: Any (custom webhooks match on the payload)
Agent: Documentation agent that updates changelogs and release notes

Your CI pipeline sends a webhook after a successful deployment. The agent reads the commit history and produces release notes.

Customer feedback routing

Source: Custom webhook from your support tool
Event: New ticket created
Agent: Analyst agent that categorizes feedback and updates a running summary

Every support ticket gets analyzed, categorized, and added to a weekly feedback digest — without anyone manually reading and tagging.

Filters for precision

Filters let you narrow which events create tasks. Without filters, every event of the matching type creates a task. That is fine for low-volume sources, but noisy for high-volume ones.

Filters use shallow property matching on the event payload. For example:

• GitHub: only issues.opened where label includes "urgent"
• X: only tweet_create_events where the tweet text mentions your product name
• Custom: only payloads where action equals "completed"

If you need complex filtering logic, use a broad trigger and let the agent decide whether to act. The agent can read the full event data in the task input and choose to complete immediately if it is not relevant.

Combining triggers with schedules

A powerful pattern is using triggers for real-time events and schedules for batch summaries:

• Trigger: Every new GitHub issue creates a triage task (immediate)
• Schedule: Every Friday, a summary agent compiles the week's issues into a report (batch)

The trigger handles the urgent, per-event work. The schedule handles the periodic, big-picture analysis. Both feed into the same agent team.

Tips

• Start with skip-review off. Let the orchestrator handle routing until you see patterns, then switch specific triggers to direct execution.
• Use descriptive trigger titles. They show up in the task board as the task source, so "Triage GitHub issue" is better than "GitHub trigger 1."
• Monitor the activity feed. Every trigger firing is logged. If a trigger is too noisy, tighten the filter or pause it.
• Pair with approval policies. For high-stakes actions (posting public replies, closing issues), enable approval so the agent drafts but you confirm.