Inbox

Working through decisions

On this page

Use Inbox to supervise delegated work without watching every Run. Questions, plan decisions, approvals, and recovery actions arrive with the context and controls needed to resolve them there. Use Chat for discussion and planning, and Tasks when you need to inspect or steer a specific piece of work.

The Inbox with its Needs you, Triage, Proposals, and Actioned views, High urgency badges, and blocked-work counts beside the Sort and Filter menus

Everything that needs you arrives in one queue

The Inbox brings the Workspace's requests and updates together:

  • Questions, comment mentions, and delegation decisions.
  • Lead updates: a report from the agent that leads a Goal or Project. One that asks you something is a question you answer once, whichever Goals show it. One that only informs is a notice you can reply to or dismiss. Either opens the same post, with its comments, as on the Goal page.
  • Plans, proposals, and approvals before consequential work, including requests to restore archived records.
  • Failed Runs and repository or credential recovery.
  • Task updates and budget warnings.

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. Start with items that need a decision. Informational updates share the feed but do not all require action.

Each item shows its kind, a title, and a body. Decisions read as questions, problems say what stopped, and notices say what happened, and the title names the records, amounts, and dates the item is about. Use the views to separate pending attention from completed decisions:

  • Needs you: every active item except Triage decisions, proposals and autonomy changes, including awareness updates you have read but not cleared. Credential-creation updates stay in the feed without adding to this count.
  • Triage: routing decisions from Team and Project leads that wait for you. The view appears only while it holds a decision.
  • Proposals: active proposed records and autonomy changes.
  • Actioned: explicit outcomes such as approvals, rejections, answers, resolving reactions, retries, and dismissals.

Needs you is always available. Proposals and Actioned appear once they hold items, so a quiet Inbox shows no empty views and, with only Needs you left, no view tabs at all. Reading changes an item's visual state, but leaves it in Needs you, Triage or Proposals. System cleanup and superseded history do not appear in Actioned.

The Inbox badge counts active requests and updates, including Triage decisions but excluding credential-creation updates, and adds the Proposals count, so proposals contribute to both parts of the total. In Needs you, Triage, and Proposals, open Sort above the list, which appears once there is more than one item, to choose Newest first or Priority first. Priority considers urgency first, then blocked work, the earliest time a Task decision is needed, Task priority, and how long a decision has waited, regardless of where items came from. The choice is saved to your account across workspaces and devices. Actioned always shows the most recently completed decisions first.

Focus on a Project, Goal, Agent or Team

Open Filter beside Sort to show only the decisions for the Projects, Goals, Agents or Teams you choose. Choose several values in one group to see any of them, and combine groups to see only items that match each.

An item belongs to a scope through its Task or the Task a proposal would create. A Goal also holds the Project proposals made for it, so the Goal filter lists as many proposals as the Goal's page shows waiting. Team filters follow the Task's current Team ownership.

An item belongs to an Agent when the Agent's Run raised it or the Agent implements its Task or the Task a proposal would create. The agent drawer opens this filter when you choose Open Inbox. Items without any of these links, such as workspace and billing notices, appear only when no filter is active.

In Triage the filter offers Projects, Goals and Member instead of Teams, and only where someone triages: a Project or Team with a lead, a Goal with such a Project or Team below it, and the Teams, Agents and people who lead them. It is the same filter as on the Tasks Triage page. A Project, Goal or Team you chose carries over when you switch views, and an Agent or person you chose in Triage stays there. Triage has no separate Agent group, because its Member group already lists the Agents that lead.

Each chosen value appears as a chip under the view tabs, with a button that clears them all. The badge counts and the order of the list do not change, so filtering never hides how much is waiting. Your filter stays while you close and reopen Inbox. Opening a specific item from another surface normally clears the scope so that item is in the list. Opening from the Tasks Triage overview carries its filters into Inbox instead, keeping the review navigation inside that selection. Choosing Review proposals on a Goal's page likewise opens Inbox on Proposals, narrowed to that Goal, and the Goal's chip shows under the tabs until you clear it. A dimension clears when you lose access to it.

For timed work, Priority uses the earlier of its scheduled start and its delivery target minus the Agent's latest estimate. This puts decisions needed to keep work on schedule ahead of decisions that can wait.

High and Critical icon badges identify urgent decisions in either sort. Hover, focus, or tap a badge to read its meaning, including the deadline or scheduled start in your timezone when timing makes it urgent. A folded group shows its most urgent child's marker. A blocked-work badge shows how many Tasks are waiting on the decision, and the same badges appear in the item's detail header. Task Machine assesses decision context in the background using workspace usage, and shares an assessment across recipients of the same decision. A new assessment can move a decision in Priority. In Newest, it only updates the badge.

