What you are trying to do
Your team keeps making decisions in places where the decision later vanishes. A judgement call in a Slack thread that scrolls off. A "let's just" in a stand-up that nobody captured. A pull request comment that an engineer interpreted one way and the PM another, both convinced they remembered correctly.
The Inbox is where those decisions land instead. It is not a notifications feed. It is the small set of items Ship routes to you — most handled through your agent, the destructive ones through the /approve page.
What lands here, and what does not
Items split into three tiers, and we are deliberate about keeping each one short.
Needs you (Tier 1). Clarifications an agent raised mid-flow that need your answer, and approvals — gated steps waiting on an explicit go-ahead before they proceed. These are the items where the run is paused on you.
Autonomy escapes (Tier 2). Failures a run could not auto-recover from, blockers where recovery failed and the work needs human follow-up, and exceptions — policy or routing edge cases that bypassed automation. The engine tried; now it needs a person.
Later (Tier 3). Improvement signals land when the same pattern of trouble has shown up more than once and is starting to look like a real problem rather than a one-off — for example, three tickets in a row skipped the code-review stage because a specialist had no fallback. Stuck work lands when a ticket or pull request stops moving on its own — idle 24 hours or more, or frozen on an unresolved dependency. Dispatch is event-driven, so a stuck item means the event chain stalled and only a human call will restart it. Reports land on a predictable schedule — your daily digest, the weekly audit, a snapshot you asked for. Reports are read-and-acknowledge; the daily retro is just a report carrying a checklist of yesterday's action items.
What does not land here: progress pings, status updates, "I started the run," "the run finished," routine state transitions, comments on tickets you do not own. Slack and the tracker timeline already do that work, and a notifications feed that pings you on every state change is just background noise wearing a fancier name.
What it looks like on Monday morning
You no longer browse the Inbox in a web tab. You ask your own agent — "what needs me today?" — and it calls Ship over MCP (inbox_list), pulls the open items, and walks you through them: answer a clarification, approve a gated step, dismiss a digest.
The console keeps exactly one inbox screen, /approve/{id}, a deep-link for a single item that lands when Ship needs an explicit web confirmation — a destructive approval, or a Telegram/MCP hand-off. Pending approvals also surface on the operator hub's "Waiting on you" strip.
Three or four items, three or four calls, from inside the agent you already work in. Day starts.
Why this is decision work, not a feed
A feed is something you scroll through hoping not to miss anything. The Inbox is the opposite. Every item is here because it needs you, and every item leaves the moment you have made the call. If your agent keeps handing you a long list, the Inbox is broken — too much noise has been routed in, and the filter needs tightening.
Ship will surface that a ticket is stuck. Ship will not tell you whether to unstick it by talking to a customer, by reducing scope, or by killing the ticket. Those are your calls. The Inbox is the surface where they happen and get logged.
What this changes about your week
Decisions stop vanishing into Slack threads. Every time you resolve an Inbox item, the call is recorded — what you decided, when, on which ticket. Three weeks later, when somebody asks "wait, who decided to kill that feature," the answer is one query away.
You also stop being the person who keeps a mental list of what needs your attention. The list lives in the Inbox now, and you reach it by asking your agent. If it is not in the Inbox, it does not need you this morning.