Inbox

The Inbox is the second surface, and after setup it is where you spend most of your time. In the triad — Chat to decide, Inbox to approve, Tasks to steer — the Inbox is the attention cockpit: the single place where everything that needs your judgment comes back to you. You do not watch every run or refresh every task. You let work proceed and act on what surfaces here, and that is how you stay in control without doing the work yourself.

Everything that needs you arrives in one queue

The Inbox is one workspace-scoped feed that collects attention from every domain into a single ordered list. An agent's question, an approval it needs before acting, a mention of you in a comment, a delegation request awaiting your decision, an agent run that failed, a task assigned or updated, a repository problem that needs recovery, a budget threshold warning — they all land in the same queue. A blocked status by itself does not create another item. The question, approval, mention, review, or recovery action that can move the work owns the attention instead. Rather than checking the chat surface, then the task board, then the machines, you check one place, and what is there is the set of things only you can resolve.

Each item names its kind and carries a short title and body, so you can read the queue and know what each entry is asking of you before you open it. Needs action contains every active item, including open decisions, replies, and awareness updates you have read but not cleared. Proposals collects the active proposed records and autonomy changes. Actioned keeps explicit outcomes such as approvals, rejections, answers, retries, and dismissals. Reading only changes an item's visual state; it does not move the item out of Needs action. System cleanup and superseded history do not appear in Actioned. The Inbox badge counts everything still waiting for an explicit outcome. Because the queue mixes sources, each view is ordered by recency rather than by domain: the most recent attention sits at the top, regardless of where it came from.

When several entries are about the same thing, the queue folds them together instead of stacking a separate row for each. Related informational updates on one task or workflow collapse behind a single summary that names what they are about and counts how many arrived, so a burst of activity on one piece of work does not push everything else out of view. A group that holds something you still have to decide opens on its own, and every item in it keeps its own actions, so a folded summary never hides a pending approval or buries the control that resolves it. You expand or collapse any group yourself, and that choice sticks as the queue refreshes around you.

Each decision carries its context and resolution

An actionable item opens the details needed to act without sending you to another page. A question includes the relevant conversation and an answer composer. An approval includes the proposed change and its consequences. A mentioned task comment includes the complete chronological thread, its attachments, current suggested replies, and the ordinary Markdown and attachment composer. Longer threads load earlier comments in bounded pages. A recoverable failure includes the reason and the action that can move work again. Links back to a task, run, or setting remain available for later exploration, but they are not required to understand or complete the Inbox request.

A missing credential follows the same pattern. The item identifies the website, requesting agent, credential kind, reason, and account-signup option. From its Inbox details, a permitted reviewer can select a matching Vault credential, add a new write-only credential, approve creation of a separate account with the configured signup email, or reject the request. The successful choice grants only the task or agent scope that asked and resumes the waiting work.

Some items have no task behind them. A budget warning or a machine-level alert belongs to the workspace or a worker. Those items still keep their decision context and resolution in the Inbox, with destination links reserved for optional detail.

Quick actions apply the source change

Items carry actions that apply the change where it belongs. Approving or rejecting a delegation, selecting a credential, requesting a CLI update for a machine, accepting or rejecting a proposed record, answering a workflow question, replying to a mentioned task comment, and deciding a workflow approval all update the source record that raised the item. A task-comment reply also appears in Task Activity and completes the recipient's Inbox item. Replying from Task Activity completes that same item. New mentions in one thread refresh its open item instead of stacking another request. Once that item is completed or archived, a later request can ask for action again. Every active item can be Dismissed, including awareness-only updates. Dismissal is its own recorded outcome, not an approval, rejection, decline, cancellation, or mark-as-read shortcut. When you dismiss a task work request and its assigned agent can continue, Task Machine adds a brief reassessment comment to the task and resumes the agent through the normal comment workflow. If no agent can run, the dismissal still succeeds without adding a comment. Awareness updates never start agent work. The Inbox holds the attention record, while the task, worker, workflow, Vault, and workspace own their changes. Approving a delegation from the Inbox therefore changes the task assignment, not only the queue.

Which actions an item offers depends on what raised it and what your workspace role can do. Pull-request review items go only to the assigned human reviewer and appear only after the implementing agent passed a fresh review of the exact commit. Their detail includes that pre-review's agent, rationale, and reviewed head alongside the agent-reported change summary, source branch, changed-file and line counts, CI status, and report time, with Approve and Request changes available in the Inbox. The canonical source link remains available for optional inspection. Workspace owners and admins use the same Inbox actions when they need to override the assigned reviewer, and the decision keeps their identity and any feedback they provide.

The command center can surface workflow-linked questions and approvals from anywhere in the app, but it still submits the same answer, approval, or rejection that the Inbox action would submit. Handling or dismissing an item moves it out of your active queue. Reading alone does not.

Capacity reminders explain what is waiting

When every paid cloud worker has task work and another task is waiting behind them, Task Machine can raise a work is waiting for cloud capacity item for workspace owners and administrators. A scheduled task whose start time has passed counts too. The detail names each worker and previews its current, queued, paused, and late task work, so the reason and affected work are visible without switching surfaces. Managed Chat uses its separate workspace lane and never creates this paid-task-capacity reminder. The detail never includes prompts, credentials, repository paths, or runtime internals.