When assessment is unavailable, including in EU-only workspaces or without funded usage, decisions start at Normal urgency and informational updates at Low. Decisions linked to an Urgent Task are always at least High. The same minimum applies when a delivery target or scheduled start is within 24 hours or has passed, or when the Agent's latest estimate no longer fits before the delivery target. Items that stop your Agents from running also have this minimum. These markers work without AI assessment and update while Inbox is open as timing or estimates change. Urgency helps you choose what to review and never approves or resolves a decision.

Completed and archived items are read-only history. Opening one from Actioned or an old notification preserves the context and decision state that were visible immediately before the decision, and its title keeps the names the records had when the item was created. Disclosures, copy controls, authorized previews, and optional links remain usable, while editable forms and controls that could change data are omitted. The footer keeps the buttons that open the item's records, such as View task or Open budget, and shows the outcome on the left, such as Approved with who decided and when.

The result and attribution remain visible, and no mutable task, pull request, proposal, or other source record is loaded to rebuild the historical view. One bounded exception applies to plan decisions completed without the deciding session's frozen projection, such as a plan approved on the Task page while its Inbox item resolved as a sibling: their full plan review is rebuilt from the plan revision the item itself references, which is immutable, so the Task's current plan content never rewrites what the decision was about.

Resolving an item raised in Chat does not start another turn in that conversation. Send a message when you want to continue discussing the result. Existing runs paused on credential or Connector authorization still recover after access is approved.

When several entries are about the same thing, the queue folds them together instead of stacking a separate row for each.

Everything that waits on one task collapses behind a single summary, whether it is a question, an approval or a mention. The summary reads like "Three items on OPS-125: Verify the launch checklist" and shows the Tasks icon with a count, so a burst of activity on one piece of work does not push everything else out of view. Related updates that are not about a task, such as one workflow, fold the same way and take the title of their newest item.

Work that a recurring schedule creates groups together too. A workflow that drafts support replies every morning creates a separate Task for each run, but the drafts waiting on you share one group named after the recurring Task, such as "Three items from the recurring Task Daily support replies", with a repeat icon. Its Group actions menu works on it like any other group's. A group's count always includes every waiting item in it, even rows the Inbox has not loaded yet, and the rest appear as you scroll the Inbox. Items that were already waiting when this grouping arrived stay with their own Task, and only new items join the series.

Proposals from the same Chat, Task, Goal lead, or Team check-in share a source group across Runs. Inbox keeps the individual proposals and their decisions inside it. Chat and Home show the same source together, and opening it shows the group review as a modal over the page you are on, without opening the Inbox drawer. On Home and in an Agent's drawer, several waiting items on one Task read as one row that names the Task and how many items wait, with the kinds of the items and how long the oldest has waited beneath it. Proposals without a shared source keep their individual entries.

When Agents create credentials for the same task or chat, those updates share one collapsed group across runs. Each credential keeps its own name, notice, and history. These updates are informational. Requests to approve credential access remain separate decisions.

Credential-creation updates with shared Group actions menus, and a credential access request outside the groups

Every group starts folded, whether or not it holds something you still have to decide, and the count on its icon tells you how many items wait inside. Every item in it keeps its own actions, and opening an item from a group opens that group, so a folded summary never buries the control that resolves it. An open group sits on its own slightly recessed surface, so you can see where it starts and ends in the queue.

The chevron right after a group's title opens it, and the title itself does the same, so a group reveals its items wherever you click along that line. You expand or collapse any group yourself, and that choice sticks as the queue refreshes around you.

Resolve a group together

Open a group's Group actions menu and choose Review to inspect its items together. When every item in the group is the same type, the same menu also offers that type's shared decisions, such as Approve, Reject or Dismiss, so you can decide the whole group without opening the review first. When the group contains different item types, Review is the only entry and you decide each type inside the review, where every type has its own named section and icon, with selection and compatible shared actions together. Choose the items before submitting that section's decision, or open an item for its individual decision. Each shared decision covers only the chosen type. An item that cannot take the chosen decision stays excluded with guidance to review it individually.

A mixed Inbox review with separate type sections, each with its own name, icon, waiting and decided counts, native items, and shared actions

The review is titled like the group, for example "Three items on OPS-125: Verify the launch checklist". Each item type is its own section whose heading counts what waits and what is already decided, such as "46 waiting · 4 decided". Its rows sit in one list with a checkbox in front, and decided items show their outcome.

