The Secret to Hermes Working 24/7: Cron, Gateway, and Heartbeat

Why can someone else’s agent work around the clock while yours stops after one round? The secret isn’t a more powerful model — it’s a background mechanism you haven’t set up.

I’ve been building a long-running autonomous trader based on Hermes.

The idea is simple: it works like a newly hired junior trader with zero background, learning arbitrage 24/7, researching markets, organizing case studies, writing strategies, running simulations, keeping a journal, and doing post-trade reviews. Don’t interrupt me unless it needs a decision on accounts, capital, live trading, or risk control relaxation.

Sounds reasonable.

But when I actually ran it, I hit a classic problem:

At the end of a task round it would say:

Next step: continue collecting case studies, then build simulation environment. No boss decision needed. Will keep working.

And then it just stopped.

It said it would continue, but it honestly ended after that turn.

The Problem Isn’t the Prompt

At first I thought the prompt wasn’t strong enough.

So I wrote:

• You must keep working
• Don’t stop and wait
• Only ask the boss for key decisions
• If no boss decision is needed, keep going

All true, but it wasn’t enough.

Because the basic interaction unit of most agent products is a turn. After it finishes replying, the system doesn’t automatically start another turn. You tell it “continue”, it can promise to continue in text, but without an external scheduler to wake it up again, the next turn simply never happens.

This is a common misunderstanding about autonomous agents:

You think you need a stronger prompt, but what you really need is a runtime that wakes it up on schedule.

Why Someone Else’s Agent Can Do It

The core difference is this:

Normal conversation: User sends message -> Agent works one turn -> Agent replies -> Stop Long-term autonomous: Scheduler hits the time -> Create new agent session -> Read state file -> Work one turn -> Write back state -> Wait for next schedule

True 24/7 work doesn’t mean forcing a single context window to last 24 hours.

The right approach is to break the long-term task into many short cycles:

Wake up every 30 minutes -> Read current state -> Pick highest-priority task -> Drive one concrete work unit forward -> Update task queue -> Write run log -> Wait for next heartbeat

In other words, the secret to long-running work is not “keep saying continue” — it’s:

Gateway + Cron + Heartbeat + State files.

The Four Components in Hermes

I finally broke the mechanism down into four layers.

1. Gateway: The Real Background Alarm Clock

Hermes cron tasks don’t rely on the current chat window to count down.

When you run:

hermes cron create …

you’re just writing the task into Hermes’s task list. The component that actually checks the time, starts the task, and creates a fresh agent session is Gateway.

If you see:

Gateway is not running — jobs won’t fire automatically. Start it with: hermes gateway install

It means the alarm list is written, but no one is watching the clock in the background.

So the first step is:

hermes gateway install

Without Gateway, cron tasks can be listed but won’t run automatically.

2. Cron: Wake the Agent on Schedule

Cron defines “when to wake the agent.”

For example:

hermes cron create “every 30m” “…”

Here’s a pitfall:

hermes cron create “30m” …

This does not mean “run every 30 minutes” — it means “run once after 30 minutes.”

You’ll see in the list:

Schedule: once in 30m Repeat: 0/1

That’s a one-shot task.

For recurring runs, you should write:

hermes cron create “every 30m” …

Or in the chat:

/cron add “every 30m” “…”

The word every is key.

3. Heartbeat: What to Do Each Time It Wakes Up

Cron only wakes the agent.

But what it does after waking up can’t be improvised.

So I recommend adding a file for long-running tasks:

HEARTBEAT.md

This file works like a shift handover card, clearly stating what must be done each time it’s woken up:

1. Read continuous work rules

2. Read current state
3. Read task queue
4. Check for blockers
5. Drive one real work unit forward
6. Update state files
7. Write run log

The key sentence:

Don’t just output a plan. As long as there is no blocker, you must actually advance at least one item among files, research, code, reports, or records.

This prevents the agent from waking up and merely saying:

Next step, I’ll continue.

And then continuing nothing.

4. State Files: Replace Chat Context

A Hermes cron run likely creates a fresh new session.

That means it does not inherit the context from your current chat window.

If you write in the cron prompt:

Continue from where you left off.

It probably won’t know what “where you left off” is.

So you need to land the context onto the filesystem:

memory/current-state.md memory/task-queue.md memory/run-state.md

current-state.md records the current phase, main task, and completed items.

task-queue.md records:

NOW NEXT LATER BLOCKED DONE

run-state.md records the latest run type, what was completed, current focus, next steps, and whether it’s blocked.

That way, each time cron creates a new session, it can restore context from the files.

This is the true key to long-term autonomy:

Don’t let chat history carry continuity; let the filesystem carry it.

A Generic Work Heartbeat Prompt

The core isn’t complexity — it’s self-containment.

You are the long-term working agent for this project. The working directory is /path/to/project. This is a Work Heartbeat. Do not only report plans — you must actually advance one work unit, unless you hit a clear blocker. First read:

• HEARTBEAT.md
• config/continuity_policy.md
• memory/current-state.md
• memory/task-queue.md
• memory/run-state.md Then execute:

1. Check for blockers.
2. If no blocker, pick the highest-priority task from memory/task-queue.md.
3. Drive one concrete work unit forward.
4. Update memory/current-state.md, memory/task-queue.md, memory/run-state.md.
5. If there is substantive progress, write a brief run record in logs/. This reply should only state:

• What was completed
• Which files were updated
• What will be done next round
• Whether user input is needed

Notice it doesn’t say “continue from before.”

Every time it restores itself from the working directory and state files.

Cron Setup Recommendations

For most Hermes users, you don’t need to complicate things at the start.

I suggest setting up 3:

1. Work Heartbeat every 30m

2. Short Review every 12h
3. Major Review every 48h

The first drives continuous daily work.

The second handles short-cycle reviews to avoid just piling up files.

The third handles periodic reflection, updating direction and task queue.

If your task is just ordinary research, you can even start with just one:

Work Heartbeat every 30m

Once you confirm it can reliably hand off, add the 12h and 48h reviews.

Minimal File Structure

I recommend any long-running task have at least these files:

HEARTBEAT.md config/continuity_policy.md memory/current-state.md memory/task-queue.md memory/run-state.md logs/

You can add or remove based on project needs, but keep these concepts:

HEARTBEAT.md what to do each wake-up continuity_policy.md long-running rules current-state.md current progress task-queue.md what to do next run-state.md handoff info from the last run

These files solve the same problem:

The agent can lose its chat context, but it must not lose its work context.

Git Should Not Be a Real-time Log

Once this mechanism runs, files will change frequently.

But I don’t recommend having the agent auto-commit every 30 minutes, and certainly not auto-push.

Git should be an audit ledger, not a runtime log.

A safe rule:

File writes: anytime Local commit: after one clear work unit is finished Push to GitHub: low frequency, after confirming no sensitive information

Especially, do not commit these into Git:

• API keys
• cookies
• tokens
• passwords
• private keys
• personal identification materials
• large raw data sets
• frequently-changing database files

Cron can make it work automatically, but that doesn’t mean you should automatically push everything to remote.

Final Summary

If your agent stops after one round, don’t blame the model first.

Ask yourself four questions:

1. Is there a backend Gateway running?

2. Is the cron schedule “once” or “every”?
3. Is the wake-up prompt self-contained?
4. Are there state files carrying over the previous round’s work?

If all four answers are yes, then it really has a chance to work 24/7.

Otherwise, you’re just chatting with an agent that’s very obedient but clocks out after every message.

The secret to long-running work isn’t making the agent run a single marathon — it’s making it always know who it is, where it is, and what to do next every time it wakes up.