Autonomous agent framework options

Date: 2026-06-06
Scope: options for reliable PM → Development → Testing autonomous work cycles for the obot-claw GitHub portfolio.

Bottom line: Jeremy's concern is correct. A durable run ledger, session state, heartbeat/run records, and issue-to-PR handoffs are common patterns. We should not build a full bespoke orchestration platform. We should use the smallest custom layer needed to bridge OpenClaw/Telegram/GitHub today, while evaluating GitHub-native coding agents and Paperclip-style orchestration for the longer term.

Recommendation

  1. Near term: finish PR #26 as a thin reliability shim, not as a product. Keep it focused on ledger/status/evidence so obot stops claiming invisible work is active.
  2. Next pilot: test a GitHub-native coding-agent path for one small obot-claw.github.io issue: Copilot cloud agent if available; otherwise Codex/Claude through GitHub third-party agent support if enabled.
  3. Parallel evaluation: run a Paperclip spike in a sandbox repo only. Paperclip's model maps closely to what we want: agents wake on assignments, run adapters, update task status, and store run records.
  4. Avoid for now: building a new multi-agent framework around LangGraph/CrewAI/Agents SDK/Microsoft Agent Framework. Those are useful for application agents, but they do not automatically solve GitHub PR lifecycle, sandboxing, liveness, or operator review.

What common systems already do

PatternSeen inWhy it matters for obot
Issue/task assignment creates a runGitHub Copilot cloud agent, Jules, Paperclip, DevinMaps directly to our Project / Requirement / Task issue model.
Run/session record stores statusOpenClaw tasks, Paperclip heartbeats, Devin sessionsPrevents the exact failure we hit: invisible or missing work being reported as active.
Agent works in isolated environmentCodex cloud, Copilot cloud agent, Jules, Devin, OpenHandsReduces dirty worktree risk and makes outputs reviewable as PRs.
Human review remains terminal authorityGitHub Copilot, Jules, Devin, CodexMatches Jeremy's preference: agents can build; humans decide/merge.
Explicit logs/session playbackGitHub Copilot session logs, Devin shell/IDE/browser, OpenClaw sessions/tasksRequired for reliable status and failure diagnosis.

Option analysis

Option A — OpenClaw-native tasks/sessions plus PR #26 ledger

Best near-term fit

OpenClaw already has a background task ledger for ACP runs, subagents, cron jobs, and CLI operations. Tasks move through queued/running/terminal states and can become lost if backing state disappears. OpenClaw sessions also expose stored session rows and trajectory export/tail commands.

Pros: already installed; aligns with Telegram/heartbeat; keeps local privacy; lowest migration cost.

Cons: current Telegram runtime did not expose the right first-class session tools, and the CLI fallback hit sandbox permission problems. Needs configuration/tooling repair before true autonomous cycles are safe.

Use it for: immediate supervision, liveness checks, cron/TaskFlow-backed work blocks, and status reporting.

Option B — GitHub-native coding agents

Best strategic path if available

GitHub Copilot cloud agent can research, plan, make code changes, and open or update pull requests from issues, GitHub.com, VS Code, or automations. GitHub also documents third-party coding agents such as Claude and Codex that can be assigned to issues or mentioned on PRs.

Pros: issue-to-PR lifecycle is built in; session logs live where review happens; branch/PR/review is native; custom agents can specialize; security controls are documented.

Cons: availability depends on GitHub/Copilot plan and org settings; third-party agent access may require GitHub App enablement; task updates after assignment may need to happen on the PR, not only the issue.

Use it for: routine GitHub implementation tasks once obot-claw org settings support it.

Option C — Paperclip as orchestration/control plane

Promising but needs sandbox pilot

Paperclip describes agents as workers that wake for heartbeats, run an adapter such as Claude Code CLI, check assignments, claim tasks, update status, and store run results for audit/debugging. It also has explicit agent identity, session persistence, and status states.

Pros: very close to our desired PM/Dev/Testing agent model; not tied to one agent runtime; gives us org structure, tasks, budgets, approvals, status, and run records.

