docs: propose persistent Agent runtime lifecycle

[freeqaz-openai]

What Problem This Solves

A restart or accepted stop request does not establish safe continuation or physical termination. Operators need clear outcomes when retained files, helper processes or remote effects remain unresolved.

Why This Change Was Made

The current ordinary Kubernetes controller selects and requests activation of the successor before requesting predecessor retirement. That path does not yet establish observed predecessor termination and writer exclusion before successor writes. This proposal requires that contract and accepts the resulting availability gap. Managed reads, then approved publication, need this replacement discipline, root work and complete ownership of any supported helpers. Public Stop task / Stop Agent / Start Agent controls, completed-state recovery and broader durable Work and child coordination are later delivery stages.

User Impact

The proposed controls distinguish accepted intent, authority withdrawal, physical termination and credential cleanup. Recovery begins with compatible same-build, same-cluster retained storage; unknown creates or termination block writable replacement. Fresh execution rechecks current authority and preserves effect receipts without replaying uncertain operations. Execution may be uncapped; leases, operation deadlines and any selected drain or delivery remain finite. Public Stop defaults remain open.

This is a documentation proposal extending RFC 0027. It remains draft with a blank implementation issue pending acceptance.

Reading Guide

• Persistent Agent and runtime lifecycle and detailed specification.
• Related drafts: #68, #69, #70.

Evidence

• Checked draft metadata, required sections, Markdown structure, links, anchors and whitespace; reran desktop/mobile rendering and independent cross-RFC review.
• Desktop preview uses a local Markdown render with GitHub-style CSS.
• Document checks only; provider, native runtime and deployment qualification require separate evidence.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge. Reviewed September 11, 2026, 3:30 PM ET / 19:30 UTC (Revision 7).

ClawSweeper review

What this changes

Adds an illustrated RFC specifying safe Agent replacement, persistent lifecycle intent, and later stop/start, recovery, and completed-result delivery contracts.

Merge readiness

⛔ Blocked before merge - 3 items remain

The proposal remains distinct from the accepted Enterprise RFC and merits continued discussion. No actionable patch defect was found; acceptance remains a substantive maintainer decision under this repository’s RFC process.

Priority: P3
Reviewed head: 1b729a515b51be2619a3b7464462b71d47fd6160
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A coherent, illustrated RFC with sufficient presentation proof and no concrete patch defect.
Proof confidence	🦞 diamond lobster (5/6) ✨ media proof bonus	Sufficient (screenshot): The pinned PNG preview demonstrates the changed RFC’s rendered text and lifecycle illustration. That is sufficient for this documentation proposal; provider and native-runtime qualification are explicitly deferred to implementation.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): The pinned PNG preview demonstrates the changed RFC’s rendered text and lifecycle illustration. That is sufficient for this documentation proposal; provider and native-runtime qualification are explicitly deferred to implementation.
Evidence reviewed	8 items	RFC acceptance process: README requires a maintainer-discussion thread, acceptance, an implementation issue, and accepted metadata before merging a new RFC. The current document correctly remains draft with a blank issue. Complete proposed contract inspected: Read the entire 444-line supporting specification, including durable admission, writer exclusion, recovery, revocation, delivery, qualification, and open decisions. It explicitly distinguishes proposed capabilities from runtime qualification. Current-main foundation does not supersede the proposal: The accepted Enterprise RFC already requires predecessor retirement before successor execution, but does not specify this proposal’s durable control, completed-state recovery, and delivery contracts. The current-main tree contains no RFC 0037; merged #35 supplies the foundation rather than a fixing replacement.
Findings	None	None.
Security	None	None.

How this fits together

OpenClaw Enterprise’s controller coordinates Agent deployment and delegates execution to compute and sandbox drivers. This proposal defines how authorized work, retained files, and observed termination constrain replacement and later lifecycle controls.

flowchart TD
  A[Authorized work and lifecycle requests] --> B[Enterprise controller]
  B --> C[Durable intent and current authority]
  C --> D[Compute and sandbox drivers]
  D --> E{Predecessor writers stopped?}
  E -->|Unknown| F[Hold replacement and retain cleanup]
  E -->|Confirmed| G[Activate successor and enable routing]

Loading

Decision needed

Question	Recommendation
Should the staged runtime baseline and later lifecycle profiles be accepted as the Enterprise lifecycle direction?	Accept the staged direction: Record acceptance with mandatory initial runtime safety and explicitly deferred public controls, recovery, and delivery profiles.

Why: The repository requires explicit RFC acceptance, and the proposal makes architectural commitments beyond the already accepted deployment contract.

Before merge

