The Always-On Agent
Module 3b ran the agent when you sent a message. OpenClaw can also start work from skills, heartbeats, cron jobs, and sub-agents. Each path still enters the same agent loop and OpenShell sandbox; the session, directive, and trigger determine what runs. You will install a skill and observe a cron-fired write.
How triggers choose context and instructions
Every mechanism on this page is described by the same three knobs:
- The session sets whose context a run inherits.
- The directive is the markdown file that tells the agent what to do.
- The trigger decides when a run starts.
The table shows the course configuration. Use the same three fields to classify other trigger types; OpenClaw also exposes additional session modes.
| Name | Session | Directive lives in | Trigger |
|---|---|---|---|
| Skill (run below) | reuses the caller's | workspace/skills/<name>.md | model picks it mid-turn when the directive matches the user's ask |
| Heartbeat (concept only) | main session here | HEARTBEAT.md | gateway timer, ~30 min by default |
| Cron (run below) | isolated here; fresh per fire | JSON drop-in prompt field | cron schedule, per-minute precision |
| Sub-agent (concept only) | fresh, parent holds the handle | inline string at delegate() time | parent agent decides mid-turn |
delegate() call are covered here only as table entries;
no cell on this page fires them, so do not wait for one.
Step 1 · Add a Skill
A skill starts as a markdown file placed under skills/, usually with a
short front-matter or heading block that lets the runtime decide when to reveal it.
The agent does not load every instruction at once; it progressively discloses the
matching skill when the next turn asks for it. You do not restart it, redeploy it,
or touch the system prompt yourself.
The widget below asks the agent to install that exact skill, then fires a chat completion designed to match it. Matching is automatic. The agent compares your request against the description of every skill in its workspace, so your prompt never has to name the one you want. Watch the agent reach for the new skill on its second turn.
Same runtime as Kickstart. You are driving the same OpenClaw agent you connected on the Kickstart page.
Step 2 · Inspect your running agent
Scheduled jobs live on the gateway rather than behind an HTTP REST route, so the
same WebSocket connection the Control UI uses is also where you list and manage them
through the cron methods cron.list cron.add and
cron.remove. A cron job lets an always-on agent act with no human in
the loop because scheduled work fires on its own timer. The course runtime creates
an isolated session for this demonstration. OpenClaw can instead bind scheduled work
to another supported session mode when continuity is more important than isolation.
The widget below walks the full lifecycle of a cron job:
- It connects and lists the crons already installed.
- It installs a demo job that fires every minute and appends a line to
MEMORY.md. - It waits about seventy seconds so the job can cross a minute boundary and run on its own.
- The next cell reads the tail of
MEMORY.mdoff the sandbox, so you see the line the cron-fired agent wrote while nothing was driving it. - The last cell removes the job so nothing lingers.
No human prompted that write. The cron schedule drove it on its own, doing real work on the agent's behalf while you were away.
Where to take this
Public Hermes repository exposes the same broad capability categories: reusable skills, persistent memory, scheduled work, and a messaging gateway. Its implementation and defaults differ from OpenClaw, so compare the security boundary and session behavior rather than assuming that matching feature names imply matching risk controls.
Any harness that can write reusable instructions, schedule work, and accept remote messages can persist a compromised directive beyond one conversation. Module 4 separates those application controls from the sandbox controls that bound filesystem, process, and network access.
default: deny when no allow rule matches. Those application controls decide who
may talk to the agent. An operating-system sandbox separately bounds what its tools can reach.
The same skills-as-memoised-trajectories pattern appears across the ecosystem under other names and shapes:
- Wang et al., Voyager (2023). The research origin, demonstrated in a Minecraft agent.
- LangGraph Persistence. Checkpointed graphs as save-and-resume.
- Anthropic, Agent Skills. The production skill-folder layout.
References
- Wang et al., Voyager: An Open-Ended Embodied Agent (2023). The skill-library / memoised-trajectory mechanic this page builds on, demonstrated in a Minecraft agent.
- Park et al., Generative Agents (2023). Multi-day autonomous-agent simulation; the reflection and memory-consolidation patterns an always-on loop reuses.
- Anthropic, Agent Skills. The production skill-folder layout this page's
skills/<name>.mddrop-in mirrors. - LangGraph, Persistence (checkpointers). Checkpointed graphs as the same save-and-resume primitive in a different production shape.
- Hermes Agent. Agent application with self-improving skills, persistent memory, cron, and a messaging gateway; NVIDIA's DGX Spark playbooks list Hermes and NemoClaw as separate setup paths.
- OpenClaw, Automation & Tasks. Current session and trigger semantics for cron, heartbeat, hooks, and background tasks.
- Hermes Agent, Security. Pairing and allowlist behavior for messaging-gateway callers.
- cron(8). The canonical reference for the scheduling primitive the cron drop-in borrows.
Comprehensive list at Going Further · References.
Try it · trigger a skill in conversation
Chat with your live agent over the gateway. If you installed the triage-incident skill in Step 1, paste an incident and watch the agent pick the skill up mid-turn without you ever naming it.
That is the same machinery a heartbeat or a cron fire would use, only driven by your own message instead of by a timer.