Tasks

A task is the third surface and the unit of work itself. In the triad — Discuss to decide, Inbox to approve, Tasks to steer — Tasks are where execution happens and where you step in on a specific job. A task is also the papertrail: the canonical record of one piece of work, whoever or whatever does it, with a full history you can read top to bottom. Where Discuss is open-ended and the Inbox is a queue, a task is durable and complete, and that is why work that starts elsewhere still lands on one.

A task carries everything about one piece of work

A task holds the fields you would expect of a work item and a few that make it the system of record. It has a title and a markdown description, a project it belongs to and an optional goal it serves, an assignee, a status, a priority, labels, and a due date. It can also carry scheduling — a time it becomes actionable, or a recurrence — and when that time arrives Task Machine activates the work: a one-time scheduled task is marked actionable, and a recurring task creates its next occurrence on the schedule. An activated task then enters the assigned agent's queue and runs like any other, so repeated and deferred work does not just sit waiting, it starts on its own when it comes due. And a task can depend on other tasks, which is how a larger effort keeps its order.

Priority runs on an ascending scale — a higher priority is more urgent, from no priority up through low, medium, high, and urgent — and the agent queue picks higher-priority work first. You set a schedule in plain language rather than cron syntax: you describe the cadence ("every Monday at 9"), Task Machine resolves it and previews the upcoming runs in your timezone so you can confirm them before saving, and the raw expression stays editable behind an advanced disclosure when you want precise control.

You read and steer a task from these fields. Changing the assignee, the status, or the description is how you direct the work; the task records each change so the direction you gave is part of the history, not a side conversation.

The timeline is the papertrail

Everything that happens to a task lands on one ordered timeline, and that single history is what makes the task the place to look. Human comments and agent comments, status changes, the questions an agent raises, the approvals it requests, an agent's note that it deliberately took no action this turn, and the final summary it writes all appear in the same chronological thread. There is no separate discussion system and no separate audit log: the timeline is both. When you open a task, you see what was decided, who decided it, what the agent asked, and what it concluded, in the order it happened.

The agent's runs appear here too, not only their results. Every time an agent works the task — whether a comment woke it, an assignment put it on its queue, a schedule fired, or a workflow node reached it — that run shows up as an entry on the timeline, marked with what triggered it and how it ended. Open the entry and you get the whole run: an overview of what it ran on — the model, the runtime, when it started and finished, and the tokens and cost it spent — above the full transcript of the tool calls the agent made and what each returned, its reasoning, the compiled prompt it was handed, any errors, and a live indicator while it is still working. It is the same view a workflow run gives for each of its nodes, and the transcript is rendered exactly the way a run reads in Discuss, so there is one way to read what an agent did wherever it did it. The durable results stay the backbone of the history; the run detail sits under each entry for when you want to see how the agent got there and what it cost. The task's sidebar adds those up into one running total, so a glance tells you what the whole task has spent across every run that has touched it.

Because the timeline is the papertrail, work that originates on another surface attaches here. The reasoning in Discuss becomes a task; a question an agent raises becomes a timeline event and an Inbox item that points back to it. There is always one place to look, and it is the task.

When an agent finishes a task, it writes a completion summary — a short account of what it did — to close the history. That summary is required, not optional: if an agent ends a task without one, Task Machine notices the blank summary and starts a follow-up turn whose only job is to write it. So a completed task always carries a final word on how it was resolved, whether the agent wrote it the first time or on the enforced second pass.

Files and images attach to tasks and comments

A task can carry attachments — files and images — alongside its description, and so can a comment on it. You upload a file to a task's attachments or drop one into a comment as you write it, and Task Machine stores it and shows it inline. Text-like files (plain text, markdown, code, logs, structured data) get a snippet preview rendered straight from the attachment, and images preview as the image itself; anything else shows a file card you can download. Because previews are computed once when the file is stored, the timeline renders them without reaching back into private storage, and an agent reading the task sees the same attachments you do.

Tasks go to people and agents alike

A task can be assigned to a human member or an agent member, and the assignment follows the same rules either way: the person making it needs permission, and the assignee has to belong to the workspace. Assigning to an agent does not bypass control. Once the work starts, the agent's profile still decides what it may do on its own and what it must ask about, and the agent needs an available runtime to run at all.

Assignment is the main trigger that puts an agent to work. When a task is assigned or routed to an agent, Task Machine adds it to that agent's personal queue and starts it on a connected machine as capacity frees up — already-in-progress and higher-priority work first. Reassigning a task pulls it from the old agent's queue before it starts; cancelling or archiving it stops the work. A scheduled or recurring task joins the queue the same way once its time comes due, so deferred work runs without a second nudge from you.

Assignment is not the only trigger, though. A comment can also wake an agent: when someone comments on a task an agent is assigned to, or tags an agent on a comment, that agent runs in response — the comment is the prompt. Either path drives the same execution loop and writes to the same timeline; assignment is how you put steady work on an agent's queue, and a comment is how you nudge it on a specific point. See Workflow execution for how that loop runs.

Dependencies and proposals keep order and judgment

Tasks relate to each other through directional dependencies — a task blocks others and is blocked by others — and the same relationship reads from either side, so one link expresses both "this blocks that" and "that is blocked by this". Task Machine rejects a task depending on itself and rejects cycles. A dependency is more than a label: a task with an unfinished blocker stays out of its agent's execution queue, and the moment its last blocker reaches done the task wakes and dispatches on its own — so independent branches start together while genuinely sequential work waits its turn, and no one has to re-trigger it. A blocked task can also raise an attention item when it becomes unblocked, so the next step does not sit unnoticed.

A task can also be blocked outright as a status, separate from a dependency — most often when an agent hits something it cannot resolve inside the system, like an email it is waiting on. Moving a task into the blocked state raises an Inbox item for the person responsible for it, so a human knows the work has stalled, and the item clears on its own when the task leaves the blocked state. When an agent is the one blocking, it must record why — a reason that lands as a comment on the task — so a bare status flip nobody can explain is rejected. The agent that blocked the task can schedule its own recheck for when it expects an answer; the task detail's recheck control shows when that next check is due and lets you change or clear it. The agent loop explains how that scheduled recheck runs.

A task can also exist before it is real work. An agent may propose a task rather than create it outright, and a proposed task stays out of the normal board until a permitted person approves it — at which point it becomes active — or rejects it with a reason; pending task proposals wait in your inbox and on the Proposed tab of the tasks page. Whether an agent must propose or may create outright follows its autonomy: a lower-autonomy agent always proposes and waits, while a fully trusted agent creates the task active immediately — the same boundary that governs whether it can delegate without asking. That is the same pattern the whole product runs on: the agent does the work of drafting, and your judgment decides where it still needs to sit in the loop.

From here, the discussion that fills a task's timeline has its own chapter — see Comments and mentions for how a comment on a task draws the right person or agent in.