• Resolve merge risk (P1) - The newly cited Enterprise controller behavior could not be independently checked because both pinned source requests returned HTTP 404; this is a reviewer limitation, not missing contributor presentation proof.
• Complete next step (P2) - Record acceptance through the required maintainer-discussion process, checking the cited controller characterization; if accepted, create the implementation issue and update status and issue metadata before merge.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Documentation scope	518 Markdown lines, 51 diagram-source lines, 2 PNGs	The substantive review concerns a design contract and its presentation; no production or test code is added.

Merge-risk options

Maintainer options:

1. Decide the mitigation before merge
   Adopt a clearly staged lifecycle contract that preserves mandatory replacement safety while leaving optional public controls and recovery profiles subject to separate qualification.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Technical review

Best possible solution:

Adopt a clearly staged lifecycle contract that preserves mandatory replacement safety while leaving optional public controls and recovery profiles subject to separate qualification.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this PR proposes a lifecycle contract rather than implementing a bug fix; document rendering was inspected directly.

Is this the best way to solve the issue?

Yes as a design proposal: extending the accepted Enterprise contract and separating initial safety from later capabilities is coherent, subject to maintainer acceptance.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning medium; reviewed against 967d9aac7472.

Labels

Label justifications:

• P3: This is a design proposal without an introduced runtime change or demonstrated urgent user regression.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): The pinned PNG preview demonstrates the changed RFC’s rendered text and lifecycle illustration. That is sufficient for this documentation proposal; provider and native-runtime qualification are explicitly deferred to implementation.
• proof: sufficient: Contributor real behavior proof is sufficient. The pinned PNG preview demonstrates the changed RFC’s rendered text and lifecycle illustration. That is sufficient for this documentation proposal; provider and native-runtime qualification are explicitly deferred to implementation.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The pinned PNG preview demonstrates the changed RFC’s rendered text and lifecycle illustration. That is sufficient for this documentation proposal; provider and native-runtime qualification are explicitly deferred to implementation.

Evidence

What I checked:

• RFC acceptance process: README requires a maintainer-discussion thread, acceptance, an implementation issue, and accepted metadata before merging a new RFC. The current document correctly remains draft with a blank issue. (README.md:80, 967d9aac7472)
• Complete proposed contract inspected: Read the entire 444-line supporting specification, including durable admission, writer exclusion, recovery, revocation, delivery, qualification, and open decisions. It explicitly distinguishes proposed capabilities from runtime qualification. (rfcs/0037/lifecycle-spec.md:19, 1b729a515b51)
• Current-main foundation does not supersede the proposal: The accepted Enterprise RFC already requires predecessor retirement before successor execution, but does not specify this proposal’s durable control, completed-state recovery, and delivery contracts. The current-main tree contains no RFC 0037; merged RFC 0027: OpenClaw as the Open Enterprise Agent Platform #35 supplies the foundation rather than a fixing replacement. (rfcs/0027-openclaw-enterprise.md:417, 967d9aac7472)
• Feature-history routing: The deployment contract traces to af708f0. Raw commit inspection identified its recorded parent, and that parent’s tree has no rfcs/0027-openclaw-enterprise.md. File history and README process history also identify kevinlin-openai as a relevant routing candidate. (rfcs/0027-openclaw-enterprise.md:417, af708f0ddb6f)
• Re-review continuity: The previous review reported no findings. The GitHub commit endpoint confirms that the latest revision adds the current-controller characterization and refreshes the preview. Local comparison against the prior head failed because an unavailable historical blob returned HTTP 403; the API patch supplied the latest delta. (rfcs/0037-persistent-agent-runtime-lifecycle.md:46, 1b729a515b51)
• Rendered documentation proof: The prepared proof-image-1.png was HTML despite its filename. Inspected the actual pinned review-preview.png and stop-and-delivery.png successfully: the document, staged scope, replacement caveat, and delivery diagram are readable and consistent with the Markdown. This supports documentation presentation only. (rfcs/0037/review-preview.png, 1b729a515b51)

Likely related people:

• kevinlin-openai: Raw commit af708f0 adds rfcs/0027-openclaw-enterprise.md:417 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: af708f0ddb6f; files: rfcs/0027-openclaw-enterprise.md)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (6 earlier review cycles)

• reviewed 2026-09-08T22:14:47.312Z sha c7b5fe1 :: needs real behavior proof before merge. :: none
• reviewed 2026-09-09T00:41:47.142Z sha b4147de :: needs real behavior proof before merge. :: none
• reviewed 2026-09-09T21:11:33.745Z sha 8a468b9 :: blocked before merge. :: none
• reviewed 2026-09-09T21:43:13.907Z sha 93b6115 :: blocked before merge. :: none
• reviewed 2026-09-11T07:48:37.665Z sha fe4ba21 :: blocked before merge. :: none
• reviewed 2026-09-11T19:09:23.070Z sha 144f276 :: blocked before merge. :: none