The reminder is workspace-scoped rather than task-scoped. Each permitted recipient sees only the latest open item for the current contention episode, even when several pieces of work join the queue. If capacity becomes available, the work starts, or the source is no longer applicable, the reminder archives itself. Dismissing the item suppresses another copy for that same episode rather than creating recurring noise. A later episode or newly delayed work can raise a fresh reminder.

Add cloud worker opens a confirmation inside the Inbox. It shows the subscription's monthly or yearly recurring price and explains that the first charge is prorated. Confirming adds one recurring worker to the existing Stripe subscription; only a successful subscription update completes the reminder. If Stripe rejects the change, the confirmation stays open and the item remains actionable so you can try again. A person without permission to manage the workspace never receives the purchase action.

Repository access reminders stay with the repository they fix

A coding task that points at an SSH repository can fail for an ordinary run reason, or it can fail because the repository refused Task Machine's key. When the failure is a confirmed SSH public-key rejection, the Inbox raises a repository access required item instead of a generic failed-run alert or a pasted git error. The item stays attached to the task that hit the problem, but the reminder itself is scoped to that repository so you fix the repository once and then continue the work.

That scope matters when the same repository is used again. Each person who is allowed to change both the task and the repository setup sees only the newest open reminder for that repository, so a later failure replaces an older one instead of stacking duplicates. Another repository keeps its own reminder. If your permission changes while a reminder is open, its detail explains that an owner or administrator must finish setup instead of showing controls you cannot use.

Opening the item shows which repository blocked which task and keeps the recovery actions together. Set up SSH access opens a separate Inbox-owned modal with the public key and provider-specific steps for GitHub, GitLab, or Bitbucket, plus generic guidance for another Git host. If the key could not be prepared yet, that setup modal offers Retry key setup first. Once the public key appears, you add it in your Git provider, close setup, and use Key added — retry task from the item to queue the task again. The item is only marked handled after that retry is actually queued, so a retry that cannot start leaves the reminder open for the next person who can act.

The reminder also clears on its own when access is working again. After a later run gets past repository access successfully, older repository-access reminders for that repository are archived automatically, so the Inbox returns to showing only work that still needs a human fix.

Review proposals where they arrive

The Inbox brings a proposal to you the moment an agent raises one and keeps the decision context and actions together. A child-chat proposal uses the standard proposer and rationale header, renders the opening prompt as a chat message, and identifies the target agent once without repeating its full configuration. A connector proposal uses the same proposal header and install-style summary for its description, connection, and availability. Approving a connector opens its prefilled setup flow with authentication and defaults expanded, so you can finish configuration immediately; rejecting records your reason without making the connector available.

Tasks, projects, goals, teams, agents, skills, connectors, and workflows also carry a Proposed tab on their list surfaces for browsing that kind's pending backlog. Promoted workflows, ready-made playbook installations, and generated playbooks collect in the Proposed view on the Playbooks page. These views show the proposal fields, proposer, and rationale before a permitted reviewer decides. Connector proposals stay in the same list format as installed and archived connectors, with each row opening the complete review preview. Approve activates or installs the proposal. Reject records a reason for the agent. Your access determines which proposals and actions you can see.

Notifications return to the decision

When an Inbox item triggers an enabled email or browser notification, opening it returns to that exact item with its context and actions ready. The same link opens the Inbox from an in-app notification, so an alert never leaves you searching through the queue for the decision it announced.

Once a day at 8:00 in your timezone, Task Machine sends one morning digest per workspace covering what is waiting on your approval, what is blocked, what finished yesterday, and what is in progress. Owners and other members who manage tasks receive the workspace-wide overview, including budget spend in each currency. Everyone else sees Inbox items addressed to them and task activity they created, are assigned to, plan, review, or share through an active team queue. If an inactive subscription has stopped work, every digest that already has relevant activity explains that work is paused. Members who manage workspace settings can open billing settings from the email. Everyone else is told to contact an owner or admin. The warning alone never causes an email to be sent. Every line links straight back into the workspace, so the email is a way in, not a dead end. Quiet days stay quiet: when nothing relevant happened and nothing needs you, no email is sent, and the digest only ever contains what you are allowed to see, composed for you.

You control the digest from notification settings, where it sits as a row in the notification table — turn the daily email off entirely there. The timezone that decides when "morning" is lives in account settings. New accounts have the digest on, with the timezone guessed from where you signed up. Change either at any time.

The Inbox updates live

The Inbox reflects the workspace as it changes, without a reload. When an agent on a connected machine asks a question, finishes a task, or hits a failure, the item appears. When you or anyone else reads, completes, or archives an item in another session, already-open Inbox and dashboard views update to match. The count you see is the count that is actually waiting, which is what lets the Inbox be the surface you trust to tell you when something needs you.

From here, the items themselves trace back to the third surface. Most of what arrives was raised on a task, so see Tasks for the record they point into and Comments and mentions for how discussion on a task turns into attention here.