Every captured waiting item that supports a shared action starts checked, including items not yet shown. Scroll to load more in their original order, open an item for its complete details and existing editor above the group review, or clear its checkbox to exclude it. The decision covers all selected captured items, not just the rows on screen. New arrivals require a new review.

An Inbox group review with every waiting item selected, checkboxes to exclude items, and rows that open each decision

Decided items stay with their type's history and outcome, and cannot be selected again. The item's side arrows stay within the captured group, including items not yet shown. Resolving an item opens the next waiting item without removing its decided row from the group. Resolving the last one closes only the individual item. Returning to the group review preserves your exclusions.

In a mixed review, rejecting or requesting changes opens a Reason window above the group. Your feedback applies only to the selected eligible items of that type. Close the window to return without requesting a decision. The review requires feedback when any selected request requires it.

Submit the decision to request it. In a mixed review, the section keeps its submitted state while you review the other types. A same-type review closes after confirmation. A message confirms the request, and Inbox stays usable while Task Machine handles the items. Each item keeps its own outcome and history.

Items that fail stay open and keep their individual actions. In a submitted group review, Retry failed items keeps the original selection and reason. Successful decisions are not repeated.

Workspace access notices

When someone gives your existing account access to a workspace, one notice shows who added you, the workspace, and your role. Your access is already active. There is nothing to accept.

A Workspace access notice naming the inviter, workspace, and Viewer role

This notice follows your account across your accessible workspaces. Dismiss clears it everywhere without removing access. Your first visit to the granted workspace also clears it everywhere, but reading the notice does not. Other Inbox work stays in its own workspace, and external MCP clients do not receive these account-only notices.

Move between open decisions

Open an item to read its complete decision in the modal. Use Previous inbox item and Next inbox item to move through the neighboring items of the open view, such as every decision in Triage, without closing it and returning to the list. Opening an item from a Task, Chat, or Home shows the view that holds it. A navigation control is disabled when there is no item in that direction.

After you successfully resolve an active item, the modal advances to the next eligible item in the queue. When the resolved item was at the end, the modal falls back to the last remaining decision. It closes only when the queue has no eligible items left.

Read the new item's context before acting. Navigation does not approve, reject, or dismiss it.

When you decide from an item's row menu, you stay in the list and no other item opens.

The modal's footer holds the item's decisions. When an item asks you to approve, reject, or assign, View task waits in the More actions menu beside those buttons. A Team thread that needs a teammate keeps View task beside Assign reply, so you can read the thread first. When something stopped, the button that fixes it leads, such as Retry repository, Run again, or Open budget, and View task stays beside it. An update that only keeps you informed leads with the button that moves it on, such as Open budget, Open skill, View usage, View credential, or View task. Dismiss is always in More actions.

If an item's details can't be loaded, the modal says so and offers Retry. Its decisions stay hidden until the details load, and More actions still lets you open its records or dismiss it.

When a lost connection returns, Inbox reopens the item you were reading and loads its current details if you still have access in that workspace. Unsaved edits are not restored, and an item you close while offline stays closed.

When a proposal changes existing text, removed words are struck through and added words are highlighted. Every changed value has two small icons in its corner that switch between the marks and the plain text. Hover an icon to see its name. Single-line values center them, longer values put them in the top-right corner, and each value has its own switch, which always starts on the marks, as Task specs describes for a plan.

A restore proposal shows the archived target, rationale, current state, and consequences with its permitted Approve and Reject actions in the same decision. No surface switch is required. Approving preserves the target's configuration and history. Unpublished Connectors still require setup, and unpublished Workflows return to draft. If another session restores or removes the target, Task Machine automatically skips the unnecessary request and closes its open decision. See Restoring archived records.

Set a Project's direction

When a Project's goals conflict, choose Follow or Ignore for each goal and Apply. You can leave a short note for the lead or choose Discuss to talk it through first. A discussion resolves nothing by itself. The lead proposes the agreed direction for review, and the original decision stays open for you.

The accepted direction replaces the Project's current default and reaches every agent starting work there. Earlier choices stay as examples, not binding rules. Applying the original decision after a discussion replaces the direction again. The completed item keeps the conflict, each goal's outcome, your note, who decided and when. Projects and goals explains how the default and later concrete decisions differ.

Decide from the keyboard

