For the complete documentation index, see llms.txt. This page is also available as Markdown.

Triggers

Triggers are the events that cause the agent to run. Each trigger is a named condition — described in prose — that the platform watches for; when the condition is met, the agent is invoked with that trigger's context. Triggers are how an agent moves from a passive chatbot (answering when asked) into an active automation (running on its own when something noteworthy happens in the host application).

Manage Agent → Triggers list

Reach this page from Manage Agent → Triggers in the left navigation. The same data is also reachable from the canvas: clicking the <N> Triggers chip in the Layout view opens the expanded trigger editor for this section.

The Builder Canvas, with the Triggers chip showing the configured trigger count
The Triggers chip on the Builder Canvas.

The trigger list

The right pane shows every trigger configured on the agent. Each row carries:

  • A trigger icon

  • The trigger's name (snake_case)

  • A type pill — currently observed as App for every row

  • A truncated description of the condition

  • A overflow menu on the right

The <N> Triggers chip on the Layout canvas always matches this count.

Note The expanded trigger editor — reached either by clicking a row or by clicking the <N> Triggers chip on the canvas — opens a wider modal with a list pane on the left and an editable detail pane on the right. The wider modal also exposes a + Add New Trigger action that's not present in the inline view. The creating a trigger page walks through that flow.

Trigger types

Each trigger has a Trigger Source — the type of event that fires it. The Trigger Source is a required field on the trigger detail form. In an example agent, the only source observed in the dropdown was App — the trigger fires from within the host application that embedded the agent.

The sources available in the dropdown depend on how the agent is set up. If the source you expect is not listed, check the agent's configuration with your platform administrator.

What's in a trigger

A trigger is the combination of three things:

Field
Obligation
Notes

Trigger Source

Mandatory

What causes the trigger to fire. The sources available depend on the agent's setup.

Trigger Name

Mandatory

A unique identifier. The platform treats this as the trigger's primary key.

Description

Mandatory

Prose that explains when the trigger fires. This is read by the planner at runtime to decide whether the trigger matches an incoming event.

The Description field carries most of the weight. The platform does not parse the description as a rules expression — it is fed to a language model that decides whether an incoming event matches the description. This means:

  • Anchor conditions to specific values. "When the business's cash reserves fall below 15% of the average monthly operating cost" is interpretable. "When cash is low" is not.

  • Avoid qualitative judgments. "When something concerning happens" matches everything; "when a transaction exceeds the historical average for that category by 50% or more" matches the specific event you want.

  • One condition per trigger. A trigger with three or-conditions is harder for the runtime to match cleanly than three triggers with one condition each. Multiple triggers also give you finer control over what happens after each one fires.

Editing or removing a trigger

Click any row to open the detail editor (the Custom Trigger panel on the right of the expanded modal). The detail editor lets you change the Trigger Source, the name, and the description, then save with Update Trigger or discard with Cancel.

The row's menu surfaces per-row actions (likely duplicate / delete / inspect).

Why this matters

A well-authored trigger is the difference between an agent that runs when it should and one that runs when something vaguely related happens. Because the description is interpreted by a model at runtime, vague language produces unreliable firing — false positives in some weeks, false negatives in others, with no obvious pattern. Spend the time to anchor each trigger description to concrete, measurable conditions. The downstream consequence is an agent whose alerts can be trusted, which is the whole point of triggering an agent rather than scheduling it.

Last updated