Task automation
The default task-ops pack — how assigning a task to an agent runs it, human review straight from the In review status, guardrails (budgets, concurrency, circuit breakers), and the kill switch.
4 min read
Assigning a board task to an AI agent puts it to work. The task-ops pack — eleven file-based workflows provisioned to every organization — covers the full lifecycle: triage, execution, review, escalation, SLA enforcement, and cleanup. Every workflow is a plain JSON file your organization owns: tune the thresholds, edit the prompts, or deactivate individual triggers on the workflow itself. A task an automation proposes sits in Backlog until a human Starts it — from that moment on it's a board task like any other and enters the loop below.
The execution loop
- Assign a task to an agent (or let unassigned triage score and route new tasks automatically — high-confidence matches auto-assign, the rest get a suggestion comment).
- The agent acknowledges (task moves to In progress), works in its own task thread with the task tools, and posts its result as a comment.
- The task parks at In review — agents can never set Done; that rule is enforced server-side regardless of any workflow configuration.
- A human reviews from the In review column — the task sheet carries everything needed: the agent's report, the live run transcript behind each Activity badge, and the comments. Move the task to Done to complete it, or send feedback by @-mentioning the assignee: a running agent picks the comment up mid-run, an idle one starts a rework run and parks the task back at In review. No approval card interrupts the flow — and no automation ever sets Done.
Failures roll the task back to To do with an explanatory comment. When a decomposed root task has subtasks, the parent waits until the last subtask closes, then rolls up to In review.
Mentions, dependencies, deadlines
- @-mention an agent in a task comment or in the task description and it reads the mentioning text and acts. Typing
@opens an autocomplete over members and the project's agents; the chat previews whether each mentioned agent will actually respond (automation off, budget exhausted, paused). Editing a description or a comment triggers only newly added mentions, and anything the automation writes itself never triggers anyone. Mentions never move the board — with one exception: when the mentioned agent is the task's assignee, the mention is treated as a retry of its assigned work and follows the assignment choreography — In progress while the admitted run works, In review on success, rolled back to To do with an explanatory comment on failure. - When a blocker closes, dependent tasks get a remaining-blocker note; fully unblocked agent work restarts automatically, human work gets an inbox notification.
- Due dates drive an SLA ladder: a 24h warning, an overdue nudge, then a human escalation to the project creator and org admins — repeated once more if the task stays overdue. Each level fires at most once; pushing the due date out resets the ladder.
Guardrails
Every agent run — assignment, mention, revision, escalation, external — passes the same admission gate:
- Budgets (per agent, monthly): at the warn threshold the agent gets an economy instruction and admins are notified once; at the pause threshold new runs are refused. Resets at month rollover.
- Concurrency caps (per agent and org-wide): excess runs queue and start automatically when a slot frees.
- Per-task circuit breaker: more than the configured runs per hour on one task pauses automation on that task until a human changes its status.
Org-wide caps (run concurrency, per-task runs per hour) ship as fixed platform defaults; per-agent budget and parallelism live in the agent's configuration.
Choosing an assignee
Not every task belongs on a coding agent. Use this rule of thumb:
| Task shape | Assign |
|---|---|
| Research, writing, summaries, personal deliverables | A person — disable unassigned triage on personal projects so agents do not auto-pick them up |
| General automation with platform tools (comments, workflows, integrations) | An Agent (platform tool loop) |
| Repository work — bugs, features, refactors, PRs | A Coding agent with the right dispatch: tale-daemon (runtime) for git workspaces, durable sandbox when configured, or accept that sandbox-only coding agents still run the platform loop on the board until you add those fields |
The assignee picker groups Agents and Coding agents separately and shows a one-line dispatch hint for each coding agent. Image agents do not appear in the task assignee list.
The kill switch
The task_automation governance policy carries the master switch: switching it off stops the run path — in-flight work finishes, nothing new starts. It is admin-only and audited; on a self-hosted instance the policy is one of the org's governance config files, alongside the limits covered on Policies and limits.
Where this fits
Task automation is what turns the project board from a to-do list into a delegation surface: a human assigns and completes, the pack runs everything in between, and Done stays a human decision. The natural next read is Backlog for how proposed work enters the loop, and The workflow editor for tuning the pack's own workflows.