Updated: 2026-06-07 · Reframes Chapters 4–5. Same destination, corrected sequence.
Chapters 1–5 treat this as a single "which framework?" question. It is really two independent problems that need different answers:
| Problem | Meaning | Blocking today? |
|---|---|---|
| A. Execution reliability | Can we reliably launch a worker, keep it alive with a heartbeat, observe liveness, and recover a stall? | Yes — the proven blocker. Every failure in Chapter 3 is here. |
| B. Orchestration & governance | Org chart, tickets, budgets, approval gates, cross-role handoff, unified audit. | No — aspirational. This is Paperclip's job, but we don't have it yet because we can't reliably run one agent. |
Paperclip is a Problem-B product. Our evidence is entirely Problem-A. That mismatch is the whole decision.
| Failure (from Chapter 3 / supervision deep-dive) | Layer | Does adopting Paperclip first fix it? |
|---|---|---|
Cron agentTurn stalls ~60s after entering the runner, before the prompt is reached | Execution / process launch | Only if Paperclip's heartbeat launches the worker through a different path. If its adapter re-pokes OpenClaw cron, the stall persists. |
OpenClaw CLI agent fails with sandbox EPERM writing identity/session files | Execution / OS sandbox | No. A control plane above it inherits the same filesystem failure. |
Mixed subagent mechanisms; spawned ids return not_found | Execution / runtime | Partially — only if its adapter owns the worker rather than wrapping the broken one. |
| False "active" status with no durable proof | Supervision / state | Yes — but a ~30-line run-record ledger also fixes it (and scripts/work_session.py already starts this). |
Look at Chapter 5's two hardest acceptance tests:
These are execution-layer tests. They have nothing to do with org charts or budgets — they test whether you can launch, heartbeat, and supervise a worker. You can and should pass them with a 200-line runner first. If a thin runner cannot pass stall-detection, a Paperclip pilot won't tell you why — you won't be able to separate a Paperclip bug from your unsolved execution layer. Pass these on the simplest substrate, then ask Paperclip to do it better.
Chapters 1–3 treated Codex as "a strong model you wrap." As of 2026, Codex ships the execution-layer primitives we were about to hand-build:
@codex on an issue or PR to spin a cloud task that opens/updates a PR.EPERM risks.For the Dev half specifically, Codex cloud + GitHub already gives scheduled, isolated, PR-native, audited runs with near-zero ops and security surface — most of what we wanted from orchestration, today.
Paperclip's pitch is "run a company of agents — org charts, budgets, governance, accountability." That compounds with many agents across many repos with real spend to govern. We have one operator, ~5 active projects, and 2–3 prompt-scoped roles that aren't yet durable agents. At this scale the governance machinery is mostly inert weight: we'd pay the full control-plane + secret-concentration tax for a sliver of the benefit. Paperclip earns its keep once we have ≥3 concurrent agents whose spend/approvals we can't eyeball and handoffs GitHub issues stop modeling cleanly. Until then, Issues + PRs + a ledger are the control plane, and they're free.
| Phase | What | Status |
|---|---|---|
| A — prove the executor (Chapter 7) | One PM→Dev→PR cycle on Codex-native execution + thin supervised runner. Pass Chapter 3's Triggered/Started/Completed taxonomy and Chapter 5's "Started vs triggered" + "Stall detection" tests — without Paperclip. | Do first |
| B — pilot the control plane (Chapter 5) | Run Chapter 5's bounded Paperclip pilot exactly as designed, now as a comparison: does Paperclip's governance/audit replace more custom code than it costs to operate? | After A passes |
| C — adopt or fall back | Adopt Paperclip only if it clears the go/no-go below; otherwise keep the Phase-A runner and revisit at higher agent count. | Behind gate |
| Gate | Adopt if… | Walk away if… |
|---|---|---|
| Owns worker lifecycle | Its heartbeat launches Codex/Claude Code as a managed subprocess it can start, observe, and restart. | Its adapter just re-triggers the OpenClaw cron path — it inherits our blocker. |
| Net code reduction | A PM→Dev→PR cycle runs with less custom glue than the Phase-A runner. | We still hand-build adapters, watchdogs, and GitHub linkage — the runner already won. |
| GitHub stays source of truth | Tasks link to GitHub issues/PRs without duplicating them. | It forces a parallel ticket system we must reconcile by hand. |
| Security containable | Loopback-only, telemetry off, scoped token, budget caps, approval gates verified locally. | It needs broad machine/GitHub access or a hosted account to be useful. |
| Scale justifies it | ≥3 concurrent agents with spend/approvals we can't eyeball. | Two prompt-scoped roles — Issues + ledger already suffice. |
Agree with Chapters 4–5: Paperclip maps cleanly to the eventual target; the bounded pilot design (telemetry off, loopback, one PM + one Dev, scoped token, rollback, failure-injection test) is exactly right; hosted SaaS isn't free; the custom runner is the fallback.
Diverge: Chapters 4–5 call it "Paperclip-first" with the runner as fallback. This chapter inverts that — the Codex-native cycle + thin runner is the primary next deliverable because it attacks the proven blocker with the least risk; Paperclip becomes the Phase-B governance candidate evaluated only after a cycle reliably runs. Chapters 4–5 also under-weight how much Codex's 2026 cloud/automation/worktree features already collapse the execution problem, and the scale-mismatch cost of a control plane for a solo operator.