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:
- Planning — Hermes uses the model to break the task into concrete steps with estimated completion times. The plan is stored in TASKS.md.
- Queuing — Steps are added to the task queue with their scheduled execution times.
- 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.
- 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
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"
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