Automation

Webhook Triggers

Start agent sessions from external events. Subscribe to events on connected accounts, or mint a public webhook URL that any service can call.

How webhook triggers work

Gamut supports two trigger mechanisms:

Connected account triggers: subscribe to events from a service linked through Connected Accounts, such as a new email, GitHub issue, or Slack message.
Custom webhook endpoints: public URLs minted by the agent that any service can send events to, with optional signature verification and delivery filters. No connected account is required.

In both cases, an incoming event starts a new agent session with the event payload and the trigger's configured prompt. Triggers appear in the Triggers section on the agent's home page, alongside scheduled tasks.

Connected account triggers

Connected account triggers ride on an existing service connection:

The agent creates a trigger, specifying the event type to listen for and the instructions to run.
Gamut registers the trigger with the external service through the platform proxy.
When the event occurs, the platform receives the payload and delivers it to the Gamut instance.
Gamut starts a new session with the payload and the configured prompt.

Trigger tools

Agents manage connected account triggers with four MCP tools.

get_available_triggers: lists the event types available for a connected account. A Gmail connection might offer GMAIL_NEW_EMAIL; a GitHub connection offers GITHUB_PULL_REQUEST_EVENT.

setup_trigger: creates a trigger:

Parameter	Required	Description
`connected_account_id`	Yes	The ID of the connected account to subscribe to
`trigger_type`	Yes	The event slug (e.g. `GMAIL_NEW_EMAIL`)
`prompt`	Yes	Instructions the agent follows when the trigger fires
`name`	No	A human-readable label for the trigger
`trigger_config`	No	Service-specific configuration (e.g. filter criteria)
`model`	No	Override the model used for triggered sessions
`effort`	No	Override the effort level: `low`, `medium`, `high`, `xhigh`, or `max`

list_triggers: lists the agent's active webhook triggers.

cancel_trigger: removes a trigger by ID.

A request like "Watch my Gmail for new emails from my manager and summarize them in Slack" leads the agent to discover Gmail events with get_available_triggers, then subscribe to GMAIL_NEW_EMAIL with setup_trigger.

Platform connection requirement

Connected account triggers require an active connection to the Gamut platform. The platform proxy registers subscriptions with external services, receives inbound payloads, and delivers events to the local instance in real time. When the platform connection is unavailable, active triggers do not receive events and the UI shows a warning.

The service connection itself must also be platform-managed. Triggers do not fire for providers configured with a personal API key instead of a Connected Account.

Custom webhook endpoints

Custom webhook endpoints turn an agent into a generic webhook receiver: any service that can send an HTTP request can trigger it, with no connected account involved.

Agents create endpoints with the create_webhook_endpoint tool. Each endpoint gets a public URL, plus an optional verification profile and delivery filter.

Signature verification

An endpoint can require HMAC signatures on incoming deliveries. The verification profile specifies:

Algorithm: hmac-sha256 or hmac-sha1.
Encoding: hex or base64 signature encoding.
Replay window: how long a delivery remains valid, protecting against replayed requests.

Whether a delivery passed verification is exposed to filters as the verified variable.

Delivery filters

An endpoint can carry a filter_exp, a CEL expression evaluated against every delivery. Only matching deliveries start agent sessions. Filtered-out deliveries are logged, never lost.

Expressions have access to:

Variable	Contents
`body`	Parsed request body
`headers`	Request headers
`query`	Query string parameters
`method`	HTTP method
`verified`	Whether signature verification passed
`content_type`	Request content type

Match with contains(), startsWith(), endsWith(), and has(). Regular expressions are rejected.

To react only to newly opened GitHub issues:

headers["x-github-event"] == "issues" && body.action == "opened"

Inspecting deliveries

The inspect_webhook_events tool lists an endpoint's recent deliveries. Use it to confirm events are arriving and to check a filter expression against real payloads.

Event payloads

When a trigger fires, the payload is appended to the configured prompt as a JSON code block:

Your configured prompt here.

---

Webhook payload:
```json
{
  "sender": "jane@example.com",
  "subject": "Q3 Report",
  "snippet": "Please review the attached..."
}
```

Events that arrive at the same time are batched into a single session rather than spawning one each: per trigger for connected account triggers, per endpoint for custom endpoints. Batched sessions receive the payloads as numbered blocks under the same prompt.

Trigger lifecycle

Status	Meaning
Active	Listening for events and starting sessions when they arrive
Paused	Deliveries are received but discarded
Cancelled	Permanently stopped
Failed	The trigger hit an error (e.g. the agent was deleted)

For connected account triggers, pausing keeps the upstream subscription active, so resuming restores delivery immediately. Cancelling cleans up the upstream subscription when no other trigger shares it.

Managing triggers

From the trigger detail view:

Pause / Resume: toggle whether incoming events start sessions.
Edit Instructions: update the prompt sent with event payloads.
Delete: permanently cancel the trigger.

Runtime overrides

Each trigger can override the agent's default model and effort level: a high-volume, low-stakes trigger can run a lighter model at low effort, while a critical one uses the strongest model at high effort. Set the model and effort parameters at creation or change them from the detail view; setting a field to null reverts to the default.

Session tracking

Sessions started by a trigger are tagged with the trigger ID, the trigger name, and an isWebhookExecution flag. The trigger detail view lists every session the trigger has started, along with a cumulative fire count and the time of the last firing.