[Feature RFC] Agent inbox board: one place for tasks, approvals and failures (personal first, team second)

Why

Users run several bots and today see approvals and progress scattered across the sidebar, approval badge and chats. An Agent inbox board gives one view of what needs me, what is running, and what is done. Inspiration: a three-column agent inbox board (NEEDS YOU / RUNNING / DONE) with per-card elapsed time, tool-call count and an Open button for human-gated tasks.

Draft for discussion. Not a commitment to scope; design review wanted from the team before implementation.

Scope

Phase 1: personal

Board with three columns: Needs you (pending approvals, failures), Running, Done; plus a List view toggle.
Card: bot, task title, one-line latest activity, elapsed time, tool-call count, primary status.
Approve / reject from the card, reusing the existing Bot Social approval flow (no second approval path).
Data in phase 1: approvals and in-progress conversations. Task cards wait for the task layer.

Phase 2: team

A manager assigns work to specific colleagues, so ownership is about who is responsible, not whose bot it is.

Assigner: assigns the task, sees progress of what they delegated.
Owner (responsible person): task appears in their Needs you; they approve.
Executing bot: does the work; may belong to the owner or someone else.
Views: Assigned to me / Assigned by me / Team overview. Reassignment is allowed and each handoff is audited.

Data model rule from day one

Every card carries assigner, owner, executingBot. In personal mode all three resolve to the user, so phase 2 adds assignment and permission filtering without redoing the UI.

Dependencies

Team mode via groups: task layer step 1 - responsible-owner authority, FLYBOT-TASK envelope, workBotId #149 task layer step 1 (responsible-owner authority, FLYBOT-TASK envelope, workBotId)
[Team] Gate cross-owner agent routes by per-Bot grants (default deny; superseded the publication gate) #51 per-Bot grants, default deny (who may see or act on whose tasks)
[Team] Recover task handoffs without duplicate work #55 handoff recovery without duplicate work
[Team] Bound agent loops and resource consumption #56 bounded loops and resource use
[Team] Add a human-readable authorization and task audit trail #57 authorization and task audit trail
[RFC] 跨运行时 Agent 对话与协作：以 OpenCode 为首个试点的目标、需求与两种方案 #198 cross-runtime collaboration RFC (status data from non-FlyBot runtimes)

UI guidelines (acceptance)

