Tasks, Runs & Scheduling

A task describes an outcome; a run is one attempt at it. A task can run many times — manually re-run, on a schedule, or re-triggered by an automation — and every run keeps its own full record.

Anatomy of a task

• Title and description — the work itself. The description is the agent's brief: state the deliverable, the sources, and the constraints.
• Priority — for your own triage in the task list.
• Template — a task can be created from a template that pre-fills the description and settings.
• Tool policy — advanced: allow/block specific tools for this task.

Run lifecycle

Every run moves through a state machine:

Status	Meaning
queued	Accepted, waiting for a worker
running	The agent is executing
waiting_approval	Paused — a gated action needs your approval
waiting_input	Paused — the agent asked you a question
completed / failed / cancelled	Terminal states

The two waiting states are fully resumable: the agent's state is snapshotted, and answering resumes execution exactly where it stopped — minutes or days later. A run can also suspend itself waiting for an external event or for another task.

What a run records

Open any run from the task's run selector to see:

• Plan — the agent's todo list as it evolved
• Activity — the full step-by-step log: tool calls, outputs, decisions
• Output files & artifacts — deliverables produced by that run
• Pending approvals / questions — anything still waiting on you
• Token usage — cost transparency per run
• Memory — facts the run saved for future work

Scheduling

Tasks support two scheduling modes, set on the task:

• One-time — run at a specific date and time ("prepare the board pack Friday 07:00").
• Recurring (cron) — run on a cron expression, with UI presets for common cadences (daily, weekly, monthly).

Scheduled runs behave exactly like manual ones — including pausing for approvals and emailing you when they finish or fail — so a recurring task is a genuinely unattended operation with human checkpoints only where you configured them.

Every Monday 08:00 — pull last week's numbers from the analytics DB,
compare with the previous week, and email the summary to the team.

Subtasks

For large work, the agent can propose subtasks (create subtask) — creating one is approval-gated by default, and whether subtasks start automatically is controlled by the project's Auto-run child tasks setting. Subtasks appear nested under the parent in the task list.

Typical use: a migration across many repositories becomes one parent task plus one subtask per repository, each with its own run history.

Task coordination

Tasks in a project can see and wait for each other:

• List project tasks — the agent can check what else is running or done in the project.
• Wait for task — a run can suspend until another task reaches a terminal state, then continue with its outcome.

This turns a project into a small orchestration space: "generate the three sections in parallel subtasks, wait for all of them, then assemble the final document."

Templates

The template gallery ships ready-made task definitions you can add to a project and run as-is or adapt — including:

• GitHub PR review — review a pull request and post structured feedback
• Incident triage — collect context and produce a first-response summary
• Postmortem draft — turn incident notes into a structured postmortem
• Recurring competitor watch — track competitor sites and report only what changed
• Data quality audit — profile datasets for nulls, duplicates, and schema drift
• Release readiness check — open PRs, critical issues, changelog draft
• Sprint risk review — flag at-risk items from your project tracker
• Security exposure triage — match advisories against your dependencies
• Marketing content mailer — draft and send a recurring content email

Templates matter most together with Automations: a trigger creates a task from a template, filling its variables from the webhook payload.