Which agent inbox? The term means two things
Some products give an agent its own email address: an inbox the agent owns and reads. That’s a real feature, and a different thing. The agent inbox defined here points the other way. It’s the queue a person owns. Many agents feed it, but only what needs a decision lands there.
Run six agent sessions in parallel and the checking-in becomes its own job. The pattern keeps recurring because the need is structural: once agents run unattended, something has to hold what they’re asking until a person can look.
Why do unattended agents need an inbox at all?
Supervision doesn’t scale by adding tabs. One agent with a question is a notification. Ten agents across nights and weekends are a monitoring job, and the moment you’re doing that job in six terminal panes, the agents aren’t really unattended. You’ve hired yourself as their assistant.
Agents produce work in parallel now, and the people who have to judge it still decide one item at a time, so the backlog has to land somewhere. Without a designed place for it, it lands in whatever surface is nearest: Slack pings, or a dashboard someone builds on a weekend. Neither gets checked on the same schedule, so things wait longer than anyone meant them to.
What belongs in an agent inbox?
Fewer land there than you’d think. The discipline that makes an inbox work is the same one that makes an on-call pager work: if everything pages, nothing does.
- Held gates. Steps a human approves every time, by design: merging a change, or touching production.
- Budget stops. A run that hit its budget cap and paused warm: it holds its work and waits for a yes or no.
- Genuine blocks. The run met something outside its instructions and stopped instead of improvising. That stop is what lands in the inbox.
- Split verdicts. A review panel that disagreed past your threshold. Consensus proceeds on its own. Disagreement is what needs a person’s review.
What doesn’t belong: routine progress, and retries that already succeeded. Those go on the record, readable when you want them. The inbox holds decisions only.
An item’s life is short: created when a run hits one of these, ranked against whatever else is already waiting, claimed by whoever opens it, decided or left to expire, and recorded to the run’s receipt either way.
What does a good inbox item look like?
A good inbox item carries the evidence needed for a decision. Call it the evidence packet: the same seven fields, whatever kind of run produced it.
| Field | What it holds |
|---|---|
| Request | What the run is asking permission for |
| Affected system | What changes if you approve it |
| Prior actions | What the run already did to get here |
| Spend | Tokens and dollars this run has spent so far |
| Proposed decision | What happens next, in plain terms, if you say yes |
| Approver | Who this is routed to, and why they’re the right person |
| Expiry | What happens if nobody decides in time |
If the reviewer has to open three other tools to find any of that, the inbox didn’t do its job; it just relocated the tab problem.
The run that files an item usually knows more about what it did than the person deciding what happens next, and it writes in its own register. A packet that quotes that register makes the reader translate before they can judge, so the item does the translating first: the scenario in plain language, the actual question, a recommendation, and the condition that would make that recommendation the wrong call.
Batching matters more as volume grows. Ten near-identical approvals should arrive as one decision with ten instances. And ranking should follow blast radius, money and production first, style questions last, so that a full inbox on a busy morning still gets the dangerous item seen first.
How is this different from notifications or a dashboard?
Notifications interrupt; they’re pushy and stateless, and past a handful a day they train you to ignore them. Dashboards inform; they’re pull surfaces you have to remember to check, and they show status rather than asking for anything. An inbox is a work queue: items hold their state until a person decides. That doesn’t make it another tab to check: you can subscribe to an item and get it delivered where you already work, through Slack, Telegram, WhatsApp or a webhook. The decision itself stays one thing in one queue, whether it’s claimed, pending or resolved. Delivery reaches you; the inbox keeps the state.
The nearest ancestors are code review queues and on-call escalation, and the inbox borrows the best property of each: review’s evidence attached to every decision, and on-call’s rule that a page should mean something.
Where does the inbox sit in a control plane?
The inbox sits downstream of the gates and upstream of the record: it only holds what a gate or a budget stop already produced, and what happens to it becomes part of the run’s history. Sumn is a control plane for unattended agent work. On Sumn, this queue is the attention inbox. Its playbook stages declare their gates: judged gates, where a model applies criteria you wrote and the run proceeds on a pass, and held gates, where a person releases it, every time. Held gates and budget stops are what feed the attention inbox.
Two things sort what reaches the inbox: who has to make the call, and whether the check repeats. Deterministic checks come first, the tests and linters a team already runs: the same input gives the same verdict, so a failing test today fails the same way tomorrow and never needs a person. Judged gates take what no rule can express, where a model applies your criteria; because that verdict can shift between runs, it lands with its evidence. Held gates keep the decisions that stay human no matter what passed below. Each layer filters for the next, so the inbox holds only what genuinely needs a person.
Every decision made there becomes part of the run’s record: who decided it, and what the item showed them. A week later, that record is still there to trace.
That wiring is why the inbox depends on the gates being real. The stop is enforced by the runtime executing the stage; a prompt can only describe it. For everything else a run needs before it’s trusted with production, from scoped credentials to checkpoints, see the agent production checklist.
The inbox is where delegation starts, not where it ends. As a team’s verification gets real, whole classes of inbox decisions can move down to a supervisor agent, and a person reviews only what it escalates. That move is earned. It grows out of the team’s verification work: tests that catch regressions, checks a model can be trusted to run. Build those first, then delegate the decisions they can verify.