feat(email): Triage Dashboard — daily-driver surface (umbrella)

[itomek]

Why this matters

Today the Email Triage Agent's user-facing surface in the Agent UI is a chat. A user types "Run a pre-scan", the agent calls the tool, returns a typed envelope, and the chat surface renders an inline triage card. That card carries the right information and the right action affordances — but the frame is wrong for the actual user we're targeting.

The target user receives 100–500 emails per day at a director / VP / senior-IC level. Their question every morning is "what needs me right now?" — not "let me have a conversation with my email." A chat-with-agent surface forces them to drive the agent verbally for every action; that's barely better than driving Gmail directly. The right frame is a task-tracker dashboard that the agent populates with surfaced items, drafted replies, learned preferences, and overnight summaries — items the user reviews and approves, not items they have to ask for.

This umbrella tracks the build of that dashboard surface, sized so a v0 is dogfoodable in a few sprints and the full vision lands as memory + multi-model + event-trigger work matures.

Scope change based on feedback

This issue captures a deliberate scope shift for the Email Triage Agent's user-facing surface. PR #995 shipped the engine (typed pre-scan envelope, inline action buttons, deterministic structured-render hook) inside the existing chat surface. Live-driving the chat surface against a real inbox surfaced the limitation: it's a power-user tool, not a daily-driver. The dashboard surface is the new direction; the chat surface is preserved as a verbal-drive entry point for power users. Engine code is reusable as-is.

POC flow this dashboard fulfills

A 5-step product flow informs the build order:

1. Context sources — inbox + calendar; messages later.
2. Event triggers — meeting ends, new email arrives, scheduled cadence.
3. Agent reasoning on local hardware — local LLM via Lemonade; eventually NPU-accelerated.
4. Outputs in task tracker — items have explicit state (in progress / drafted / summarized) and live somewhere persistent the user can browse without re-running the agent.
5. Human approval / execution — approve drafted reply, accept invite, copy summary.

What's shipped today only partially covers steps 3 and 5. The dashboard delivers step 4 and the surface around step 5; steps 1 and 2 land progressively.

Build order — fastest dashboard visibility first

Sub-issues are intentionally ordered so a visible dashboard surface lands as early as possible, even if its data is sparse, so we can dogfood the frame and let real-use friction drive the rest. Per direction received in the scope change, event triggers and local NPU acceleration are sequenced last — both are high-leverage but neither blocks the dashboard from being usable.

#	Issue	What lands	Visible?
1	#1008	Dashboard route + 3-column skeleton	✅ Yes — empty surface, but visible immediately
2	#1009	Wire pre_scan_inbox + Refresh button	✅ Real triage data populates the Surfaced column
3	#1010	In-session task store + state machine	✅ Items move through columns as user acts
4	#1011	Drafted column with Send/Edit/Discard	✅ "Agent does work, human approves" loop
5	#1012	Calendar items column with RSVP	✅ Calendar decisions in same surface
6	#1013	"Learned this session" preferences strip	✅ Trust-arc visibility loop
7	#1014	Migrate task store to persistent memory	Dashboard upgrades to "real" daily-driver
8	#1015	Streaming progress UI for long jobs	Dominant friction reduction
9	#1016	Background watcher / event triggers (deferred)	Always-on assistant
10	#1017	Local NPU acceleration for classifier (deferred)	Sub-second inference

Sub-issues 1–6 together produce a dogfoodable dashboard. Sub-issue 7 makes it honest as a daily driver. Sub-issues 8–10 take it from "manually-triggered snapshot" to "always-on assistant" without changing the user-facing surface.

Dependencies

• Memory subsystem — required for #1014 and everything after; the in-session store works as a stand-in until then but a daily-driver dashboard needs persistence to claim "Drafted overnight" honestly.
• Multi-model parallelism (#1000) — required to bring tier-1 classification down to sub-second so a background poll cadence is viable. The dashboard works without it; it just won't refresh autonomously at low cost.
• Connectors framework / Google OAuth (already merged: #915, #926).

Acceptance for the umbrella

• Dashboard surface is selectable when the Email Triage agent is active (route or tab inside the Agent UI).
• A user can land on the dashboard, click Refresh, and see categorized email items with action buttons within one minute of opening it.
• Drafted replies, calendar items, and learned preferences each have their own surface; none require chat-driving.
• All approval flows (send draft / archive / RSVP / etc.) reuse existing TOOLS_REQUIRING_CONFIRMATION gating.
• All email body content remains processed locally — no cloud calls for body inference, consistent with the parent agent's local-only architecture.
• Dashboard surface is the default landing surface for the Email Triage agent once items 1–6 land; chat surface remains accessible.

Refs

• Parent agent umbrella: #645
• Engine PR: #995
• Dependency: #1000 (multi-model parallelism)
• Provider track: #963 (Outlook/Exchange)

[github-actions]

Thanks for filing this — the scope shift reads well, and ordering the build so a visible dashboard surface lands first (even with sparse data) is exactly the right way to dogfood the frame before optimising the data behind it. A few grounded notes from the codebase as you file the sub-issues:

🟡 Wording on the engine PR. #995 is still open, not merged — "shipped the engine" reads as past-tense in the body. Worth softening to "introduced" / "in review" so the umbrella doesn't claim landed work that's still under review.

🟢 Existing reuse points for the sub-issues, so they don't accidentally re-invent:

• TOOLS_REQUIRING_CONFIRMATION is already wired in src/gaia/agents/email/agent.py and applied per-tool in tools/reply_tools.py, tools/delete_tools.py, tools/calendar_tools.py — the dashboard's send/archive/RSVP buttons should plumb the same gate end-to-end rather than introducing a parallel confirmation surface.
• Action persistence has a starting point in src/gaia/agents/email/action_store.py — worth checking whether the in-session task store (sub-issue 3) extends that or sits alongside it.
• Agent UI surface selection: today the Email agent renders inside the chat surface — gaia chat --ui. Sub-issue 1 (3-column skeleton) needs an Agent UI route/tab decision; that touches src/gaia/apps/webui/src/ (frontend) and src/gaia/ui/ routers (backend SSE). Worth calling out which agent the dashboard registers under so it lands cleanly alongside the chat surface, not as a parallel app.

🟢 Plan doc needs a dashboard section. docs/plans/email-triage-agent.mdx currently has zero mentions of "dashboard" — the spec still describes the chat surface as the user-facing frame. If this scope shift is real direction (not just an exploration), the plan doc should grow a section for it so the spec and the umbrella don't disagree. Otherwise reviewers will read the spec and miss the new direction.

🟢 Acceptance criterion clarification. "Dashboard surface is the default landing surface for the Email Triage agent once items 1–6 land" — the chat surface today is shared infrastructure used by every agent. "Default landing surface" probably means a per-agent landing override, which is itself a small design decision (and reusable by other agents). Worth flagging that as either explicit scope of sub-issue 1 or its own sub-issue.

On the deferrals (event triggers, NPU): both make sense to sequence last — neither blocks the dashboard from being usable, and the autonomy-engine work in docs/plans/autonomy-engine.mdx is the natural home for the watcher rather than something specific to this surface.

cc @kovtcharov-amd for visibility on the per-agent landing-surface question — that one might affect more than email.