Last updated: 2026-05-16

Long-Running Tasks & Scheduling — Autonomous Workflows

Hermes's task scheduler is what makes it an agent rather than a chatbot. You give it a goal with a deadline and it works — independently, across restarts, across sleep cycles — until the goal is done or it needs your input. This guide covers task submission, the TASKS.md workspace file, multi-step autonomous execution, check-in patterns, and how to keep long-running tasks safe.

How the Task Scheduler Works

When you submit a task to Hermes, it goes through four stages:

  1. Planning — Hermes uses the model to break the task into concrete steps with estimated completion times. The plan is stored in TASKS.md.
  2. Queuing — Steps are added to the task queue with their scheduled execution times.
  3. Execution — The daemon picks up each step at its scheduled time, pulls relevant memory context, calls the model, executes any tool calls, and stores results.
  4. Reflection — After the final step, Hermes writes a reflection to the procedural memory store and REFLECTIONS.md.

Between steps, the daemon is idle — no API calls, no cost. You're only billed for the actual step executions.

Task Submission — CLI Reference

Immediate execution

hermes run "Summarise this week's GitHub issues in my Atlas project and categorise by priority"

Scheduled once

# Natural language scheduling
hermes run --at "tomorrow 7am" "Check server disk usage and send me a Telegram report"
hermes run --at "friday 5pm" "Compile the week's completed GitHub PRs into a changelog entry"
hermes run --at "2026-05-01" "Start the Q2 project review process"

# ISO 8601 timestamp also accepted
hermes run --at "2026-04-07T08:00:00" "Morning brief"

Recurring tasks

# Natural language recurrence
hermes run --every "weekday 8am" "Morning brief: pull GitHub notifications and server status"
hermes run --every "monday 9am" "Weekly project status update"
hermes run --every "1st of month 10am" "Monthly cost review across all API providers"

# Cron syntax also accepted
hermes run --every "0 8 * * 1-5" "Weekday morning brief"

Long-horizon tasks with check-ins

# Tell Hermes how long it has and when to check in
hermes run \
  --deadline "2026-04-13" \
  --checkin "daily 6pm" \
  "Research the current state of AI agent memory architectures. Read at least 20 sources. Produce a structured comparison report with citations. Check in with me each evening with progress."

Task with explicit steps

hermes run --plan "$(cat <<'EOF'
Goal: Migrate my blog from WordPress to a static site

Steps:
1. Export all posts from WordPress (ask me for the export file path)
2. Convert each post to Markdown using pandoc
3. Organise by category into /content/ directory structure
4. Generate index files for each category
5. Write a migration summary report

Check in after each step. Don't proceed to the next step without my approval.
EOF
)"

TASKS.md — The Task Workspace File

Hermes maintains a running TASKS.md in your workspace that shows all active, queued, and recently completed tasks. You can also write tasks directly into this file and Hermes will pick them up on its next scheduler cycle (every 60 seconds by default).

# ~/.hermes/workspace/TASKS.md

## Active Tasks

### t-007: Research AI memory architectures
- **Status:** running (step 3 of 8)
- **Deadline:** 2026-04-13
- **Check-in:** daily 6pm
- **Next step:** Summarise sources 11–15 and update comparison matrix
- **Next execution:** 2026-04-06 14:30

## Queued Tasks

### t-008: Weekly project status
- **Schedule:** recurring — monday 9am
- **Next run:** 2026-04-08 09:00
- **Description:** Pull GitHub open issues, check server metrics, send Telegram summary

## Defining Tasks Here (Hermes picks these up automatically)

### New Task (Hermes will plan and schedule this)
- **Description:** Review all open GitHub issues in the Atlas repo and label them by component
- **Deadline:** 2026-04-09
- **Priority:** high

When Hermes sees a section without an ID (like "New Task"), it plans it, assigns an ID, and converts it to a proper task entry. This lets you define tasks in your editor without using the CLI.

Check-Ins — Staying in the Loop

Check-ins are how Hermes communicates progress on long tasks without interrupting you constantly. Configure a notification channel, and Hermes sends a structured update at each check-in time:

# Configure Telegram for check-ins (in hermes.json)
{
  "notifications": {
    "channel": "telegram",
    "botToken": "${TELEGRAM_BOT_TOKEN}",
    "chatId":   "YOUR_CHAT_ID",
    "checkIn": {
      "format": "brief"   // brief | detailed | markdown
    }
  }
}

A typical check-in message:

📋 Hermes Check-In — Research task (t-007)
2026-04-06 18:00

Progress: Step 3/8 complete
✓ Identified 20 relevant sources
✓ Read and summarised sources 1–10
⏳ Currently: Summarising sources 11–15

On track for Friday deadline.
No blockers — continuing autonomously.

Reply to give instructions, or ignore to let me continue.

You can reply to a check-in message via Telegram and Hermes will incorporate your instructions before the next step:

# Example reply to a check-in:
"Skip the Letta paper — I've already read it. Focus on the MemGPT and Reflexion approaches."
# Hermes stores this as an episode, adjusts the remaining steps, continues

Autonomous Step Execution — What Hermes Does Alone

During autonomous execution, Hermes can:

  • Make API calls to configured MCP tools and providers
  • Read and write files in the workspace directory
  • Search the web via configured search tools
  • Run shell commands if granted and if a tool wraps them
  • Store intermediate results to memory for use in later steps
  • Re-plan remaining steps based on what it discovers

