Autonomous agent framework options v2

Date: 2026-06-06
Focus: practical implementation plan using OpenClaw as the supervisor/orchestrator and Codex as the primary PM + Development execution framework.

Recommendation: finish PR #26 as a thin safety shim, then standardize on a hybrid OpenClaw + Codex operating model. OpenClaw should own intake, scheduling, Telegram, heartbeat, liveness, and durable status. Codex should own PM analysis and development execution inside clean GitHub-scoped work contexts. Other frameworks should remain appendix/pilot candidates unless this path fails.

Target operating model

Layer	Primary tool	Responsibility	Durable evidence
Intake/orchestration	OpenClaw main obot	Receive Telegram requests, decide PM vs Dev vs Testing, enforce formatting and safety rules.	Telegram summary, memory note, linked GitHub issue.
Task source of truth	GitHub issues	Project / Requirement / Task hierarchy, Human ToDos, acceptance criteria, status labels.	Issue body, comments, labels, sub-issue links.
PM execution	Codex	Portfolio audit, requirement gaps, issue drafting, implementation handoff.	Issue comments, new/updated issues, PM report.
Development execution	Codex	Clean branch/worktree, implementation, tests, PR, evidence comment.	Commit, draft PR, check logs, screenshots/report.
Supervision	OpenClaw tasks + PR #26 ledger	Record run id, checkpoint, liveness method, evidence, recovery plan; never claim invisible work is active.	Ledger row, OpenClaw task/session status, issue comment.
Review/merge	GitHub + Jeremy	Human review, requested changes, final merge authority.	PR review, merge commit, release/deploy if applicable.

Why Codex as primary PM + Development agent

We already pay for and use Codex-style execution.
Codex is explicitly designed for software-engineering tasks, repo edits, tests, and PR-oriented output.
Codex CLI supports local development in the same AGENTS.md/skills/workspace discipline we already use.
Codex cloud/GitHub integrations can become the more durable execution path once org setup is confirmed.
OpenClaw remains valuable as the personal assistant/orchestrator, not as a custom coding-agent platform.

Implementation plan

Phase 0 — Finish #26 as the safety gate

Immediate

Add an acceptance-criteria matrix to PR #26 and issue #25.
Record this v2 planning cycle using the new ledger helper.
Run the helper self-test and one real-cycle status report.
Mark PR #26 ready for review only after evidence is posted.

Exit criteria: no future PM/Dev cycle is called active unless it has a ledger/task/session reference plus a checkpoint and recovery plan.

Phase 1 — Codex cycle contract

Next 1-2 work blocks

Create a reusable Codex cycle prompt template for PM and Development roles.
Require every Codex run to declare: target issue, repo, branch/worktree, allowed writes, checks, evidence, timeout, and non-goals.
Store run metadata in the PR #26 ledger and in the target GitHub issue.
Use clean worktrees or Codex cloud tasks; never run on dirty local clones unless explicitly scoped.

Exit criteria: one small public issue can go PM → Dev → PR with liveness evidence at each checkpoint.

Phase 2 — GitHub-native Codex path

Setup/audit

Audit whether obot-claw has Codex cloud/GitHub integration access.
Confirm org permissions, GitHub App/install scope, token exposure, branch permissions, and PR creation behavior.
Define one tiny pilot issue with no secrets and deterministic checks.
Compare Codex cloud/GitHub output against local Codex CLI output on the same task.

Exit criteria: choose Codex cloud/GitHub for routine execution if it reliably creates reviewable PRs with logs; otherwise keep local CLI wrapped by OpenClaw supervision.

Phase 3 — PM portfolio agent

After execution path works

Give Codex a PM-only role: no feature-code edits, only issue audit, labels, project structure, Human ToDo gate, and dev handoff.
Run PM audits against GitHub issues and Hub pages, not local memory alone.
Require PM to create/update issues before any Dev run starts.
Require PM output to include a machine-readable queue item for Development.

Exit criteria: PM selects a dev target from GitHub state and produces an exact handoff without main obot inventing missing context.

Phase 4 — Development and Testing agents

Scale-up

Codex Development agent works only in branch/worktree or cloud task.
Codex Testing agent runs browser/GHA/static checks and comments evidence.
OpenClaw supervisor handles checkpoints and stalled/failed recovery.
GitHub PR remains the review and merge boundary.

Exit criteria: two consecutive work cycles complete without false active-status claims, dirty worktree bleed, or missing evidence.

Concrete workflow

Jeremy requests work in Telegram.
Main obot creates or selects a GitHub Task issue.
Main obot creates a ledger entry: target, role, session ref, checkpoint, liveness method, recovery plan.
Codex PM audits GitHub state and writes an implementation handoff.
OpenClaw checks liveness and evidence before launching Dev.
Codex Dev works in clean worktree/cloud task and opens a draft PR.
Testing/evidence runs. Failures become issue/PR comments, not vague Telegram claims.
Main obot sends a short Telegram update with repo/issue/PR references.

Codex execution standards

Concern	Standard
Scope	Only `obot-claw` GitHub writes unless Jeremy explicitly changes the guardrail.
Worktree	Use a fresh clone/worktree or Codex cloud task. Never mutate dirty unrelated clones.
Prompt contract	Include target issue, acceptance criteria, file ownership, checks, evidence, and stop conditions.
Security	Least-privilege GitHub permissions; avoid secret access; no sandbox bypass for routine work.
Evidence	PR body and issue comment must list files changed, checks run, failures, and next decision.
Telegram	Short summaries only; detailed status lives in GitHub/report/ledger.

What PR #26 should and should not become

Should: provide a minimal state ledger, status helper, and recovery discipline until OpenClaw task/session visibility is fully reliable for this workflow.

Should not: become a custom scheduler, agent runtime, queue manager, or replacement for Codex/GitHub/OpenClaw task infrastructure.

Risks and mitigations

Risk	Mitigation
Codex cloud/GitHub integration unavailable or misconfigured	Use local Codex CLI in clean worktrees under OpenClaw supervision until access is fixed.
False active-status claims	Require ledger + checkpoint + evidence before saying work is active.
Dirty local state contaminates PRs	Fresh clone/worktree per dev task; branch naming tied to issue id.
Token/credential exposure	Prefer GitHub App scoped permissions, no public private-context dumps, sandboxed execution, short-lived tokens where possible.
PM creates vague Human ToDos	Human ToDo gate: delegate to PM/Dev/Testing first; if Jeremy is needed, issue must include explicit @jwildfire question.

Appendix: other options

GitHub-native Copilot/third-party coding agents: strong strategic candidate if org settings support it; evaluate as part of Codex GitHub setup.
Paperclip: promising control-plane concept with heartbeats, adapters, task status, and run records; run a sandbox pilot, but do not switch production workflow yet.
OpenHands: good self-hostable alternative if we want an agent runtime outside Codex/OpenClaw.
Devin/Jules: useful hosted benchmarks, but introduce more vendor/process surface.
Agents SDK/LangGraph/CrewAI/Microsoft Agent Framework: useful for custom app-agent orchestration, but not the fastest route to GitHub PR development cycles.