Triggers

A trigger starts a run. It is the platform's automation primitive — the thing that decides when an agent or a pipeline executes, on a schedule, on demand, or in response to what else is happening.

#Overview

Agents and pipelines do not run on their own. A trigger starts a run: an isolated execution where the agent reasons and produces output, or the pipeline processes its data. The same trigger model applies to both — a trigger is bound to an agent or a pipeline and fires it.

There are three trigger types. Each has a real fire mechanism: a clock tick, a signed HTTP request, or a matched platform event. An entity can have any number of triggers of different types.

#Cron triggers

A cron trigger fires on a schedule defined with standard cron syntax. It is the right choice for recurring work — a nightly report, a periodic sync, an hourly check.

# Every day at 06:00
0 6 * * *

The expression above runs the bound agent or pipeline once daily at 06:00. A trigger can specify the time zone its schedule is evaluated in. Disabling a cron trigger stops it from firing without deleting it; re-enabling resumes the schedule.

#Webhook triggers

A webhook trigger exposes an HTTP endpoint. Posting to that endpoint starts a run, letting external systems kick off an agent or pipeline in response to their own events.

Webhook delivery is verified. Each request must carry a valid signature, and unsigned or tampered requests are rejected before any run is started. Signing secrets can be rotated without downtime, so a leaked or aging secret can be replaced while the endpoint stays live.

#Event triggers

An event trigger fires when a platform event matches it. The most common use is chaining: when one run completes, its run.completed event can start another agent or pipeline, letting you compose work without an external scheduler.

• A trigger matches events by type, so only the events you care about start a run.
• Matched event data can be passed into the new run as input, so the downstream entity acts on what just happened.

Chaining is bounded for safety. The platform limits how deep a chain of triggered runs can go and detects cycles, so an event trigger cannot set off an unbounded cascade.

#Declaring vs creating triggers

Triggers can come from two places, and both coexist on the same entity.

• Declared in the project — defined in your project manifest alongside the agent or pipeline and applied when the project is deployed, so automation ships and versions with the code.
• Created in the control plane — added through the dashboard for operational triggers that are not part of the codebase.

Re-deploying a project replaces only the triggers it declared. Triggers created in the control plane are preserved across deploys. See Deployment for how project manifests are applied.

#Failures

Triggers do not fail silently. Every dispatch — successful or not — is recorded with the entity, the resulting run, and timing. When an inbound event is malformed or a dispatch cannot complete, it is captured in a dead-letter view instead of being discarded.

That makes failed trigger executions inspectable: you can see what arrived, why it could not start a run, and act on it. See Observability for where execution history and dead-letter entries surface.

#Next steps

• Agents — What a run is, and how an agent reasons and produces output once a trigger starts it.
• Deployment — How project manifests are built and applied, including declared triggers.
• Observability — Execution history, dead-letter inspection, and live run traces.