hermes - 💡(How to fix) Fix Skill proposal: hermes-pulse - beacon-style handoff triggers for long-running workflows

Summary

I would like to propose an optional skill/pattern for Hermes called hermes-pulse.

The goal is simple: when an agent finishes a meaningful unit of work, it should leave behind a small, durable handoff that can guide the next step later. A good pulse is more like a beacon light on the shore than another agent talking forever. It stays available as low-cost state, and the next action only wakes up when there is a real condition to respond to.

This is not meant to be a rigid replacement for Hermes' existing loop behavior. It could be implemented as a skill, a prompt template, a workflow convention, or eventually a lightweight supervisor/orchestrator hook if that fits the project better.

Problem

In longer workflows, an agent can complete a subtask and then stop even though the next action is obvious. The user may see a message that sounds like work is continuing, but the system has actually gone idle or lost the handoff.

This shows up in a few forms:

• the agent completes research but does not clearly assign the next step
• the next agent/tool has no compact handoff summary
• long-running workflows lose momentum between subtasks
• missed handoffs do not create a reminder, escalation, or restart point
• the user has to manually recover state after the chain stalls
• parallel agents can finish at different times with no shared low-cost way to rejoin the larger workflow

There are related reports around idle behavior and silent termination, such as #7968. This proposal is focused on a user-facing workflow pattern that can help preserve momentum even when the underlying runtime behavior varies by model/provider/task.

Core idea

hermes-pulse is a small handoff object plus a wakeup condition.

Instead of agents repeatedly tagging each other or burning tokens to check whether something happened, an agent writes a compact pulse when it finishes. That pulse can be picked up later by a scheduler, orchestrator, queue, issue, file watcher, cron, webhook, or another agent.

In other words:

• the agent does the work
• the agent writes the pulse
• the agent can stop
• the pulse remains as durable state
• a cheap external trigger wakes the next step only when needed

This keeps the workflow alive without requiring the model to constantly keep itself alive.

Proposed skill: hermes-pulse

hermes-pulse would define a short completion handoff that agents can emit at the end of meaningful work.

Example format:

## Pulse

Completed: [what was finished]
Verification: [passed / needs review / blocked]
Next: [specific next action]
Owner: [user / Hermes / another agent / orchestrator]
Wakeup: [event, time, condition, queue item, issue, file, webhook, or manual review]
Fallback: [what should happen if this is not picked up]
Status: [ready / in progress / blocked / escalated]

The format can be adjusted to match Hermes conventions. The important part is not the exact field names. The important part is that task completion creates a usable next-step handoff and a clear condition for re-entry.

Verification checkpoint

Before writing the pulse, the agent should briefly check:

1. Is the completed work actually usable?
2. Is the next action specific enough to start?
3. Is the wakeup or fallback concrete enough that the workflow can resume without reconstructing context?

This keeps the handoff practical without adding much ceremony.

Parallel agent use case

This pattern may be especially useful when multiple agents are working in parallel.

For example, several agents can each finish a research slice and emit a pulse. The orchestrator does not need to poll the model continuously. It can wait until enough pulses are ready, until a timeout occurs, or until a specific dependency is satisfied, then wake the merge/scoring/synthesis step.

That makes the handoff more like durable workflow state than a chat message that disappears into history.

Possible implementation paths

This could be done in more than one way:

• Skill only: document hermes-pulse as a reusable skill for long-running workflows.
• Prompt template: add it as an optional prompt pattern for multi-agent/task-chain runs.
• Workflow convention: recommend it for research, code, triage, and agent orchestration tasks.
• Supervisor hook later: if Hermes eventually supports lifecycle hooks for task completion, the pulse could be emitted or validated there.
• Low-cost wakeup layer later: connect pulses to cron, queues, file watchers, webhooks, issues, or reminders so the model only runs when there is something to do.

Why this would help

This gives Hermes users a simple way to make agent work more durable:

• clearer handoffs between agents or steps
• less user effort recovering context
• better audit trail for long workflows
• fewer silent stalls after partial progress
• a natural place to define fallback behavior
• less need for token-expensive self-polling or repeated status chatter

Example

A research agent finishes a website audit. Instead of ending with only a summary, it emits:

## Pulse

Completed: Website audit for example.com with findings grouped by page.
Verification: Passed; sitemap count and sampled pages checked.
Next: Score the findings by severity and business impact.
Owner: Scoring agent or orchestrator.
Wakeup: Start scoring when all assigned audit pulses are ready, or at the 24-hour timeout.
Fallback: If scoring does not start after the timeout, create a reminder or reopen the audit queue.
Status: Ready.

That gives the next step enough context to continue without the user having to restate the workflow, and without the model staying active just to wait.

Open questions

• Would this belong best as a skill, documentation pattern, or runtime hook?
• Does Hermes already have a preferred handoff format that this should align with?
• Should this be scoped only to long-running/multi-agent workflows, rather than normal short chats?
• Is there an existing lifecycle or plugin mechanism where a future version could validate these handoffs?
• Are there existing Hermes primitives for cheap wakeups, queues, cron-like checks, or event-driven continuation that this should reuse?

I am happy to refine the format if there is a preferred Hermes style for skill proposals.