Triggers
Triggers connect events from your tools to agent actions. Instead of waiting for an agent's next heartbeat, a trigger lets something in the outside world — a new lead, a failed deploy, an inbound email — wake the right agent and set it to work immediately, with conditions and safety rules in between for full control.
Triggers are coming soon. Open Triggers in the sidebar to see the live preview and the expected launch window. This page describes the model so you can plan for it; the setup surface lights up when the feature ships.
The model: Event → Condition → Agent → Action#
Every trigger is a small pipeline with four stages:
| Stage | What it is |
|---|---|
| Event | A signal from a connected tool — the thing that starts the pipeline (a new CRM lead, a Slack mention, a calendar change, a GitHub PR). |
| Condition | A smart filter that decides whether this event is worth acting on, so agents aren't woken by noise. |
| Agent | Routing — which agent should handle this event, based on its role and responsibilities. |
| Action | What the agent does in response, run through its normal supervision and guardrails. |
Reading it as a sentence: "When this event happens, and it meets this condition, hand it to this agent, which takes this action."
Why triggers matter#
Agents already run their Observe → Understand → Decide → Act → Report loop on their own cadence. Triggers make that loop event-driven for the moments that can't wait:
- A hot inbound lead gets a follow-up in seconds, not at the next check-in.
- A production incident routes straight to the agent that owns delivery.
- A new support ticket lands with the onboarding agent the instant it's created.
The event sources are the same connected tools your agents already use — connecting a tool is what makes its events available to trigger on.
Conditions keep it calm#
The Condition stage is what keeps triggers from becoming noise. Rather than firing on every event, a condition narrows to the ones that matter — a deal over a threshold, a message containing a keyword, a failure of a specific kind. This mirrors the notification hints you already set on an agent (proactive-notify vs. do-not-notify) in Templates.
Actions still obey governance#
A trigger is a starting gun, not a bypass. Whatever action the agent takes still resolves through the full three-plane cascade — the workspace safety floor, the agent's supervision mode, and the tool's permission. A triggered action that would normally need approval still parks for your approval.
So you can wire an aggressive trigger without losing control: the event decides when the agent engages, but the guardrails still decide what it may do when it does.
What to prepare now#
While triggers roll out, you can get ready:
- Connect the tools whose events you'll want to trigger on — see Connecting tools.
- Hire and shape the agents that should own each kind of event, using Templates and clear responsibilities.
- Set your guardrails so triggered actions are governed the way you want — see Guardrails & sensitive actions.
What's next#
- Webhooks — the inbound counterpart: let an external service call an agent directly.
- Connecting tools — the event sources triggers draw from.
- Supervision & modes — how a triggered agent decides what it may do.