What Hermes will not do autonomously (it pauses and asks):

  • Send emails, messages, or make posts — even if a channel is configured
  • Delete files or make destructive changes
  • Make API calls that cost money beyond the configured step budget
  • Proceed with a step it has low confidence in
  • Take any action the task description didn't explicitly cover
Define the scope of autonomy explicitly in each task

Hermes respects the scope you give it. "Research and write a report" gives it autonomy to read and write. "Research, write, and publish to my blog" gives it autonomy to publish. Be deliberate — it's better to start with a narrower scope and widen it after testing than to grant full autonomy to an untested task definition.

Task Safety Controls

Step budget

Prevent runaway tasks by capping how many model calls a single task can make:

{
  "tasks": {
    "defaultStepBudget":  20,   // max model calls per task
    "maxStepBudget":     100,   // hard ceiling even if task requests more
    "onBudgetExhausted": "pause-and-notify"  // pause | fail | notify-and-continue
  }
}

Token budget per step

{
  "tasks": {
    "maxTokensPerStep": 8000   // cap input+output tokens for any single step
  }
}

Confidence threshold

Hermes scores its own confidence before executing each step. Below the threshold, it pauses and asks:

{
  "tasks": {
    "confidenceThreshold": 0.75  // pause and check in if confidence falls below this
  }
}

Dry-run mode

# Plan the task without executing anything
hermes run --dry-run "Migrate blog from WordPress to static site"

# Output: shows the full plan, estimated steps, model calls, and cost estimate
# Nothing is executed or stored

Managing Running Tasks

# List all tasks
hermes tasks list
hermes tasks list --status running
hermes tasks list --status queued

# Show full detail for a task
hermes tasks show t-007

# Show execution log
hermes tasks log t-007

# Pause a running task (stops after current step finishes)
hermes tasks pause t-007

# Resume a paused task
hermes tasks resume t-007

# Cancel a task (stops immediately, stores partial results)
hermes tasks cancel t-007

# Retry a failed task from the last successful step
hermes tasks retry t-007

# Add instructions mid-task (injected before next step)
hermes tasks note t-007 "Focus on peer-reviewed sources only from now on"

/goal — Persistent Goals Across Turns (v0.13.0+)

The /goal command locks the agent onto a target and keeps it there across turns — the agent won't declare itself done until the goal's success criteria are met. Useful when you want Hermes to keep working without needing to re-prompt it after each step.

# Set a persistent goal
/goal Write a complete competitive analysis of the top 5 AI agent frameworks by Friday

# Check current goal
/goal status

# Clear the active goal
/goal clear

While a goal is active, Hermes evaluates every completed turn against the criteria before deciding whether to continue or stop. The agent won't drift — it stays focused on the goal even across long multi-step runs.

/subgoal — Add Criteria Mid-Run (v0.14.0+)

Once a /goal is running, /subgoal lets you layer in additional success criteria without restarting:

# Add extra criteria to the active goal mid-run
/subgoal Include a cost-per-token comparison for each framework
/subgoal Prioritise frameworks with MCP support

The judge factors the new criteria into the done-or-keep-going decision on the next turn. No restart, no context loss.

no_agent Cron Mode — Script-Only Watchdogs (v0.13.0+)

Cron jobs can now skip the agent entirely and just run a shell script. Empty stdout is silent; non-empty output gets delivered verbatim to your notification channel. Ideal for simple monitoring tasks where you don't need LLM reasoning:

# hermes.json — cron job with no_agent mode
{
  "cron": {
    "jobs": [
      {
        "id": "disk-check",
        "schedule": "*/30 * * * *",
        "no_agent": true,
        "script": "df -h | awk '$5 > 80 {print \"WARN: \" $0}'"
      },
      {
        "id": "uptime-ping",
        "schedule": "0 * * * *",
        "no_agent": true,
        "script": "curl -sf https://mysite.example.com || echo 'ALERT: site down'"
      }
    ]
  }
}

no_agent jobs cost nothing — no model call, just a shell script. Use them for polling, health checks, and alerting that don't need intelligence.

Sessions Survive Restarts (v0.13.0+)

Before v0.13.0, a gateway restart mid-task would lose the in-flight session. As of v0.13.0, the gateway auto-resumes interrupted sessions when it comes back up — whether from a crash, a hermes update, or a deliberate restart. No task context is lost.

This makes it safe to run hermes update even while tasks are in progress. The daemon will restart, re-attach to the session, and continue from where it left off.

Self-Reflection After Tasks

When a task completes, Hermes automatically runs a reflection pass. The reflection is stored in both REFLECTIONS.md and the procedural memory store. You can read them:

cat ~/.hermes/workspace/REFLECTIONS.md

# Example reflection entry:
---
Task: Research AI memory architectures (t-007)
Completed: 2026-04-13
Duration: 7 days, 12 steps

What went well:
- Breaking research into daily reading quotas kept the task on track
- Using a comparison matrix from step 2 made the final report much easier to write

What to improve:
- Should have confirmed source quality criteria with user before starting
- Step 5 (synthesising conflicting claims) needed more time than allocated

Learned patterns:
- For research tasks: always establish evaluation criteria in step 1
- For report tasks: draft the structure in step 1, fill it in over subsequent steps
- User prefers sources from 2024 onwards; ignore older papers unless foundational

These reflections are retrieved automatically for future similar tasks — Hermes genuinely improves with experience.

← Back to Hermes hub · See also: Persistent Memory Architecture · MCP Tool Integration

📬 Weekly Digest — In Your Inbox

One email a week: top news, releases, and our deepest new guide. No spam. Same content via RSS if you prefer.