> For the complete documentation index, see [llms.txt](https://comunity.gitbook.io/learning.comunitynexus/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://comunity.gitbook.io/learning.comunitynexus/26.2/toolkit-guides/intelligence/trigger-an-agent.md).

# Trigger an agent

A trigger is what causes an agent to run. Without one, an agent can only be used in the playground.

Triggers are found under **Intelligence (Preview)**, then **Triggers**. The screen has two tabs, **Configuration** and **Monitoring**.

## Before you start

* An environment. Intelligence is organised by environment throughout, and Triggers states the requirement directly: until an environment exists the screen shows only a prompt to create one. See Environments.
* An agent that works in the playground. See Create an agent.
* A data service with no unbuilt changes, because saving a trigger writes code into it.

## Kinds of trigger

| Kind         | Fires                                 |
| ------------ | ------------------------------------- |
| **Schedule** | At a time you set                     |
| **Data**     | When a record in your project changes |

A schedule suits work that reviews a period: checking the previous day's claims and summarising them for the responsible manager, or looking over yesterday's registrations for anyone worth contacting personally.

A data event suits work that has to respond to something as it happens.

## The Create Trigger form

Every trigger is created from the same form, which sets its source routing, the agent it runs, and the condition tree. The fields common to every kind are:

| Field                 | What it sets                                                                             |
| --------------------- | ---------------------------------------------------------------------------------------- |
| **Trigger Type**      | **Data** or **Schedule**. The type-specific configuration below changes with the choice. |
| **Agent**             | The agent this trigger runs.                                                             |
| **Source Identifier** | Auto-generated from the entity and method; how the trigger is identified.                |
| **Order**             | Orders this trigger relative to others (default 0).                                      |
| **Enabled**           | Whether the trigger is active.                                                           |

## Create a data event trigger

Choose the entity and the operation. The Toolkit shows the entity and the method the trigger will be inserted into, for example the add method on a user profile. The **Data Entity** and **Entity Method** set the record change that fires the trigger, and a **Generated Code Snippet** previews the code that will be inserted into the entity's custom code, auto-inserted and updated without duplicates for this trigger.

### Filter with conditions

Every record matching the event reaches the trigger. Conditions decide which of those reach the agent. Build them under **Conditions** with **Add Root Group**.

Conditions and condition groups filter on the record's own fields: a user profile created without a gender, or without an ID number. Where the agent should see everything, remove the conditions and every record created is sent.

Filtering here rather than in the agent's instructions is worth doing. A record excluded by a condition never becomes a model call at all.

## What saving a trigger changes

Saving a trigger writes code into your project's data service:

* A call is added to the entity method the trigger fires on, four lines at the call site.
* An `AgentTriggerBridge` class is added where the project does not already have one. It carries the scaffolding a call to an agent needs, including routing the record and waiting for the final result.

The bridge class is ordinary project code and can be called directly, so an agent can be invoked from anywhere in your project and not only from a trigger. The trigger exists to save you writing that call by hand.

## Build the project

{% hint style="warning" %}
A trigger takes effect only after the project is built. Where the data service already holds unbuilt changes, the Toolkit asks for a build before the trigger can be saved.
{% endhint %}

A trigger is also the record the platform monitors against, so runs are logged and tracked against the trigger that caused them. The **Monitoring** tab shows that trigger activity.

## Agent handoff rules

The Triggers screen also holds **Agent Handoff Rules**, under **Configuration**: the transition rules that hand work from one agent to another. See Connect agents for when a handoff is the right mechanism.

## Where to go next

* Connect agents: let a triggered agent call others
* Monitor agent activity: confirm the trigger is firing