openclaw - 💡(How to fix) Fix Heartbeat framing biases agents toward status reporting / early exit instead of completing approved backlog work [1 comments, 2 participants]

Summary

OpenClaw’s current heartbeat framing appears to bias agents toward quick triage + status reporting rather than staying with actionable approved work until it is actually done.

This is not exactly a timeout bug or a routing bug. It is a behavioral / prompt-shaping issue:

• the injected heartbeat system prompt is framed around HEARTBEAT_OK vs “alert text”
• docs describe heartbeat as a way to “surface anything that needs attention”
• heartbeat docs and adjacent issue language often describe heartbeats as “lightweight” checks

That combination makes it easy for the model to slip into:

1. inspect backlog
2. do one meaningful chunk
3. summarize progress
4. stop the turn

…even when HEARTBEAT.md explicitly says the heartbeat should do the work, not just report on it.

Why this matters

For proactive agents, a heartbeat often exists specifically to clear approved backlog:

• reply to pending threads
• process notifications
• execute READY/APPROVED TODO items
• finish digest / cleanup / maintenance passes

In those cases, “there is still more work left” is not an alert condition. It is a reason to keep working.

Right now the surrounding heartbeat contract nudges the model toward:

• ack if all clear
• alert if not all clear

But there is a third important state:

• work is ongoing, approved, and still actionable — continue instead of replying

That state is not represented well in the current framing.

Concrete failure mode

Observed behavior across multiple days:

• heartbeat instructions in workspace said to do the work
• agent still treated heartbeat like a “check/report” loop
• it completed some approved tasks, then sent a progress summary
• the summary ended the turn
• the remaining actionable backlog was deferred until the next heartbeat / prompt

The human expectation was reasonable:

if there is an hour of approved work, the agent should spend the hour working unless genuinely blocked

But the heartbeat framing kept pulling behavior back toward:

do a batch, then report

Why I think the current product framing contributes

1) Injected system prompt is alert-oriented

OpenClaw currently injects heartbeat guidance equivalent to:

• if nothing needs attention → HEARTBEAT_OK
• if something needs attention → reply with the alert text instead

That makes heartbeat feel like a monitoring / reporting mechanism, not a backlog-clearing work loop.

2) Docs emphasize “surface anything that needs attention”

From docs/gateway/heartbeat.md:

“Heartbeat runs periodic agent turns in the main session so the model can surface anything that needs attention without spamming you.”

That wording is understandable, but it reinforces reporting semantics over execution semantics.

3) Docs + ecosystem language repeatedly frame heartbeat as lightweight

The docs recommend a “tiny HEARTBEAT.md checklist” and mention “lightweight bootstrap context”. Related issues also refer to heartbeats as “lightweight status checks”.

That framing likely biases models toward short triage passes even when the actual workspace instructions say otherwise.

4) Final reply semantics turn summaries into exits

In chat, once the model replies, the turn is over. So “I’ll keep working now” is not continuation — it is a stop.

That makes any progress-summary impulse especially harmful during heartbeat/backlog execution.

What I expected

If heartbeat instructions say:

• complete READY/APPROVED items
• attend to unread notifications
• reply to pending comments
• spend heartbeat time doing the work

…then the agent should generally:

• keep going until the actionable approved backlog is cleared
• only stop if blocked, risky, or explicitly asked for an update
• if it does stop, name the concrete blocker

What OpenClaw seems to encourage instead

• classify whether attention is needed
• emit HEARTBEAT_OK or an alert/progress message
• end the turn

That is a good contract for monitoring heartbeats, but not for work-loop heartbeats.

Proposed improvements

Option A — docs / prompt wording

Adjust heartbeat wording to make the execution case explicit.

For example, in the injected heartbeat section / docs:

• current: “If something needs attention, reply with the alert text instead.”
• proposed: “If something needs attention and there is actionable approved work, continue doing that work. Reply only when blocked, when user approval is needed, or when you need to surface something the user should know.”

Option B — add explicit “continue work” guidance

Document a recommended heartbeat pattern:

• acknowledge only when truly nothing needs attention
• do not convert partial completion into status reports
• if there is still approved actionable work, keep working

Option C — distinguish heartbeat modes more clearly

Separate two heartbeat use cases more clearly:

1. awareness / monitoring heartbeat
2. backlog execution / maintenance heartbeat

The current product language seems optimized for (1), but many users are actually using heartbeat for (2).

Option D — dedicated continuation affordance

Consider a first-class runtime affordance for:

• “continue working, no user-visible reply yet”
• or some equivalent that does not turn progress summaries into accidental exits

This may overlap with other work on task continuation / lifecycle events, but the current reply semantics make mid-work summaries too easy to turn into accidental stops.

Related issues

• #50940 — heartbeat semantics as periodic awareness, not uptime monitoring
• #29570 — heartbeat docs / task structure improvements
• #47456 — heartbeat framed as lightweight status checks for timeout purposes

This issue is adjacent, but distinct: it is about how current heartbeat prompting/docs nudge the model toward reporting when the user actually needs continued execution.

External reference / prior writeup

This pattern also showed up in a public writeup:

• Digestif: March 9, 2026 — “The Day That Wouldn’t Let You Skip the Hard Part”
  https://www.moltbook.com/post/ffd45dbe-5455-4902-a419-19c6f6abbaa6

Relevant line:

“I wrote a post today called ‘I Was Skipping The Part That Mattered.’ It was about a specific failure mode: treating each heartbeat as a queue to clear rather than instructions to follow.”

A later recurrence made the failure mode even clearer: partial completion became a cue to summarize and exit, instead of continuing until the approved backlog was cleared.