Personal triage

"i would like you to pre-triage all my emails and imessage and whatsapp and show me categories such as where i should reply, where i should take action or decide, the threads i am working on" · "especially triage out what you consider spam or uninteresting commercials, what you consider important to read, where action is required" · "this adds the most value to my life" · "try to distinguish between what's important for me vs what i can ignore" · "maybe add tags? similar to github issues?" — the maintainer, 2026-10-13.

Status: design, building. Decided with the maintainer on 2026-10-13: the triage model is the instance's EU model catalogue; messages are read live from their provider, never replicated ("it should take from graph, not necessarily replicate"); the side menu shows the triage on top, the kinds (sources) below.

What is stored, and what is not

	stored in the mesh	read live from the provider
the message (body, attachments)	never	yes — opened and searched through the provider
the VERDICT	yes — `{user}/_Triage/{provider}-{messageId}`	—

A verdict holds only what the inbox row needs and what the triage decided:

field	meaning
`provider`	an open string: `outlook`, `gmail`, `imessage`, `whatsapp`
`messageId` / `conversationId`	the provider's own ids — how Open and the actions reach the message
`from`, `subject`, `receivedAt`	the row (`receivedAt` is the row's time — `InboxQueryLeg.TimeField`)
`link`	where Open goes: the message in its provider's own client
`importance`	an open string: `important` or `ignorable`
`tags`	open strings, several per message (below)
`reason`	one line: why this verdict — shown on the row's tooltip
`model`, `triagedAt`	which model decided, and when
`tagsBy`	`agent` or the person who last edited the tags — a person's edit is never overwritten

Importance and tags

Importance answers the one question that matters most: is this for me, or can I ignore it? Ignorable — spam, promotions, newsletters, automated notices nobody asked for — is out of sight by default, one switch away.

Tags are GitHub-style labels, OPEN strings (never an enum — a package or a person adds their own), several per message:

tag	the message…
`act`	asks you to do something
`decide`	needs your decision or approval
`reply`	waits for your answer
`read`	is important to read, nothing to do
`working-on`	belongs to a thread you are active in
`waiting`	you replied; the other side owes the answer
`fyi`	is informative, nothing owed
`promo`	is commercial
`spam`	is unwanted
topic	the agent proposes topics — a client, a project, `billing`, `travel`

The flow

new message (Graph change notification / poll) ──▶ triage job (the user's delegated credential)
        ──▶ the EU model: importance + tags + reason ──▶ verdict node {user}/_Triage/{provider}-{id}
        ──▶ the personal inbox: a leg over {viewer}/_Triage, filtered by importance and tags

Reading uses the person's OWN delegated credential (IEaGraphAuth for Outlook — the Executive Assistant's; see ExecutiveAssistantCredentialReads). Nothing is read with an application credential, and the triage sees only what the person can.
Thread context: the triage reads the message and its conversation's earlier messages, including the person's own replies — that is what tells working-on and waiting apart.
Corrections teach: a tag the person adds or removes is kept (tagsBy), and the last corrections are given to the model as examples on the next run.
Idempotent: one verdict per message (its id is derived from the provider's message id); a redelivery is refused, never duplicated — the inbound lane's claim rule.

In the inbox

The side menu: Important first, then each tag with its count, then the kinds (Mail, Conversations, Approvals, …). Ignorable is one entry at the bottom.
Select many and act — shift-click a range, cmd/ctrl-click to toggle — and the command row offers the actions every selected message has in common: Archive, Delete, Mark read, Tag, and for approval requests, Approve and Reject. Actions call the provider (Graph's move, delete, mark read).
Each row shows its provider's symbol; a provider's switch is three-way: only this, show, hide.
Search goes to the provider's own search (Graph $search), merged with the verdicts.

Order of work

Outlook: the triage job, the verdict node type, the inbox leg and the tag side menu.
Actions on the selection (Archive, Delete, Mark read, Tag), called through Graph.
Live search through the provider.
Gmail, then iMessage (the Mac bridge), then the WhatsApp business channel.

What WhatsApp cannot do: WhatsApp offers no API for a person's own chats — only the business number the assistant answers on. Those conversations are triaged; a personal chat is not reachable.