Autopilots
Recurring work without a person: a schedule, a webhook from an external system, or a button dispatches an agent, a team, or a workflow.
An autopilot is a standing instruction: it fires on its own and hands the work to an assignee. Overnight ticket triage, a weekly report, a reaction to an event in another system — anything that should happen on a schedule or on an event, rather than when somebody remembers it.
The workspace ships ready-made starting points — a daily digest, bug triage, a weekly progress report, a documentation check, and others — or an autopilot can be built from scratch.
Who the work goes to
An assignee is required, and it decides what happens when the autopilot fires:
- An agent or a team — an issue is created and assigned to them. The work lands on the board with the usual history, comments, and status.
- A workflow — the process starts, with no issue and no agent. If an issue is needed, the workflow files one with a step of its own.
For an agent or a team you can set a prompt — the instruction the agent wakes up with — and the project the issue lands in. The issue title comes from a template, which can substitute the current date.
The autopilot's team is its home: the team's people and the admins see the autopilot, and its runs are seen like the team's tasks. You can pick a team you are in or may edit. Without a team the autopilot belongs to the whole workspace, and the issues it files go to the default team.
What fires it
| Trigger | When it fires |
|---|---|
| Schedule | On a cron expression in the timezone you choose |
| Webhook | When an external system posts to its address |
| Manual | The Run now button — the same path, just a different source |
| API | From a programmatic call |
One autopilot can hold several triggers. A schedule fires on the minute in its own time zone; a new schedule starts in the time zone of your profile. Scheduling is to the minute, not to the second.
- A firing that falls while the previous one is still running is skipped, not queued.
- A firing missed while Bounc was down is not made up later.
- When the clocks change, a time that does not exist that day is skipped, and a time that happens twice fires once.
Webhooks
A webhook trigger has its own address, and that address is the credential.
- A webhook is not signed. Anyone who knows the URL can fire the autopilot; there is no further check. So the address is kept secret and rotated if it leaks.
- Retries do not double the work. Deliveries are deduplicated by key, so a provider that retries will not fire the autopilot twice.
- The payload reaches the assignee. An agent gets it in the description of the issue that is created; a workflow gets it in the run's input.
- Every delivery is visible: the raw body, the headers, the attempt count, and the outcome. Any of them can be replayed by hand.
A webhook address is a secret: whoever holds it can fire the autopilot. That is why it is shown only to the people who may change the autopilot's settings — it fires with their rights. If it leaks, rotate the address: the old one stops working immediately, and every external system has to be updated.
Run history
Every firing is recorded with its source (schedule, manual, webhook, API), its status, and a link to the issue it created.
| Run status | What it means |
|---|---|
| Running | The firing is under way |
| Issue created | The issue is filed and assigned |
| Completed | The firing did its job |
| Skipped | The conditions did not hold — nothing was dispatched |
| Failed | It broke, with a stated reason |
The autopilot itself is in one of three states: Active, Paused, or Archived.
The guard against a broken autopilot
A daily check pauses on its own any autopilot with at least 50 runs in the past week of which 90% failed. The the rationale is straightforward: a broken autopilot should not consume agent runs and tokens for months. Its creator gets a notification in their inbox, and the autopilot can be switched back on as soon as the cause is fixed.
Each step of a firing is retried for about a minute when a service briefly fails, and never opens a second task. A run that still fails is not retried — the next scheduled firing simply starts a new one. If an autopilot is critical, build your own check: have the agent post a comment on success, and watch for its absence.
Who can configure one
Changing what an autopilot dispatches — the assignee, the prompt, the triggers — is for its owner and the workspace's admins. Everyone else sees the autopilot and its run history.
Next
- Workflows — what a workflow-assignee autopilot starts.
- Webhooks — receiving external events in full: response codes, deliveries, security.
- Assets — Assetflows, the automations of tables: the same idea, fired by records.
- Agent tasks — what a firing turns into.