Tasks

A task is the third surface and the unit of work itself. In the triad — Chat 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 Chat 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 implementer, 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 implementer, 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 same tasks also lay out as a board — a kanban grouped into columns by status, so what is in progress, in review, blocked, and done reads at a glance and you move work by dragging a card from one column to the next. The list-versus-board layout is a per-account preference that follows you across projects rather than a per-page toggle.

Start with the view that answers the next question

The Tasks page leads with three common views. All shows the workspace's work, Mine narrows it to tasks assigned to you, and Needs attention collects blocked work, open questions, and review states that call for judgment — each row there also shows how long the task has been in its current state, so the oldest blockers stand out. These views change the lens without changing the tasks underneath, so you can move from the whole operation to your own queue or the work waiting on a decision in one step.

A task an agent is queued on or actively working carries a small live dot on its row and board card. Hover it to see which agent and whether the run is queued or running, so execution is visible without opening each task. List and Board show top-level tasks; a count beside a list title reports its direct subtasks, which you navigate from the task itself. Search the current page by task title, description, or exact identifier. A direct subtask match returns its top-level task so the work remains reachable without adding hidden rows or cards. On Scheduled and Recurring, the same field also finds workflows by name or description. Use Filter for the records you want included, such as a project, goal, implementer, status, label, priority, due date, or only the tasks running right now. Use View options for how those records are arranged: grouping, ordering, sort direction, and the columns shown in the list. List and Board switch the layout directly. Keeping filtering separate from presentation means changing the arrangement never silently changes which work you are looking at.

See past Runs and future schedules together

Timeline places actual task Runs and expected scheduled work on one shared time axis. Finished Runs are bars with their real start and finish; active Runs continue to the Now marker. One-time schedules and recurring occurrences are points because their duration is not known yet. Workflow schedules also appear before they create a backing task, so the view does not hide future work merely because it starts through a workflow.

Timeline groups work by Goal by default, with Project and Agent as alternatives. Goal and Project always reflect the task's current organization, so moving a task moves its visible Run history with it. Agent grouping uses the agent that performed each Run, which means one task can appear across several agent lanes. Hover or focus any Run or schedule point to see the same task card used on the board; every visible Run for that task highlights at once, even when those Runs are separated in time or split across agent lanes. The first bounded page is part of the page response, and more task identities load as you scroll rather than making the initial chart wait on a second request.

Task Activity is the papertrail

A task keeps its complete papertrail in two chronological tabs. Activity is the steering history: human and agent comments, status changes, questions, approvals, and the final summary appear in the order they happened. Queued and running agent work appears there while it is active. If work fails or times out, Activity keeps the newest failure visible until newer work succeeds. Successful, cancelled, and superseded runs stay out of the steering history so execution mechanics do not crowd out the decisions and durable results. Consecutive generated events collapse into one counted task update row, using the same in-place accordion as Chat tool activity. Expanding it shows each event's summary, author, time, and complete historical detail. Comments, decisions, and active runs remain separate so the steering history stays clear.

When someone else adds a comment while you keep the task open, that comment receives a subtle highlight wherever its thread sits in Activity. Replying clears the highlights in that thread, and reloading clears all highlights rather than turning comment reading into another saved state. A question remains its comment thread on the task, while its mirrored Inbox item stays in the global Inbox rather than becoming a second task-activity card. An approval appears as a distinct Inbox card on the task and does not add a comment that repeats the same request. Approvals are standalone by default. When a specific comment thread contains necessary decision context, an agent can explicitly attach that chosen comment; the bounded conversation then appears immediately under Comment thread inside the Inbox approval without guessing from the latest task comment. When connector credential access blocks the task, that card is the same recipient-scoped Inbox decision rather than a second request; it retains approval, rejection, detail, and the completed outcome in Activity. Superseded Inbox records stay in Inbox history rather than returning as normal task activity.

Runs is the complete execution record. Every agent and workflow run remains there, including successful work, cancellations, failures that later recovered, and blocked-task rechecks. Workflow steps stay grouped beneath their workflow run and load more inside that group when needed. Both tabs read from oldest to newest and load the next page automatically as you scroll down, so long-lived tasks remain complete without loading their whole history at once.