Copy: one word per action; no duplicate labels (cf. Social UI polish round 3: truncation, duplicate Add friend/Accept invite, Manage access depth, wording (#166 follow-up) #173, Social UI polish: duplicate settings labels, Sharing layout, Create Bot back/default model, native Remove confirm, Auto-send label, account menu truncation #230); consistent zh/en.
Status: exactly one primary status per card, color plus icon, never color alone; failed cards show the reason.
Approvals: state what will happen in plain words (e.g. runs on production); confirmation feedback after approving; reject is confirmable or undoable; no native browser/OS confirm dialogs.
Layout: long titles truncate with full text on hover; no truncated account menu; narrow windows fall back to List view.
Empty states and hints: each column has a one-line empty message; first run shows a short guide.
Consistency: avatars and titles identical across homes (cf. Face-to-face: avatars and room title differ per home (regressions of #137/#172); Leave is abrupt and not seen by the peer #182).
Accessibility: keyboard reachable cards and actions.

Out of scope for now

Cross-team visibility beyond granted Bots.
Auto-approve rules.
Any change to the approval security model.

Open questions for discussion

Is Done retained forever or aged out (e.g. 7 days)?
Can an owner delegate approval, or only the assigner reassigns?
Should failures notify, or only appear in the board?
Where does the board live: sidebar entry, top-level page, or both?
How are tasks from non-FlyBot runtimes ([RFC] 跨运行时 Agent 对话与协作：以 OpenCode 为首个试点的目标、需求与两种方案 #198) represented?

Process

Per team rule: implementation via cloud OpenCode, review via Codex; no hand-written code from bots.

Child RFC: 401 merged output digest and acceptance (#401).

Owner decision (2026-10-19): Approvals must never be given by the user replying with a chat message. Approving or rejecting happens only through explicit UI controls (buttons on the approval card / board card), reusing the existing Bot Social approval flow. Typed replies must not count as approval.

Document the agent operating model in AGENTS.md (ThinkFlowLab#414)

Triage on main 7b9e90b, 2026-10-19 ~12:10 Asia/Shanghai: needs-human, not agent-ready. Recorded constraint: approvals only through explicit UI buttons (owner decision 2026-10-19). Still open: the owner has not approved Phase 1 scope (columns, card fields, where the board lives in the UI, data sources). Question for the owner: approve Phase 1 as written (personal board: Needs you / Running / Done, approve and reject buttons reusing the Bot Social approval flow), or narrow it first?

Extend a paused friend chat in FlyBot, approved on the chat's card (T…

Show a Share this Bot? card on share.requested; tell the sender a ref…

Triage (maintenance, 2026-10-20 08:04 Asia/Shanghai)

Checked on main a45fc8c. There is no board yet. The building blocks exist:

pending approvals in the work snapshot (work.approvals, with DSH's card in a Bot's chat and the overlay for groups)
per-row Working / Waiting for your approval in the sidebar
task records with open/working/blocked/result-ready/accepted/failed (core/src/host/tasks.js, [Team] Persist a minimal collaboration task lifecycle #54)
approval notifications (approval-notices.js)

Recorded constraint, kept: approvals happen only through explicit UI buttons, never typed replies.

Expected behavior (phase 1, personal)
One Inbox view of my own Bots:

Needs you: pending tool approvals with Approve / Reject, plus failed turns and tasks with their reason
Running: Bots working now, with elapsed time
Done: finished in the last 7 days

Each card has exactly one status and an Open button to its chat.

First slice (smallest shippable step)

A list view with the three groups, built from data that already exists (work.approvals, running state, task records). No new host state.
Approve / Reject on the card call the same approval answer the chat card uses, so there is no second approval path. Feedback is shown after the click, with no native confirm dialogs.
Empty line per group, keyboard reachable, long titles truncated with the full title on hover.
Tests and a docs/subsystems/core-client.md entry. The three-column board and the tool-call count come in slice 2.

Details I decided (say if you disagree)

Held Bot messages (a Bot's reply or message waiting to be sent) show in Needs you with Open only. Bot-sent messages stay approved in the chat by the owner, not from the board.
Only my own Bots. Friends' Bots, a granted Bot's downstream and team views (assigner/owner/executingBot filters) wait for [Team] Gate cross-owner agent routes by per-Bot grants (default deny; superseded the publication gate) #51/Team mode via groups: task layer step 1 - responsible-owner authority, FLYBOT-TASK envelope, workBotId #149. The data model keeps assigner/owner/executingBot, all set to me for now.
Done ages out after 7 days. Failures show on the board, and the push for them is Proactive reminders 1/3: event reminders (approval waiting, failed, finished) in app and desktop #353 (one event source).
Non-FlyBot runtimes ([RFC] 跨运行时 Agent 对话与协作：以 OpenCode 为首个试点的目标、需求与两种方案 #198) are out of scope for phase 1.

Question for the owner
Where does Inbox live: (a) one Inbox row at the top of the sidebar with a count, opening a page; (b) only in the account menu and command palette, like Scheduled tasks; or (c) a header icon with a count? Also: is this slice (list view, existing data, same approval buttons) OK as phase 1?
Recommendation: (a). No new + menu entry and no new sidebar section, just one row.

Owner decision (2026-10-20): Confirmed option (a): Agent inbox step 1 — three columns Need you / In progress / Done, existing data only, owner's Bots only, Done kept 7 days; approvals still use the same in-chat buttons. Entry: a top sidebar Inbox row with a count badge.

Claimed by maintenance run (2026-10-20 08:55 Asia/Shanghai), branch feat/349-agent-inbox on Birfy/FlyBot, following the Owner decision above.

Minor decisions for step 1 (PR #472), 2026-10-20 09:06 Asia/Shanghai:

Group names: Needs you / In progress / Done. The decision text says "Need you"; I used the triage's grammatical "Needs you", and "In progress" from the decision instead of the triage's "Running".
Where it opens: the Inbox row opens a dialog over the conversation (like Memory), not a Settings page, so Inbox is not a settings entry. Badge = number of Needs you cards.
Approve / Reject on the card only for approvals the group chat's card answers (answerable), with the same labels as that card (Reject / Allow once) and the same answerApproval call. An approval in a Bot's own chat is answered by DSH's card there, so its inbox card has Open only. Held Bot messages have Open only (Bot-sent messages are approved in the chat).
Tasks: failed, blocked and result-ready go in Needs you (with the reason / question / summary); open, claimed and working go in In progress; accepted and cancelled in Done. Task cards have Open only (task actions are later).
Done also lists my Bots' chats whose last turn finished in the last 7 days, with their last line as title, newest 20. Failed tasks age out after 7 days too, since nothing dismisses them.
Failed turns with no task record are not shown: there is no host record of them, and adding one would be new host state. That goes with Proactive reminders 1/3: event reminders (approval waiting, failed, finished) in app and desktop #353's event source; listed in Agent inbox phase 2: board view, tool-call counts, failed turns and team views (after #349) #471.
Held message in a friend's chat counts: it is my Bot's message waiting for me. A friend's Bot's own work never shows.
Deferred scope filed as Agent inbox phase 2: board view, tool-call counts, failed turns and team views (after #349) #471 (needs-human).

Add Agent inbox step 1: Inbox row with Needs you / In progress / Done (…

Cleanup: Agent inbox step 1 shipped (see #491 / related). Removing stale agent-working and assignee.

Navigation Menu

Repository navigation

[Feature RFC] Agent inbox board: one place for tasks, approvals and failures (personal first, team second) #349

Why

Scope

Phase 1: personal

Phase 2: team

Data model rule from day one

Dependencies

UI guidelines (acceptance)

Out of scope for now

Open questions for discussion

Process

Triage (maintenance, 2026-10-20 08:04 Asia/Shanghai)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Feature RFC] Agent inbox board: one place for tasks, approvals and failures (personal first, team second) #349

Description

Why

Scope

Phase 1: personal

Phase 2: team

Data model rule from day one

Dependencies

UI guidelines (acceptance)

Out of scope for now

Open questions for discussion

Process

Activity

hsliuustc0106 commented on Oct 18, 2026

Birfy commented on Oct 19, 2026

Birfy commented on Oct 19, 2026

Birfy commented on Oct 20, 2026

Triage (maintenance, 2026-10-20 08:04 Asia/Shanghai)

Birfy commented on Oct 20, 2026

Birfy commented on Oct 20, 2026

Birfy commented on Oct 20, 2026

Birfy commented on Oct 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions