> For the complete documentation index, see [llms.txt](https://docs.uptiq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.uptiq.ai/agent-builder/build/triggers.md). # 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 **` 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 ` 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 **` 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.uptiq.ai/agent-builder/build/triggers.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.