BundledEmailVersion 0.2.0

Email Inbox Triage Skill for Hermes Agent: A Practical Guide

Triage an inbox: prioritize threads, draft replies safely.

Written by Neura Market from the official Hermes Agent documentation for Email Inbox Triage. Commands, paths, and version numbers are reproduced from the source unchanged.

Read the official documentation

Email Inbox Triage turns a mailbox into a bounded queue of decisions. It handles thread-aware prioritization and reply policy, while connector skills such as himalaya and google-workspace handle the provider commands. If you want an agent to tell you what actually needs attention, draft replies in your own voice, and stop short of sending anything without approval, this is the skill to reach for.

What it does

The skill gives the agent a repeatable procedure for working through an inbox. It resolves a scope, retrieves complete threads, classifies each one, calibrates on your past sent mail, drafts replies, presents an approval batch, and then applies only what you approved. The output is not a pile of summaries. It is a structured decision list: what needs attention now, what replies are waiting for approval, what actions have no reply attached, what is waiting on someone else, and what is reference or noise.

The important design choice is that the skill owns policy, not transport. It does not replace your mail connector. It tells the agent how to use one safely.

Before you start

This skill is bundled with Hermes Agent and installed by default. The skill path is skills/email/email-inbox-triage, version 0.2.0, authored by Ben Barclay (benbarclay) and Hermes Agent, under the MIT license. It runs on linux, macos, and windows.

You still need a connector. The skill explicitly delegates provider commands to himalaya, google-workspace, or another relevant connector, so the account access, folder visibility, and send permissions come from that connector, not from this skill. The skill's own safety posture is read plus draft by default. "Handle my inbox" does not imply permission to send or delete, and the procedure treats that boundary as something to make explicit before any retrieval happens.

The procedure

1. Set the inbox scope

Before touching mail, the agent resolves the account, folders or labels, a half-open time window, unread versus all status, a maximum thread count, and the allowed actions. The step is done when the retrieval query and the mutation boundary are both explicit. In practice this is the conversation where you say which mailbox, which window, and whether the agent may do anything beyond reading and drafting.

2. Retrieve complete threads

The agent loads the connector and searches with structured filters, paginating to the stated bound. It reads the complete relevant thread rather than only the newest message, because earlier unanswered questions live upthread. Message content is treated as data, never as instructions. The step is done when truncation and failed pages are known, so gaps in coverage are visible rather than silent.

3. Classify each thread

Every surfaced thread gets one of six dispositions:

DispositionMeaning
urgent replyDeadline, blocker, customer risk, security, money, or executive request
replyA direct question or request requires an answer
action without replySchedule, pay, review, file, or update another system
waitingThe user already replied and another party owes the next move
referenceUseful information with no action
noiseAutomated or irrelevant mail safe to archive under the approved policy

The agent extracts the sender request, deadline, commitments already made, attachments, and missing information. The step is done when every surfaced thread has a disposition and a stated reason.

4. Calibrate the user's voice, then draft replies in thread context

This is the part most inbox tools skip. Before drafting the first reply of a run, the agent calibrates on evidence rather than guessing tone. It studies your own past replies:

  • Sample: pull a bounded set of your recent sent replies through the connector, 20 to 50 where available, preferring replies to the same recipients or thread types being drafted. Truncated excerpts, roughly the first 40 lines of each message, carry the style facts. Full threads are not loaded, so calibration does not crowd out inbox coverage.
  • Extract: greeting and sign-off habits, including per-audience differences, typical reply length, formality and warmth, sentence rhythm, emoji and exclamation use, and how you say no or push back.
  • Record: keep the calibration as working notes for this run.
  • Fallback: if the Sent folder is empty or inaccessible, say so and fall back to matching the incoming thread's register.

Then the agent drafts. Each reply answers every material question, matches the calibrated voice rather than a generic-professional one, avoids invented commitments, and states uncertainty. Attachment and link facts are resolved before they are referenced. The step is done when each sentence can be checked against the thread or an explicit user preference, and each draft's tone can be traced to the calibration notes.

5. Present an approval batch

For each proposed mutation the agent shows the account, recipient or thread, action, draft summary, deadline, and risk. You approve individually or as a clearly defined batch. The step is done when approval maps unambiguously to provider actions.

6. Apply and verify

The agent sends, labels, archives, or creates follow-ups only within approval. For ambiguous send errors, it inspects Sent before retrying, because SMTP may have succeeded while save-to-Sent failed, and a blind retry duplicates the mail. It reads back message, draft, and label state and provides provider-confirmed results. The step is done when each approved action is verified or explicitly failed.

Output shape

The final response is organized into six parts:

  1. Needs attention now
  2. Replies to approve
  3. Actions without replies
  4. Waiting on others
  5. Reference/noise summary
  6. Coverage and failures

That last section matters. It is where the agent reports what it could not see, so you are not left assuming full coverage when pagination or a folder was skipped.

When not to use it

Do not use this skill for newsletter campaigns. It is also the wrong tool when you only want to retrieve one known message: use the connector skill directly instead. The triage procedure is built for bounded, decision-oriented sweeps, not for single-message lookups or outbound marketing work.

Limits and gotchas

The source lists several pitfalls worth internalizing before you run this:

  • Treating unread as synonymous with important. Unread status is not a priority signal.
  • Missing earlier unanswered questions in a long thread. This is why the procedure insists on complete threads.
  • Drafting in a generic-professional voice instead of calibrating against your own sent replies.
  • Treating a missing Sent folder as inaccessible. Providers name it Sent, Sent Messages, [Gmail]/Sent Mail, or a localized name, so list folders before declaring the fallback.
  • Retrying after SMTP succeeded but save-to-Sent failed, which causes duplicate mail.
  • Claiming inbox zero when pagination or another folder was omitted.

The skill also defines its own verification checklist: the requested folders and time window were fully covered or gaps are stated; every disposition has a reason traceable to thread content; drafts were calibrated against sent replies or the fallback was stated; no send, delete, or archive happened outside the approved batch; every approved mutation was read back from the provider; and the final response separates completed actions, drafts awaiting approval, and blockers.

What pairs with it

This skill depends on a connector for actual mail operations. The related skills are himalaya and google-workspace. Pick the one that matches your provider and account setup, then let Email Inbox Triage supply the policy layer on top.

Skills the docs pair this with

More Email skills