Ash Autonomy & Initiative

Heartbeat matters because it creates a recurring opportunity for Ash to notice, assess, and sometimes act. But that only becomes useful autonomy if it is sparse, inspectable, and cheap enough to live with.

1. What heartbeat actually is

Core fact

A periodic main-session turn

According to the OpenClaw docs, heartbeat runs periodic agent turns in the main session so the model can surface anything that needs attention without spamming. It is not a detached worker process and not a task ledger entry.

Important distinction

Not the same thing as cron

Heartbeat uses approximate recurring cadence, while cron is the exact scheduler. Heartbeat is for routine awareness and context-sensitive monitoring. Cron is for exact timing, isolated execution, and scheduled jobs with task records.

Trigger model

HEARTBEAT.md is read on heartbeat ticks, not on boot

This is the clarification that matters most in practice. The heartbeat file is not operationally “activated” by normal startup. It is read when the heartbeat runner fires on its periodic schedule. The docs describe a default 30-minute cadence, but that should now be treated as a documented default, not a proven live behavior on this install.

Practical implication

Editing the file does nothing until the next heartbeat run

If HEARTBEAT.md changes right now, that does not by itself trigger immediate work. The new content is picked up on the next heartbeat tick, or sooner only if heartbeat is manually woken through the appropriate OpenClaw mechanism.

The most useful framing is this: heartbeat is not “autonomy” by itself. It is the scheduling surface that gives bounded initiative a rhythm.

2. Why heartbeat is relevant to autonomy at all

Reason one

It creates periodic awareness

Heartbeat gives Ash a recurring chance to look around and decide whether anything actually deserves attention: inboxes, calendar, reminders, unfinished threads, stale memory, or project drift.

Reason two

It supports silence as well as intervention

The response contract is explicit. If nothing needs attention, the model should return HEARTBEAT_OK. That matters because good initiative is not constant activity. It is selective awareness.

Reason three

It can batch multiple small checks

The automation docs explicitly position heartbeat as the right fit for routine monitoring like inbox, calendar, and notifications, precisely because several lightweight checks can be bundled into one periodic turn.

Reason four

It keeps initiative inspectable

Heartbeat behavior can be shaped through config, active hours, delivery rules, and a small HEARTBEAT.md file. That makes the autonomy model legible instead of mystical.

3. The real danger: API burn and accidental noise

Why prior attempts felt risky

Heartbeat runs full agent turns

The docs are blunt about this. Heartbeats are full model calls. If the interval is too short, the prompt is too broad, or the session carries too much history and context, token usage can climb quickly.

This is likely why earlier experiments felt like they were “doing something,” but without enough precision to justify the cost.

What makes it worse

The expensive version of heartbeat

Running too often
Using full main-session history every time
Stuffing too much into HEARTBEAT.md
Using chatty, ambiguous instructions
Allowing heartbeat to deliver too often instead of mostly staying quiet

4. What the docs say to do instead

Use isolatedSession: true: this is the biggest cost lever, because it avoids replaying the full conversation history on every heartbeat.

Use lightContext: true: this limits the bootstrap context so heartbeat can focus primarily on HEARTBEAT.md.

Keep HEARTBEAT.md tiny: the docs explicitly recommend a short checklist or reminders only.

Use active hours: restrict heartbeat to times when outreach is actually appropriate.

Use a cheaper heartbeat model when appropriate: heartbeat does not always need premium reasoning.

Use tasks: blocks: only due checks are included, and if nothing is due the heartbeat is skipped entirely.

This is the critical correction: heartbeat is not inherently a token drain. Unscoped heartbeat is a token drain. Properly scoped heartbeat is a sparse monitoring system.

5. The especially important behavior in HEARTBEAT.md

Skip behavior

Empty heartbeat files are skipped

If HEARTBEAT.md exists but is effectively empty, OpenClaw skips the heartbeat run to save API calls. That means an empty or near-empty file is a real cost-control mechanism, not just a placeholder.

Task mode

Due-only tasks can skip nonessential turns

The docs support a structured tasks: block with per-task intervals. Only due tasks are injected, and if none are due, the model call is skipped entirely with reason=no-tasks-due.

What happens now

An empty file means the scheduler may still tick, but the real run should short-circuit

That distinction matters. The system can still conceptually reach a heartbeat interval boundary, but with an effectively empty heartbeat file it should skip the substantive model work rather than reading a rich checklist and producing a real heartbeat turn.

The key mental model

The file is a conditional input, not a standing daemon prompt

HEARTBEAT.md does not sit there being constantly “watched” in a heavy way. It is better understood as a small instruction file that gets consulted when the heartbeat runner wakes up. If the file is empty or no tasks are due, OpenClaw is designed to skip the expensive part.

Live finding

Documented default is not the same as proven active runtime

A real-world test was run on this install by adding a quote-delivery instruction into HEARTBEAT.md and waiting across the expected interval window. No delivery appeared, and no satisfying local evidence of heartbeat execution was found. That means the 30-minute default should not be treated as proven live behavior here.

Current conclusion

Heartbeat probably needs explicit configuration before it truly exists in practice

The strongest current interpretation is that heartbeat is a real OpenClaw capability, but not one that is actually active on this machine yet. The likely missing piece is an explicit heartbeat configuration block or enablement step. Because configuration edits have been a source of instability before, the plan is to handle that later through the intended terminal configure flow rather than by hand-editing openclaw.json from chat.

6. Heartbeat vs cron, in practical terms

Use heartbeat for

Awareness and lightweight initiative

Inbox triage every 30 to 60 minutes
Calendar awareness and upcoming events
Low-noise reminders to notice drift or stale memory
Occasional check-ins when something actually matters

Use cron for

Precise timing and isolated jobs

One-shot reminders
Daily reports at exact times
Weekly deep analysis
Standalone jobs that should not inherit ongoing session context

7. The best first autonomy pattern for Ash

Recommendation

Start with disciplined heartbeat, but only after explicit activation is verified

The strongest path forward is still probably a deliberately conservative heartbeat setup, but the first job now is proving heartbeat is actually enabled in live runtime before designing around it:

isolatedSession: true
lightContext: true
active hours
a small HEARTBEAT.md file
2 to 4 due-only tasks at most
delivery that is mostly silent unless something actually matters

Once explicitly enabled and verified, that turns heartbeat into a real bounded autonomy layer: periodic awareness, selective intervention, low noise, and much better control over cost.

8. What this means for initiative in Ash Foundry

Bottom line

Autonomy should be understood as architecture, not vibe

The initiative question is not solved by asking whether Ash should be “more autonomous.” It is solved by choosing the right mechanisms. Heartbeat is one of the most important of those mechanisms because it provides recurring bounded awareness. But the useful version is disciplined, cheap, and inspectable, not theatrical.

Documentation links

OpenClaw Docs · Heartbeat The main source for heartbeat behavior, config, response contract, cost controls, tasks blocks, and delivery rules. OpenClaw Docs · Automation & Tasks The decision guide for choosing between heartbeat, cron, hooks, standing orders, tasks, and task flow. OpenClaw Docs · Scheduled Tasks (Cron) The reference for exact scheduling, isolated runs, reminders, and why cron should handle the jobs heartbeat should not.