HermesWatcher
Search⌘K For brandsSetup help
StartStart hereSetup plannerInstall Hermes AgentChat from your phoneYour first 24 hours
Use casesUse cases by goalWorkflowsCase studiesStarter promptsCommunity reports
LearnWhat is Hermes Agent?Guideswitcheer's WingtipsTopicsFAQCommand cheat sheetGlossarySOUL.md gallery
ToolsTools & integrationsAll messaging platformsSkills directoryPlugins directorySkills, plugins & MCP
TroubleshootReleases
Work with usServicesNewsletterFor brands: partner with usFor AI agentsContactAboutFollow @HermesWatcher on X  (opens in a new tab)

Follow-Up Watch

Use case ·  · 0:06

Transcript

No sound. Below: what's on screen, beat by beat.

  1. At 0:00

    A glowing blue blueprint marked "AGENT BUILD BLUEPRINT" and titled "Inbox Manager Agent", with the subtitle "sort, draft, follow up, summarize". Three boxes above the agent light up, "Google Workspace Skills", "Email Inbox Triage Skill" and "Cron", and arrows carry them down into the agent.

  2. At 0:01

    "Gmail" on the left glows as a dot travels from it into the central "Inbox Manager Agent" box, which then lights up.

  3. At 0:02

    The top output path lights in turn: "Reply Draft Queue", then "Approval Gate", then "Send".

  4. At 0:04

    "Follow-Up Watch" lights up, with a dashed "Keep watching" loop that circles back into it.

  5. At 0:05

    "Daily Inbox Digest" lights up last, completing the blueprint. The @HermesWatcher handle sits in the top left corner.

A workflow that keeps waiting-on-someone email threads from slipping: it records what each thread is owed, rechecks when due, and surfaces only what needs you. Sending stays behind your approval.

The clip is the 6-second header from the post: the full Inbox Manager Agent blueprint, with Follow-Up Watch lighting up near the end.

Skill page Watch on X (opens in a new tab)More use case videos

The post on X

HermesWatcher @HermesWatcher ·
How to Build a Follow-Up Watch Workflow Inside Your Inbox Agent: Everything You Need to Know!Keep waiting-on-someone email threads from disappearing, then surface them only when they actually need attention.The easiest email to forget is often the one you already answered.Once the next move belongs to someone else, the thread can disappear from your attention even though the outcome still matters.A Follow-Up Watch keeps that waiting state alive:waiting thread → record what is owed + when to check again → re-read the thread when due → resolve/update/surface → approve the next action → save the new state
Show the rest of the post
What You NeedYour agent needs:
  • access to search/read the inbox,
  • enough thread context to understand what is still owed,
  • a durable place to store waiting items,
  • a next-review date or rule,
  • a clear approval policy for reminder sends.
For the durable state, use something the agent can reliably read and update: a Markdown file such as FOLLOW_UPS.md, a database/task record, or another persistent store.I would keep each watch item simple:
  • Thread: stable thread/message reference
  • Waiting on: person/company
  • What is owed: the reply, decision, document, payment, approval, etc.
  • Last contact: last meaningful outbound date
  • Next review: date or rule
  • Status: waiting / due / needs decision / snoozed / resolved
  • Notes: only what the next check actually needs
Define the Rules FirstA good Follow-Up Watch should not treat every unanswered email the same.Four rules matter most:
  • Only watch threads where someone else owns the next move. If the ball is back in your court, it belongs somewhere else.
  • No reply does not automatically mean “follow up now.” The stored date/rule decides when it becomes due.
  • A new reply does not automatically mean “resolved.” Re-read what was actually owed. Partial answers can keep the item open.
  • The current thread beats stale state. FOLLOW_UPS.md or your database is a durable memory layer, not a substitute for checking what actually happened.
I would also add one stop rule so the agent does not create an endless reminder loop. After a defined number of attempts or a long stale period, route the thread back to you for a decision.Build the Loop1. Capture the waiting itemWhen triage finds a thread where you already replied and the other party owes the next move, create or update one follow-up record.Do not create a new record every time the workflow sees the same conversation. Use the thread/message identity to update the existing item.2. Review only what is dueOn each check, load the active watchlist first.Anything that is not due can stay quiet.For each due item, re-read the relevant thread and decide:
  • resolved: the expected outcome arrived,
  • still waiting: nothing changed, but another reminder is not needed yet,
  • partial: a reply arrived, but something is still owed,
  • due: no resolving reply arrived and the follow-up rule has fired,
  • blocked: the thread/context cannot be verified.
3. Surface something usefulA due item should tell you more than “you have not heard back.”I would show:
  • who/thread,
  • what you are waiting for,
  • how long it has been,
  • why it is due now,
  • the recommended next action,
  • an optional prepared follow-up reply.
That should be enough to approve, edit, defer, close, or escalate without reconstructing the conversation from scratch.4. Save the new stateAfter each decision, update the durable record.If the item is resolved, close it so it stops resurfacing.If you send an approved reminder, record the new last-contact date and next-review rule.If it is still waiting, keep the same record and move the next review forward according to your policy.Keep Sending Separate From WatchingThe safe default is:agent watches + prepares → human reviews → only approved follow-ups are sentUse stronger review for financial, legal, security, HR/personnel, escalation, or other high-impact threads.If a send result is ambiguous, verify the provider/Sent state before retrying so the same reminder is not sent twice.Validate It Before AutomatingStart with a small mixed watchlist: one thread that is not due, one that is due with no reply, one with a resolving reply, and one with a partial reply.If the workflow keeps the first quiet, surfaces the second, closes the third, and correctly keeps the fourth open, the state logic is working.Make It RecurringOnce the manual loop works, schedule one recurring watch instead of creating a separate timer for every email.A daily review is a sensible starting point for ordinary follow-ups, but the cadence should match your actual needs.Each run should:read active follow-up state → check only relevant threads → update the same records → surface only actionable itemsHermes ImplementationHermes already has the pieces needed to build this.Its current email-inbox-triage Skill includes a waiting outcome for threads where you already replied and someone else owes the next move.Pair that with a supported email connector and your durable follow-up state.For a recurring Hermes setup, use Cron with your project directory as the workdir, attach the relevant email Skill if useful, and tell the scheduled prompt to explicitly read and update FOLLOW_UPS.md before reporting what is due.That last part matters: workdir gives the scheduled run access to the project and loads supported context files such as AGENTS.md, but an arbitrary state file like FOLLOW_UPS.md is not automatically injected just because it sits in the folder.With the current Google Workspace Skill, Hermes can search/read Gmail and send threaded replies after confirmation.That gives you the full Follow-Up Watch loop:remember what you are waiting for → bring it back at the right time → verify the real thread state → surface the next move → keep the state current until it is actually done.

The post as written on Sep 19, 2026, with any sign-up offers and pointers to replies left out. Figures in it are from that day. The summary above describes the design in the video and the post.

More videos

All videos