What you are trying to do
You want to ask your Inbox and instantly know which items need a quick decision, which are reports to read, and which are signals to think about later. Mixing those three together is what makes most notification systems unusable. Sorting them by type and tier is what makes the Inbox actually work.
Every Inbox item in Ship carries a type. The type tells you two things at once: what kind of thing this is, and what it expects from you. The types group into three triage tiers — needs-you first, then autonomy escapes, then later — and your agent returns them in that order.
The item types
Needs you. Clarification — an agent's question for you, raised mid-flow when it would rather ask than guess. Approval — a gated step needing an explicit go-ahead before it proceeds. These pause a run on you.
Autonomy escapes. Failure — a run that could not auto-recover. Blocker — recovery failed and the work needs human follow-up. Exception — a policy or routing edge case that bypassed automation.
Later. Improvement is filed when an agent noticed a pattern — not one instance, but a repeat — that points at something worth changing. The most common shape is "orphan tickets skipped at stage code_review" with a count attached: one tracker project had five tickets miss the same stage. An improvement is rarely urgent today, but it usually deserves twenty minutes this week. Stuck work is filed when a ticket or pull request has been idle 24 hours or more — "PR #213 — no activity 24h+"; the right next step is usually to open the linked pull request and either nudge it, close it, or take it on yourself. Report is filed on a schedule — the daily digest, the weekly audit, a snapshot you asked for. Reports are read-only; acknowledging one is your way of saying "I have read this and I know where we stand."
The daily retro is not a separate type — it is a report flavour. The morning digest is a report item that carries yesterday's action items as a checklist, so the retro and the digest are the same kind of thing.
How items get here
Most items are filed by the engine and its scheduled jobs: the daily digest writes the morning retro, the weekly audit writes the assurance report, and the event-driven dispatcher — not a self-heal cron, those were retired — surfaces stuck work and failures as runs stall. Some are filed by specialists mid-flow when an agent hits a dead end and would rather raise a clarification or an exception than guess. And you can file your own item from your agent via inbox_create when you want to leave a note for tomorrow-you.
Whichever filed it, the type tells the truth. There is no "miscellaneous" bucket — if something does not fit one of the types, it does not belong in the Inbox.
How items get routed away from you
Items carry an owner, so you can ask your agent for just yours — "my open inbox items" maps to the Mine filter on inbox_list; Unassigned and All open are the other two ownership scopes available to admins. Workspaces are isolated: items are scoped to the workspace you query, so one team's work never leaks into another's.
Routing also happens implicitly. An improvement signal about a pattern in repo A references repo A so anyone who owns it can see it is theirs. A stuck-work item names the pull request, which names the author, which names the owner.
What this changes about your week
You do not scan a wall of chips in a tab. You ask the agent what needs you, and it returns the items typed and ranked by tier — needs-you first (clarifications and approvals that pause a run on you), then autonomy escapes (failures, blockers, exceptions), then later (improvements, stuck work, reports). You spend less time deciding which item to read first because the tier already told you — and the Inbox stops being a thing to dread and starts being a thing you finish.