Comments and mentions

Comments are how discussion happens on a task, and they are the connective tissue of the three surfaces. The triad is Chat to decide, Inbox to approve, Tasks to steer, and comments sit where Tasks meet the Inbox: they keep human and agent conversation attached to the task it concerns, and they are how a remark on a task becomes attention in someone's queue. Where a chat in Chat is open-ended thinking, a comment is grounded — it belongs to one task, and it lives in that task's history.

Comments live on the task timeline

A comment is attached to a task and appears in that task's timeline, in the order it was written, alongside the status changes, questions, approvals, and summaries the work produced. Human comments and agent comments use the same thread, so there is one history rather than a discussion in one place and a papertrail in another. Comments can be replies to one another, which keeps a back-and-forth grouped without leaving the task. That single thread is the point: when you read a task, the conversation about it is right there with everything else that happened.

A comment can carry attachments, too. You drop a file or image into a comment as you write it, using the same uploader the task's attachments section uses, and it appears inline on the timeline — a snippet preview for text-like files, the image itself for images, a download card for anything else. This is how you hand an agent a log, a screenshot, or a sample file in the same breath as the comment that asks it to act, and the agent reads the attachment as part of the thread. See Tasks for how attachments and previews work.

Agent comments can suggest your next reply

An agent can add up to five short suggested replies to an ordinary comment or thread reply. They appear as numbered options above the same Markdown and attachment composer you already use. Selecting one fills the composer. You can edit it, add an attachment, write something different, or leave without sending. Task Machine never submits a suggestion for you.

Suggestions follow the current conversation. They remain available only while that agent comment is the newest comment in its thread. Any newer comment removes the older options, so a stale suggestion cannot answer a conversation that has moved on. Suggestions alone do not notify anyone. The agent must mention a human when that person needs to act.

Reactions acknowledge without adding noise

A reaction is a single emoji on a comment — 👍, 👎, or 👀 — that lets a person or an agent acknowledge a remark without writing a reply everyone then has to read. You react from the comment itself: the reactions a comment already has show as small counts beneath it, and an add-reaction button opens a picker to place your own. Each member holds at most one of each emoji on a comment, and a reaction appears for everyone watching the task the moment it is made, so a thread can carry quick acknowledgement alongside its substantive comments.

Reactions are part of the dialogue with agents, not just decoration. When a comment triggers an agent — because it tags the agent or lands on a task the agent already owns — the agent confirms it before working by reacting 👍 on the comment that triggered it, so you can see the request was received without a separate "on it" reply cluttering the thread. A reaction on an agent-authored comment can also steer that agent: 👍 means proceed with the proposed next step, 👎 means stop or change course, and 👀 can acknowledge that someone is watching without requiring a reply. If no useful action follows from the reaction, the agent can finish quietly instead of adding noise.

People can always steer an agent this way when they are allowed to react to the comment. Agents can steer another agent by reaction only when their own profile allows reaction steering, and an agent reacting to its own comment never starts itself again. Agents place and clear reactions through the tama reactions command, and the guidance built into every agent tells them to acknowledge with a reaction rather than a throwaway comment. See the CLI command reference for the command itself.

Mentions draw a person in

Mentioning a human member is how you put a comment in front of someone. When a comment names a member, Task Machine creates an Inbox item for that person and sends them a notification, so the comment reaches the surface they already watch rather than relying on them to find it. Opening the item shows the complete chronological thread, including attachments and comments added after the mention. Longer threads load earlier comments in bounded pages without losing the reply composer.

The person can reply from the Inbox with Markdown, attachments, and any current suggested replies. They can also open the task and reply from Task Activity. Either path completes their Inbox item. A newer mention in the same thread refreshes the person's open item instead of adding another request. Each mentioned person receives their own item, and one person's reply does not resolve another person's attention.

Mentions respect visibility and task permissions. You can only mention members you are allowed to see, and the author is never notified about their own comment. A person who can read the task can see its thread context. Only someone who can update the task sees the reply controls. Opening the linked task marks its mentions read, while replying completes the request and keeps it in the Inbox history.

Tagging an agent or team triggers it on the thread

A comment can also carry one tag that is not a human mention: it can tag a single agent or a single team. Agents and teams share one slot — a comment may carry at most one such tag combined — and that tag both sets who owns the thread the comment opens and triggers a turn of work. References classify by their target, so an agent reference tags an agent, a team reference tags a team, and a member reference is the human mention described above. No lookup is needed to tell them apart.

Tagging an agent on a root comment starts that agent's thread and puts the comment into its conversational steering batch. Comments, replies, and reactions aimed at that agent in the same thread wait until you have been idle for one minute, then the agent handles the current set together in one run. Different agents and threads stay separate. Later replies keep driving the same agent without another tag, so the thread remains a running conversation rather than a one-shot. You do not need to assign the task first: the tag both names the owner and drives the work.

A plan waiting for your approval does not end that conversation. A comment can still ask the agent to explain the Work Spec, check whether it remains valid, or revise it. That turn cannot implement the task or count as approval. A revised Work Spec returns for fresh approval, and reactions stay quiet at this gate so a 👍 never releases the work. Only the dedicated approval action lets implementation begin.

Tagging a team routes the thread through the team's lead rather than running a fixed member. When the lead is an agent, the comment triggers the lead to take the thread and decide how the team handles it. When the lead is a person, the thread routes to them through the Inbox instead of running an agent. Either way the team tag points the conversation at the team's coordinator, and the lead decides what happens from there — see Teams for how lead-driven routing works.

One more path needs no tag at all: a comment on a task that already has an agent implementer steers that implementer. You can drive an agent by tagging it explicitly, by commenting on a task it already owns, or by reacting to a proposal it wrote. These paths use the same one-minute conversational batch. Comment-triggered work still comes from human comments only. Reaction-triggered work is bounded by the reacting member's profile and never lets an agent start itself from its own reaction.

Questions and approvals are first-class on the timeline

Some entries on the timeline do more than inform — they pause work and wait for you. An agent can raise a question on a task when it needs a human answer, or an approval request when it wants permission before doing something consequential. Each is a durable record on the task, each writes a timeline event, and each creates an inbox item routed to the member responsible for answering it, linked back to the exact event so you decide with the history in view.

These are the moments the triad is built around. The agent does the work and reaches a point where your judgment is required. It does not push past the gate, it asks, and the ask lands in your Inbox. You answer the question or decide the approval, and the work continues from there. That is the loop these three surfaces close: you decide in Chat, you steer on Tasks, and the comments, questions, and approvals on a task route through the Inbox to keep you in control of all of it.