Every agent product that launched this year has the same quiet problem: the model is great at the current turn and useless at the next one. You tell it "ship the release", it says "sure, I'll cut it once CI passes", and then nothing happens. The turn ended. There is no one left in the room to notice CI went green.

Muse, Dots, Grok Bot, OpenClaw and Hermes all solve this with the same two ideas: a goal (what must be true when we are done) and a heartbeat (something that wakes the agent up and asks "are we there yet?"). They differ in where the goal comes from and who owns the clock. This post is a plain-English comparison, then a concrete fix I shipped to Hermes.

How it works in Meta Muse

Muse has one agent per user, not one per conversation. That one agent wakes up on a timer, roughly every 30 minutes, plus whenever an event fires (new message, calendar change, webhook). It is not heartbeating every chat thread; it heartbeats itself and then looks at a single Goals ledger.

• Goal is a tool, not a state machine. The harness exposes goal.get(), goal.create(objective, token_budget) and goal.complete(). The model decides mid-turn to call goal.create; there is no "inference step" after the first message. Simple requests get no goal at all.
• User confirms. When a goal is created from conversation, Muse shows a card (title, deadline, scope, steps, cadence, approvals) that the user can edit or drop. Explicit user goals from the Goals tab skip the card.
• Durable with a checkable end state. A goal is not "work on X"; it is "X is true and here is how to check it". goal.complete() is gated by a completion audit; the model saying "done" does nothing.
• Harness-side nudge. If roughly ten model calls go by with no progress, the harness injects "Continue working toward the active goal, verify requirement by requirement." Idle with an active goal triggers a continuation turn.
• Silence is a feature. Heartbeat turns that have nothing to say return NO_REPLY and the user never sees them.

Why it works: one clock, one ledger, one judge. The goal lives outside any chat thread, so a dead thread does not kill the work.

How it works in OpenAI Dots

Dots (the Codex personal agent) is the most explicit about separating "the thing I promised" from "the conversation where I promised it".

• Tasks are first-class objects. A task has a goal statement, an acceptance check, a schedule or trigger, and a permission scope. Tasks persist in the agent's memory store, not in the thread.
• Two ways in. The user can say "every Friday, summarize my open PRs" and Dots creates a standing task; or Dots proposes one when it notices recurring intent, and the user approves. Either way the task is shown as a card before it runs.
• The runtime owns the clock. A scheduler fires tasks; each run is a fresh turn with the task card as context. Finished runs post a short report; runs with nothing new are suppressed.
• Acceptance check gates completion. A task closes only when the check passes. "I think it's done" is not an input the scheduler accepts.
• Permissions travel with the task. Each task carries what it may touch (read calendar, send email), so background runs cannot escalate quietly.

Why it works: the schedule and the acceptance check are data the harness enforces, so the model cannot drift or forget.

How it works in xAI Grok Bot