Cons: newer system; likely operational overhead; would need careful privacy/security review; should not be wired into production obot until a small repo pilot proves it is stable.

Use it for: an experiment coordinating PM/Dev/Testing agents around a toy or low-risk public repo.

Option D — Codex CLI / Codex cloud

Useful execution engine, not full coordinator

OpenAI's Codex CLI is a local coding agent. OpenAI also describes Codex cloud tasks as running in secure isolated containers with repo-provided code and dependencies. Codex usage is tracked across local and cloud clients through OpenAI's compliance/usage surfaces.

Pros: we already use Codex-style local development effectively; strong coding model; compatible with AGENTS.md; can be wrapped by OpenClaw/cron/Paperclip.

Cons: local CLI is not itself a durable multi-agent scheduler; our current sandbox blocked OpenClaw CLI fallback writes; cloud access and GitHub integration need explicit setup.

Use it for: coding execution inside a better run manager, not as the run manager.

Option E — Claude Code GitHub Actions / OpenHands / Devin / Jules

Viable alternatives by use case

Claude Code GitHub Actions can respond to mentions on issues/PRs and create PRs through GitHub Actions. OpenHands provides a self-hostable agent SDK, CLI, local GUI, REST API, and cloud option. Devin and Jules are hosted asynchronous software engineering agents that emphasize parallel backlog tasks, PRs, and human review.

Pros: mature async development patterns; better out-of-box session visibility than our current ad hoc loop.

Cons: varying cost, vendor lock-in, setup, and repo access implications. Some are hosted systems, so private context and credentials need strict review.

Use it for: comparison pilots after GitHub-native availability is checked.

Option F — General multi-agent frameworks

Do not start here

OpenAI Agents SDK, Microsoft Agent Framework, LangGraph, CrewAI, and AutoGen-style systems are useful when building an application that orchestrates agents. They offer patterns such as handoffs, agents-as-tools, graph workflows, checkpointing, and human-in-the-loop controls.

Pros: flexible; strong for custom workflows and PM/research/planning agents.

Cons: they do not automatically provide GitHub issue assignment, PR creation, code sandboxing, session logs, or deployment checks. We would still need to build those operational pieces.

Use it for: later, if we need a custom PM planner or evaluator loop after adopting a proven execution substrate.

Recommended next steps

  1. Complete PR #26 as a guardrail: acceptance matrix, one real ledger-backed cycle, and issue evidence.
  2. Audit GitHub agent availability for obot-claw: Copilot cloud agent, third-party Codex/Claude agents, required plans/settings/GitHub Apps.
  3. Create one pilot issue designed for a GitHub-native coding agent: small, testable, public, no secrets, clear acceptance criteria.
  4. Run Paperclip locally or in a sandbox against a low-risk repo and evaluate whether its heartbeat/status model can replace our custom ledger.
  5. Only then decide whether OpenClaw remains the primary orchestrator, GitHub-native agents become the dev execution layer, or Paperclip becomes the control plane.

Decision matrix

PathReliabilitySetup costGitHub fitPrivacy/controlRecommendation
OpenClaw + PR #26Medium now; high after tooling repairLowMediumHighUse immediately as guardrail.
GitHub-native agentsHigh if enabledMediumHighMediumPilot next.
PaperclipUnknown but architecturally relevantMedium/highMediumMedium/high if self-hostedResearch pilot only.
Codex CLI wrapperMediumLow/mediumMediumHigh localUse as execution engine, not scheduler.
OpenHandsMedium/highMedium/highMediumHigh if self-hostedConsider after GitHub-agent pilot.
Devin/JulesMedium/highLow/mediumHighLower, hostedUseful benchmark, not first choice.
Agents SDK/LangGraph/CrewAI/MS Agent FrameworkDepends on implementationHighLow without extra workHigh if self-builtDo not use for dev execution yet.

Implication for PR #26

PR #26 should be treated as a minimum viable safety layer, not the final orchestration platform. It should prevent false status reports while we evaluate better off-the-shelf execution/control planes. If a GitHub-native or Paperclip-like control plane wins, the #26 ledger can either become a compatibility adapter or be retired.

Sources