Open a run and you get an overview of the concrete model, whether Auto or a fixed override selected it, the worker, timing, tokens, and cost above the transcript of tool calls, reasoning, compiled instructions, and errors. The newest transcript page loads automatically, and you can move to earlier or later events without loading the complete transcript at once. Search, page fetching, and browser rows name one or two public domains and otherwise count the sites involved, so the collapsed history stays informative without exposing full URLs. It is the same view a workflow run gives for each of its steps, and the transcript is rendered exactly the way a run reads in Chat, so there is one way to read what an agent did wherever it did it. The task's sidebar adds every run into one total and separates spend by planning, implementation, review, verification, and follow-up, so you can see which stage used the budget without opening each run.

Because Task Activity is the papertrail, work that originates on another surface attaches here. The reasoning in Chat 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, agents, and teams

A task can be assigned to a human member or an agent member, or queued with a team that owns the routing decision. When a project's workflows consistently route new work through one team, the create form suggests that team by default and places it before individual implementers. You can keep the suggestion, choose someone directly, or leave the task without an implementer. The same form lets you choose the Planner and Reviewer explicitly; leave them on Default planner and Default reviewer to inherit the configured task-role defaults. A team-routed task stays in the shared queue until the team's lead routes it to one member, so the team owns the handoff while one person or agent still owns the execution.

The assignment follows the same permission rules in every case: the person making it needs permission, and the member or team 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 worker 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 the workspace queue for that execution lane. Capacity is shared fairly across projects: each project gets a turn before one busy project takes another slot, while already-in-progress and higher-priority work stays first within that project. Local tasks, cloud tasks, and scheduled work have independent capacity, so a due schedule does not have to wait for an unrelated task lane to clear. 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 scheduled lane 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.

Repository work is reviewed before merge

An agent working in a connected repository reports its pull request directly to Task Machine. The task shows the source link, current commit, source state, and Task Machine review state. The report also records the required CI result and source mergeability for the exact commit. A pull request mentioned in a transcript or comment does not become task state. The agent must link it with tama and report each new head explicitly.

Review follows the reported commit. Before the agent submits a head, it fetches and rebases onto the latest tip of the pull request's actual base branch, runs the repository's complete local validation, and checks the source again. A scheduled source recheck inspects required CI, mergeability, the source-host review decision, every review thread and comment, and whether the head still contains the latest base tip. Requested changes, unresolved actionable feedback, a stale base, failed checks, or conflicts return the work to implementation. The agent addresses the feedback, rebases when needed, repeats complete validation, pushes the new head, and waits for its source checks. It can submit only a feedback-complete head that includes the latest base tip, passes every required CI check, and can merge cleanly. When an agent implements the task and a human owns the final decision, the implementer first reviews the exact head in a fresh session. Only a passing pre-review sends that same revision to the human's Inbox, where the decision includes the agent's rationale. If the pre-review finds a gap, the work returns to the implementer without asking for human attention. An assigned agent reviewer remains one fresh review rather than adding a second agent pass. Supervised and Balanced work requires a human reviewer. Autonomous and Full autonomy can use a human or agent. Workspace owners and admins can use the same Inbox actions when they need to override the assigned human reviewer, and Task Machine records who made that decision.

Approval in Task Machine and approval on the source host are separate. Task Machine always requires its own final reviewer approval before an agent may merge an open pull request. A repository rule may additionally require source-host approval. After approval, the implementer checks the exact head immediately before merging, performs the merge with its source tool, and reports the merged state. If direct source inspection shows that the canonical linked pull request's exact current source head was already merged outside this sequence, the agent records that head and state, writes the completion summary, and closes the task without asking for retroactive approval. A new commit, newly failing required check, or newly reported conflict clears readiness and returns the work to implementation, so the corrected code must pass the sequence before a future review or merge. Repository-backed agent work cannot finish while a linked pull request remains open or without a source-confirmed merged current head.

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 starts 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. When an agent blocks the task, it must record why, and that reason stays in the task's status event. A bare status change nobody can explain is rejected. The blocked status does not create a generic Inbox item or an automatic comment. If a person must act, the question, approval, delegation, review, or one mentioned comment carries that request. Worker and repository failures use their own recovery item. The agent can set a deliberate first recheck for an outside condition, and its reason also stays in the task event without creating more Inbox work. If the same blocker is still present later, Task Machine updates only the next check; it does not repeat the event, add a comment, or create Inbox work. A materially different blocker replaces the current reason and records one new event. An ordinary agent-authored block without an exact time receives a one-hour safety backstop. If the task remains blocked, Task Machine schedules later checks automatically: successful checks stay frequent for the first day and then gradually spread out, while unsuccessful checks back off much faster. Task Machine does not infer the first check from pull-request text or status. The task detail's recheck control shows the next check and lets you move or clear it. The agent loop explains the full cadence.

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.