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 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.

Note — Depth gap Other trigger sources (such as API-invoked or scheduled triggers) may exist platform-wide but were not visible in the example agent's dropdown. Whether other sources require specific platform settings, agent capabilities, or app configurations to appear is queued for a future capture pass.

What's in a trigger

A trigger is the combination of three things:

Field	Obligation	Notes
Trigger Source	Mandatory	Currently only App observed in this engagement.
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).

Note — Depth gap The exact items in the ⋮ menu were not enumerated during capture.

A note on the example agent's trigger list

The triggers list in the example agent observed during capture contained six rows with only three unique trigger names — each appearing twice. The Trigger Name field is documented as "a unique identifier for this trigger," so the duplicates were unexpected. This is flagged in the companion anomalies report as something the platform team may want to investigate; it should not be assumed to be normal behavior in your own agents.

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.