#missing persistent next-action model in accepted workflows

1 messages · Page 1 of 1 (latest)

eager edge
#

We are seeing a recurring OpenClaw agent workflow issue: after accepting a multi-step task, the agent loses its next-action model. It remembers context but does not maintain objective → current state → next step → completion criteria.

This is not just token compaction or memory recall. The agent often has the required tool output, but hands control back to the user instead of continuing or naming a blocker.

We documented examples in issue #79809. Is the intended solution TaskFlow, standing orders, cron, or an upcoming self-elected continuation feature? What is the recommended OpenClaw pattern for persistent next-action workflow state?

shadow beaconBOT
#

Short answer: for persistent next-action workflow state, the recommended OpenClaw shape is Task Flow / Lobster-style workflow state, not memory, heartbeat, or cron by themselves.

How I’d separate the pieces:

  • Normal accepted chat task: the agent should keep going in the same run until done or explicitly blocked. If it has the needed tool output and hands control back with no blocker, that’s an agentic follow-through/runtime/model behavior bug, not the intended UX.
  • Task Flow: use this when you need durable multi-step orchestration: objective → step state → child tasks → retries/waits → completion across restarts. Docs: https://docs.openclaw.ai/automation/taskflow
  • Lobster: use this when the steps can be made deterministic/typed, especially with approval gates and resume tokens. This is usually the strongest pattern for “don’t forget the next action.” Docs: https://docs.openclaw.ai/tools/lobster
  • Standing orders: define standing authority, scope, escalation rules, and execution discipline. They’re not a progress ledger; pair them with cron/Task Flow/Lobster. Docs: https://docs.openclaw.ai/automation/standing-orders
  • Cron: trigger timing / recurring execution. Use session:<id> if the workflow should build on prior run context, but cron is still a trigger, not the state machine. Docs: https://docs.openclaw.ai/automation/cron-jobs
  • Heartbeat: good for periodic awareness/check-ins. It should not be treated as the thing that resumes every accepted multi-step workflow.

So for issue #79809 specifically: the expected behavior for an accepted task is not “user must say continue after every subtask.” If this is happening on 2026.5.7 with required tool output already present, I’d treat that as a bug/regression and keep the GitHub issue focused on a minimal transcript showing: accepted objective, tool result, obvious next step, and premature handoff.

The practical workaround today is: encode long-running workflows as

#

Task Flow or Lobster, with standing orders for authority and cron only if it needs scheduled triggering. Self-elected continuation is referenced in current agentic-parity work, but I would not design production workflows around an upcoming feature until it lands in docs/releases.