Autonomous agent framework options v3
Date: 2026-06-07
Purpose: identify the actual blocker preventing reliable long-running PM/Development sessions and define concrete next steps.
Bottom line: the blocker is not the PM prompt, the Dev prompt, Telegram formatting, or the portfolio framework. The blocker is OpenClaw cron agentTurn startup reliability: scheduled isolated agent runs are entering the runner and then failing before agent execution starts. Until that runner path is fixed or bypassed, cron cannot be trusted as the durable PM/Dev execution engine.
What failed
| Run | Expected | Observed | Interpretation |
|---|
| 2026-06-06 23:34 PM test | Start PM agent and audit portfolio | Failed after about 60 seconds: isolated agent run stalled before execution start (runner-entered) | The agent never reached the PM prompt. |
| 2026-06-07 06:33 PM retest | Start PM agent with lighter context | Same 60-second startup stall | Context size was not the primary cause. |
| 2026-06-07 tiny persistent-session smoke test | Run a minimal NO_REPLY task | Same startup stall | The failure is in cron agentTurn runner startup, not task complexity. |
| 2026-06-07 systemEvent fallback | Wake main session | Queued successfully and ended immediately | Useful as a reminder/wake path, but it does not execute autonomous work by itself. |
Root cause assessment
The current architecture assumed cron could directly launch long-running isolated PM and Dev agent turns. That assumption is false in the current runtime. The evidence shows a startup handshake failure before the model receives or executes the prompt.
The current failure mode is especially dangerous because it can look like a successful schedule trigger while producing no PM artifact, no Dev artifact, and no useful Telegram alert. This is why the supervision rules need to distinguish three states:
- Triggered: scheduler accepted a run request.
- Started: an agent began execution and produced liveness evidence.
- Completed: the run produced durable PM/Dev artifacts.
Only the third state should count as useful autonomous work. Only the second state should count as active work.
Decision: stop treating cron agentTurn as the executor
Recommendation: use cron only as a wake/checkpoint mechanism until OpenClaw cron agentTurn startup is fixed. Run long PM/Dev work through a separate durable execution path: either a TaskFlow-style local runner, Codex CLI in a supervised background process, or Codex cloud/GitHub-native tasks. OpenClaw should supervise and report, not be the only execution substrate.
Concrete implementation plan
Step 1 — Split scheduler from executor
Immediate
- Keep OpenClaw cron for timed wakeups and watchdog checks.
- Stop using cron
agentTurn as the primary long-running PM/Dev executor.
- Represent every work cycle as a durable run record before execution starts.
- Require the run record to contain: run id, phase, target issue, executor type, start time, heartbeat/checkpoint deadline, output artifact, and recovery action.
Exit criteria: a triggered-but-not-started run is automatically detected as failed within minutes.
Step 2 — Build a local supervised Codex runner
Today
- Create a script such as
scripts/run_codex_cycle.sh or scripts/run_codex_cycle.py.
- Inputs: role (
pm or dev), target issue, repo, timeout, prompt template, allowed write scope.
- Output: JSON run record plus transcript/log file under a durable run directory.
- Run Codex CLI with explicit non-interactive flags and periodic heartbeat output so watchdogs can see liveness.
- Use shell/background process management, not OpenClaw isolated cron agentTurn, for long execution.
Exit criteria: one PM dry run writes a run record and either a portfolio audit artifact or a clear failure reason.
Step 3 — Make cron a launcher/checker, not the worker
Today
- Daily PM cron wakes main obot or runs a small shell launcher that starts the supervised Codex runner.
- A watchdog cron checks the run record after 5-10 minutes.
- If PM completes with a safe Dev target, the launcher starts Dev using the same supervised runner.
- If PM fails or stalls, watchdog posts one concise Telegram alert and does not pretend work is active.
Exit criteria: a PM failure produces a visible alert and a failure artifact without requiring Jeremy to ask.
Step 4 — Prefer GitHub/Codex-native execution for real development
Next
- Audit current Codex cloud/GitHub integration permissions for obot-claw.
- If available, move Dev execution to GitHub/Codex-native PR tasks where possible.
- Keep OpenClaw as intake, scheduling, monitoring, and Telegram reporting layer.
- Keep local supervised Codex runner as fallback for repos/workflows not supported by Codex cloud.
Exit criteria: one GitHub issue can go PM plan → Dev task → PR → review response with durable status and no hidden agent state.
Recommended near-term architecture
| Layer | Use now | Why |
|---|
| Scheduler | OpenClaw cron systemEvent / watchdog | Good at timed reminders and main-session wakeups; current agentTurn runner is unreliable. |
| Executor | Supervised Codex CLI runner | Direct process control, logs, heartbeat output, explicit timeout, recoverable failure artifacts. |
| Future executor | Codex GitHub/cloud tasks | Better fit for repo-native PR work once permissions and workflow are confirmed. |
| State | GitHub issues + local run ledger | Durable, reviewable, and not dependent on chat transcript memory. |
| Reporting | Short Telegram summary + linked durable artifact when requested | Prevents truncation and formatting drift. |
Concrete next steps
- Do not wait for the 07:30 PM cron as a real work executor. It is currently only a wake/check path.
- Create issue/PR for supervised Codex runner. This should be the next implementation target in
obot-claw.github.io, not safety-agent.
- Implement runner with explicit heartbeat. Minimum viable script: start PM prompt, write
started, update heartbeat every N seconds, write completed or failed.
- Add watchdog validation. A separate check reads the run record and alerts if no heartbeat or artifact appears.
- Run one PM dry run manually. The first success criterion is not “Dev shipped code”; it is “PM run produced durable audit output and correctly started or declined Dev.”
- Then wire daily PM → Dev. Only after the supervised runner passes a manual test should cron own the daily flow.
What not to do
- Do not keep retrying isolated cron
agentTurn and calling it progress.
- Do not count a cron
ok event as PM/Dev completion unless an artifact exists.
- Do not bury PM/Dev state in Telegram messages.
- Do not build a full custom orchestration platform. Build the smallest runner/checkpoint layer needed, then prefer Codex/GitHub-native execution where it works.
Immediate recommendation: move today’s work to a supervised Codex runner implementation. The first acceptance test should deliberately simulate a stalled run and prove Jeremy gets a concise alert plus a durable failure record.