Automation

Runs don't have to be queued by hand. Agentfleet can start a workflow on a schedule or in response to an event — the two ways to automate a workflow without a person in the loop. Both bind a workflow and an agent to a trigger source and seed each run's initial context; both fire repeatedly while enabled; and both produce ordinary runs, fully observable and identical to hand-queued ones.

Schedules

A schedule binds a Quartz cron expression to a workflow, firing it on a recurring cadence.

Field	Purpose
Workflow & agent	What runs, and the identity it runs as.
Cron expression	When it fires. Validated at its own boundary — an invalid cron can never reach a schedule.
Input template	Key/value pairs that seed the initial context of every run the schedule starts.
Enabled	Gates firing. A disabled schedule keeps its definition but never fires.
Description	What the schedule is for.

A schedule is a durable definition — runtime state lives on each run it produces, so an enabled schedule fires as many times as its cron dictates. You can enable, disable, update, and delete a schedule, and fire it now to trigger a run on demand without waiting for the next cron tick (useful for testing the binding, or for an out-of-band execution).

Event triggers

An event trigger binds a Service Bus event to a workflow, starting it when a matching event arrives.

Field	Purpose
Workflow & agent	What runs, and the identity it runs as.
Event source	The Service Bus topic/subscription the trigger listens on.
Event-type filter	Narrows which events on the source fire the trigger — a trigger fires for exactly one event type.
Input mapping	A declarative mapping from event-payload fields into the workflow context keys seeded onto each run.
Enabled	Gates firing.
Description	What the trigger is for.

When a matching event arrives on the source, the trigger seeds a run's initial context from the event payload via its mapping, then starts the workflow. Because the source, filter, and mapping are each validated at their own boundary, a trigger can never bind to an empty filter or leave a required workflow input unmapped. Enable, disable, update, and delete triggers as you would schedules.

Identity still applies

Automated runs are not privileged. A scheduled or event-triggered run executes under the same delegated-identity model as any other run: each step still performs a token exchange, scoped to that step's resource and tool. The difference is only in who initiates the run — a cron tick or an inbound event instead of a person — not in what the run is allowed to do.

Related

• Runs — what a fired schedule or trigger produces.
• Run Inputs — the shape of the initial context both seed.
• REST API — the schedule and event-trigger endpoints.