Trigger

• A trigger is Guild's mechanism for automating agent execution. It runs an agent automatically when an external event fires or on a recurring schedule.
• Triggers come in two types: webhook (fires on events from a connected service like Slack, GitHub, or Linear) and time (fires on hourly, daily, weekly, or monthly schedules).
• Triggers live inside a workspace and target a specific agent. The agent receives the event payload (for webhook triggers) or the schedule metadata (for time triggers) as its input.
• Triggers are managed through the Guild app or the CLI: create, list, get, activate, deactivate, and inspect the sessions they spawn.

A trigger in Guild is a rule that automatically runs an agent when something happens. That "something" can be an event in a connected external service (a Slack mention, a GitHub pull request, a Linear issue) or a moment on the clock (every hour, every weekday at 9 AM). Triggers live inside a workspace and are bound to a specific agent, so when the trigger fires, Guild spawns a session on that agent with the event or schedule information as its input.

Without triggers, every agent invocation is manual: a person opens the app or the CLI and asks the agent to do something. With triggers, agents work like any other production system, on their own schedule or in response to real events, with the same governance, audit, and permission rules the workspace applies to every other session.

Webhook triggers

A webhook trigger fires when a specific event happens in a connected service. You choose the service, the event, and (optionally) an event action. When the event arrives, Guild spawns a session on the target agent with the event payload as its input.

Currently supported webhook services and example events:

• Slack: app_mention, message
• GitHub: pull_request, issues, push
• Linear: issue, comment
• Jira: issue_created, issue_updated
• Azure DevOps: workitem.created, git.pullrequest.created
• Google Docs: document changes
• Notion: page updates

Time triggers

A time trigger fires on a recurring schedule. Supported frequencies are hourly, daily, weekly, and monthly. Daily and weekly triggers take a time of day and, for weekly, a day of the week. The agent runs on that cadence and receives the schedule metadata as its input.

Sessions spawned by triggers are first-class

Every trigger fire produces a session. Sessions started by webhook triggers have type webhook. Sessions started by time triggers have type time. You can list a trigger's sessions with guild trigger sessions <trigger-id>, filter session lists by type with guild session list --type webhook, and inspect any session the same way you inspect a chat session.

Triggers are managed from the app or the CLI

In the app, open a workspace, click More then Triggers in the sidebar, click New trigger, and configure the service, event, or schedule. From the CLI, use guild trigger create with --type webhook or --type time and the relevant flags. See the Triggers guide for the full walkthrough.

Agents in production do not wait for a human

A prototype agent runs when a person asks it to. A production agent runs when the work needs doing. Triggers are what turn an agent from a chat companion into a piece of infrastructure that responds to the same events the rest of your systems respond to.

Automation should not skip governance

It is easy to bolt an ad-hoc webhook consumer onto an agent and call it done. That path skips every governance rule the workspace enforces: credential scope, audit trail, session history, cost attribution. Triggers keep automation inside the same governed lane as every other session, which is what makes them safe to leave running.

Events and schedules cover most real automations

Most of the automation an operations, engineering, or support team wants comes down to one of two shapes: something happened in a tool we use, or the clock reached a certain point. Webhook triggers cover the first. Time triggers cover the second. Between them, you can run an on-call assistant that responds to Slack mentions, a nightly report agent that runs at 6 AM, a PR-review agent that fires on every pull request, and dozens of other patterns without writing your own scheduling or event-routing infrastructure.

Create a webhook trigger from the CLI

guild trigger create --type webhook --service SLACK --event app_mention --agent <identifier>

Fires the target agent every time your Slack workspace sees an app_mention event. The Slack event payload is passed to the agent as its input.

Create a time trigger from the CLI

guild trigger create --type time --frequency DAILY --time 09:00 --agent <identifier>

Runs the target agent every day at 9 AM in the workspace's configured timezone. Change --frequency to HOURLY, WEEKLY, or MONTHLY as needed.

List, inspect, and control triggers

guild trigger list                           # List triggers in the default workspaceguild trigger get <trigger-id>               # Get trigger detailsguild trigger sessions <trigger-id>          # List sessions spawned by a triggerguild trigger update <trigger-id> --time 10:00guild trigger activate <trigger-id>guild trigger deactivate <trigger-id>

Filter sessions by trigger type

guild session list --type webhookguild session list --type time

Useful for reviewing everything an agent has done in response to a specific class of trigger.

Deactivate rather than delete when in doubt

guild trigger deactivate stops a trigger from firing without removing it. You keep the trigger's history and can reactivate later. Prefer it to deletion whenever you might want to reintroduce the automation.

Triggers inherit workspace credentials

A webhook trigger only works if the workspace has credentials connected for the service. If a trigger's target service is not connected in your workspace, the trigger will not fire even if you have created it. Connect the service first, then create the trigger.

Time triggers depend on the workspace timezone

A DAILY trigger at 09:00 fires at 9 AM in the workspace's configured timezone, not the machine that created it. Verify the workspace timezone before scheduling anything time-sensitive.

Webhook payloads become agent input

Whatever payload the connected service sends becomes the input to your agent. Design your agent's inputSchema to accept the shape of the events it will actually receive. A GitHub pull_request payload is not the same shape as a Slack app_mention payload.

Guild is a control plane for AI agents, a place to build, deploy, and govern the agents your teams run in production. Triggers are how agents graduate from something a person invokes to something the business runs on its own terms.

• The Triggers guide walks through every service and schedule option end to end.
• The full CLI reference lists every guild trigger command.
• Triggers live inside a workspace, alongside agents and workspace context.
• Explore the Guild CLI and the rest of the platform at guild.ai.