Action Required
Action Required is where work returns to you.
When an agent finishes something that needs a decision, or hits something only a person can do, it lands here rather than waiting silently on a page nobody has open.
It spans every loop and every project. Reviewing a document, approving a plan, reading a pull request and granting a cloud permission all arrive in the same place, which is why it is worth checking before anything else.
It belongs to the team, not to you
Section titled “It belongs to the team, not to you”The inbox is shared. Anyone with access can pick an item up, and resolving one clears it for everybody.
This is deliberate. An agent waiting on “someone” should not be blocked because the one person who happened to trigger it is on holiday.
Items you act on are recorded as done or dismissed, and the resolved view keeps that history.
Two kinds of item
Section titled “Two kinds of item”Things to review. A plan, a set of initiatives, a document, a pull request, or maintenance findings. Each is a decision an agent has deliberately handed back rather than made for you.
Things to set up. Work an agent cannot do because it needs credentials, an account, or access that only a person holds: an environment variable, a secret, a third-party service, a DNS record, billing approval, or a cloud permission.
Setup tasks carry a plain statement of why they are human-only. If you are wondering why the agent did not just do it, that field is the answer.
Setup tasks are ordered by when they block you
Section titled “Setup tasks are ordered by when they block you”They are grouped into three phases rather than listed flat, because doing them in arrival order means doing optional work before the thing stopping your build.
| Phase | What is in it |
|---|---|
| Before the build can start | Credentials, accounts and infrastructure a build needs to run for the first time. |
| Wire build outputs | Connecting generated values back to providers: paste, configure, register. |
| Optional follow-ups | Billing, alerts and polish you can come back to after launch. |
Within a phase, work for the same provider is grouped, so you visit each console once.
A setup task gives you the value to use, a copy button, and a link straight to the provider’s console or documentation. Where a value is secret it is handled as one.
Clearing the inbox
Section titled “Clearing the inbox”Three ways to make an item go away, and they mean different things.
- Mark done. You did it.
- Dismiss. It does not apply and is not going to.
- Snooze. Not now. An hour, until tomorrow, or a week.
Snooze is the one people skip and then regret. An inbox where every item is either urgent or permanently ignored stops being read at all.
You can select several items and resolve them together, search, and filter to one project. Keyboard shortcuts move through the list without reaching for the mouse.
Who can act
Section titled “Who can act”Resolving an item, including completing a setup task, needs the same permission as doing the work: members, admins and owners can. Viewers see the queue but cannot clear it.
That matches the rest of the product, and it is worth knowing before you ask someone with read-only access to unblock a build.
