How are humans supposed to know a task is waiting on them?
NickyDigital · 2026-06-21
When an agent needs me (a confirmation, a question, a sign-off), the task moves to In Review and the agent waits. But nothing tells me it's waiting — it doesn't hit my Inbox, doesn't reassign to me, just stays on the agent. Unless I happen to click into that exact card, I never find out. I've had several tasks sitting blocked on me without knowing.
Am I missing a setting/notification toggle for this? Or is that just how it works right now?
If I'm not missing anything — how is a human supposed to know a task is waiting on them? From what I can tell the Inbox only surfaces failed runs, join requests, approvals, and alerts. A plain agent→human question or confirmation isn't any of those, so it pings nothing.
Suggestion: add a "Waiting on you" section to the Inbox — every task where an agent paused for human input. Like the approvals count, just widened to cover these questions/confirmations. Then the Inbox is the one place I check for "what needs me," instead of hunting through the board.
Happy to send task IDs where it bit me.
Answers
Aron Prins · 2026-06-21
Good catch — and you're not missing a toggle, you're missing a tab.
When an agent pauses for your input, the issue does stay on the agent (you're right about that), and it won't reassign to you or fire an email. But it isn't silent: it surfaces in the Blocked tab of your Inbox, which sits next to Mine / Recent / Unread / All. That tab is the "what's stopped and needs a human" view, and its badge changes colour by severity, so a question sitting on you will light it up.
Your exact case — an agent asking you a direct question — shows there as a Needs decision chip, labelled "Pending user decision" with an Answer question action. Board-level confirmations and sign-offs land in the same tab as "Pending board decision." So the "Waiting on you" section you're describing already exists; it just lives in the Blocked tab rather than in the main Inbox counts.
Docs: [Blocked Inbox](https://docs.paperclip.ing/#/guides/day-to-day/blocked-inbox).
Two honest caveats:
It's a pull model. No push notification or email yet — you do have to glance at the Blocked badge. Bookmark /inbox/blocked and it becomes your one "what needs me" stop. It only lights up if the agent asked a structured question. If an agent just flips the task to In Review and stops without registering an actual question or confirmation, it can land under "Review without action path" (a "Needs attention" chip) instead of "Needs decision" — or, worst case, not stand out. That's my bet for the tasks that went quiet on you.
Please do send those task IDs. Whether they showed as "Pending user decision," "Review without action path," or nothing at all tells me whether this is a wrong-tab thing or a real gap in how those agents paused — and those are very different fixes.
NickyDigital · 2026-06-21
Thanks @aronprins — I dug in, and the catch is they're not landing in Blocked.
Every one that bit me is status: inreview, not blocked, each with a registered pending interaction. Because that interaction is a valid action path, the liveness sweep never demotes them to blocked — so they're not "Review without action path" either.
They sit in a fourth bucket your three didn't cover: inreview with a live pending human interaction → surfaced nowhere (not the Blocked tab, not the badge).
Task IDs + what each is (all on my instance, so the IDs won't open for you — happy to pull any thread/run detail you want and send privately):
PIC-267 — inreview, askuserquestions pending → not in Blocked PIC-302 — inreview, requestcheckboxconfirmation pending → not in Blocked PIC-313 — inreview, 2× requestconfirmation pending → not in Blocked PIC-333 — inreview, assigned to me, no interaction → not in Blocked PIC-305 — inreview, requestconfirmation pending + a linked approval. The approval shows in the Inbox approvals count, but the issue itself never appears in Blocked.
Root of it: the sidebar Inbox badge is failedRuns + alerts + joinRequests + approvals — pending thread interactions aren't in that sum, and the Blocked tab keys on status = blocked, which these never reach. So an agent that politely raises requestconfirmation / askuserquestions on an inreview issue waits indefinitely with zero signal.
I went ahead and built a fix — PR <https://github.com/paperclipai/paperclip/pull/8447> :
Counts pending agent→human interactions (requestconfirmation, askuserquestions, requestcheckboxconfirmation,\ suggesttasks) into the Inbox badge New GET /companies/:id/awaiting-human-interactions endpoint A "Waiting on you" Inbox section listing each ask, linking to the issue, reusing the existing dismissal flow Tests included; Greptile review addressed; CI green except one fork-only lockfile-artifact flake
Would love your take — happy to adjust placement (it's on the Mine tab now) or fold it into the Blocked tab instead if that's the model you'd prefer.