With an item open, press A to approve, R to request changes and D to dismiss it, and J and K to open the next and previous item. Press ? to show each key in a tooltip beside its button. A key appears only when the item has exactly one control of that kind, so it never picks between two decisions, and Reject and decisions that need your input have no key. A key presses the same button you would click, so permissions, confirmations and the Reason window work as usual, and keys never fire while you type.

Assign work waiting in a Team queue you lead

When a Task waits in the queue of a Team you lead, its item asks who should work on it. Choose a teammate, or yourself, and click Assign. The Task moves to that person or Agent, who is notified, and the item closes. The Task still counts toward the Team's cost and active time. Assigning needs permission to edit Tasks.

Like other decisions, the item is marked High and alerts you when its Task is Urgent or close to its deadline.

Place a Task that has no implementer

When a To do or In progress Task has had no implementer and no Team for a day, an item asks who should work on it. Choose a person, an Agent, or a Team and click Assign, or click Move to Backlog to park the Task until you are ready. Assigning needs permission to assign Tasks, and moving needs permission to edit them.

The item goes to whoever created the Task when they can assign it, and to a Workspace Owner otherwise. It closes when the Task gets an implementer, moves to Backlog, is finished, or is archived, so each Task asks once. Tasks in Backlog never raise it.

Read what happened

An update that keeps you informed says what happened in a sentence or two. Cards below it show the records involved, such as the Task, budget, skill, or credential, and the numbers that matter, such as spend against a limit or the date files are deleted. Click a card to open its record. A card for the page you already have open is left out.

An item about something that stopped leads with a warning that says what stopped, followed by a sentence on how to move on. Its cards show the Task, Run, Worker, or schedule involved, and a failed Run shows its last output and activity below them.

A task update shows each change under its own heading, with the earlier value struck through and the new value highlighted. It covers the status, title, description, priority, and due date. When an approved plan changes the acceptance criteria, the update shows that too, unless you approved the plan yourself. A very long description only shows that it changed, so open the Task to read it.

Recover after a Local usage limit

While AI subscription usage insights are on, a Local Worker's usage-limit item completes by itself when Task Machine sees that provider's subscription reset. It also offers Retry now to people who manage the Workspace or its Agents. After restoring provider access or changing accounts in tamacode, use it to clear Task Machine's waiting period and request recovery for eligible interrupted assignments.

A rate-limit Inbox item showing when work can resume and the Retry now action

The item is marked retried once Task Machine accepts the request. Provider quota, manual Worker pauses, Workers disabled for Agents, budgets, capacity, and Task approvals remain unchanged. A new provider limit can pause work again. Workers explains the recovery boundaries.

Notifications return to the decision

An in-app alert appears only when an item first reaches High or Critical. Routine decisions and updates wait in the Inbox and badge. The alert shows the item's title with kind, urgency, and blocked-work icons. Open it to review that exact item in the Inbox drawer without leaving your current page, with reasons, dates, and blocked-work counts available inside Inbox. It never makes the decision for you.

High and Critical items email you right away. Other enabled emails arrive together in your summary, and browser alerts wait briefly to group related activity. Before sending, Task Machine removes Inbox items you have read, handled, or seen in an in-app alert. If you handled part of a group, only the remaining items are sent. An item becoming urgent later does not send another browser alert. Invitations and sign-in messages keep their separate delivery rules.

When a changed pull request replaces its review, the new review alerts you again only if you had not seen the earlier one or it is more urgent than the one you saw.

While you have a task or Chat conversation open in a background tab or unfocused window, its browser tab title counts new Inbox items addressed to you in that Workspace, comments on the open task, and messages in the open Chat. For example, (3) Chat · Launch planning · Task Machine means three new items arrived while you were away.

The count starts with new arrivals rather than your unread backlog. A comment and its matching Inbox notice count once, and your own comments and messages do not count. Returning to the page clears the count without reading or resolving Inbox items.

Each email links back to the Workspace Inbox and contains only what you may see.

Choose how often summary emails arrive in notification settings. New accounts start with two summaries a day, at 08:00 and 16:00 in the timezone set in account settings. Non-urgent emails wait until 07:00 if they would arrive overnight. Change the frequency or timezone at any time.

The Inbox updates live

The Inbox reflects the workspace as it changes, without a reload. When an agent asks a question, finishes a task, or hits a failure in Cloud or on a Local Worker, 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 active queue and counts update as requests arrive or resolve.

To inspect the work behind an item, see Tasks for the record they point into and Comments and attachments for how discussion on a task turns into attention here.

Read Proposals, Questions and approvals, and Setup and recovery for the decisions you will encounter.