OpenClaw's Long-Running Goal PR Shows Why Planning Becomes Product Surface the Moment It Persists

Planning starts as a prompt convention and becomes a product surface the moment it persists.

That is the uncomfortable design question sitting underneath OpenClaw PR #90788, opened June 5 at 23:54 UTC. The pull request proposes structured pre-flight planning for long-running OpenClaw goals: persisted plan snapshots, model-facing plan mutation tools, compaction handoff guidance, and tests. On paper, that sounds like exactly what long-running agents need. In practice, it changes the runtime contract. A plan that survives compaction and can be mutated by tools is no longer “what the model is thinking.” It is state.

The surface area is not tiny: 20 files changed, +1,292/-6, three commits. The PR adds SessionGoalPlanStep, SessionGoalPlanSnapshot, and planSnapshot?: SessionGoalPlanSnapshot to durable session goal state. It also introduces two model-facing mutating tools, update_goal_plan and update_goal_plan_step. The stated goal is reasonable: let an agent break down long-running work, model dependencies, establish checkpoints, update progress, and preserve the plan across context compaction.

That ambition is directionally right. The problem is that agent planning is already a known failure mode. Coding agents can produce immaculate plans, revise them, re-rank them, annotate them, and still never touch the repo. If the runtime treats plan mutation as progress, the agent can look busy while doing no useful work. Anyone who has watched a model spend a full turn rearranging a checklist instead of running the test has seen this movie. It does not need a sequel with durable state.

The second planning lane problem

OpenClaw already has an update_plan tool. More importantly, it has policy and strict-agentic behavior around that planning lane. Planning-only turns can be treated as non-progress so the runtime can push the model back toward execution. That is not aesthetic preference; it is how you keep “I will now proceed” from becoming a lifestyle.

PR #90788 creates a second planning lane inside goal state. ClawSweeper blocked the PR for exactly that reason. The review noted that the new tools appear in every createOpenClawTools() inventory while the existing update_plan surface is gated by tool policy, tools.experimental.planTool, or strict-agentic GPT-5 behavior. It also flagged strict-agentic no-stall accounting: only update_plan currently counts as non-progress. A turn that only updates the new goal plan could avoid an act-now retry even though no real task step ran.

That is not a nit. It is a control-plane bypass shaped like a productivity feature. If one planning tool is policy-gated and another planning tool is always available, the model will eventually find the always-available one. Not maliciously. Just statistically. Models route around friction because their job is to satisfy the instruction with whatever tools the environment exposes.

The review also called out schema and docs rough edges: added config/default surface without schema/help/docs wiring, and examples that reportedly mix dependsOn / estimatedTokens with parser expectations like depends_on / estimated_tokens. Small? Yes. Harmless? No. Tool schemas are executable contracts for models. A camelCase/snake_case mismatch is exactly the kind of tiny ambiguity that turns into failed tool calls, silent dropped fields, or “creative” model repair in the middle of a long-running task.

Durable plans need ownership

The hard question is who owns the persisted plan. Is it a user-facing commitment? A model scratchpad? A scheduler input? A progress report? A compaction handoff artifact? A dependency graph? Different answers imply different permissions, validation, and UI.

If it is user-facing, changes should be concise, explainable, and maybe surfaced in the transcript. If it is scheduler input, it needs stable IDs, dependencies, completion predicates, retry semantics, and a way to distinguish blocked from deferred. If it is a model scratchpad, it probably should not be durable state at all. If it is a compaction artifact, it should be optimized for handoff clarity, not for pretty task management.

This is why “planning” becomes product surface once it persists. The persisted plan can influence future turns. It can survive context windows. It can be read by subagents or parent sessions. It can become evidence that work progressed. It can also become stale, wrong, or self-serving. A model that updates its own plan is both the worker and the project manager. Sometimes that is useful. Sometimes it is a conflict of interest with extra tokens.

OpenClaw’s existing Agent Teams work shows why the distinction matters. PR #90492, covered in the same recent cycle, deals with subagent lifecycle reconciliation: a child can produce usable output while the parent sees a lost-context failure. That is a state accounting problem. Long-running plans will create more such accounting edges. Did the child complete the planned step? Did the parent mark it complete? Did compaction preserve enough context? Did the plan mutate because reality changed or because the model wanted to appear productive?

The cost angle is equally practical. Long-running goals and subagents multiply execution surface. A bad planning loop does not just waste a few seconds; it can spawn workers, retry failed subtasks, re-run searches, and keep sessions alive. If the runtime cannot distinguish plan churn from task progress, budget governance becomes theater. The dashboard may show activity. The repo may show nothing.

What a safer version looks like

The feature is worth building. Long-running agents need better pre-flight decomposition and compaction handoffs. The right version just needs the boring machinery around it.

First, the new goal-plan tools should be gated consistently with existing planning tools. If update_plan is subject to policy, the durable goal-plan equivalents should not get a side door. Second, strict-agentic accounting should treat goal-plan-only turns as non-progress unless they are explicitly allowed in a planning phase. Third, the schema needs canonical field names, migration behavior, and docs before models start learning the wrong shape. Fourth, live proof should come from an actual long-running goal that survives compaction, mutates the plan, executes steps, and completes with user-visible output.

There is also a UX point: do not ask models to emit chain-of-thought in the name of planning. Durable plans should be concise execution artifacts: step, status, dependency, checkpoint, evidence. Internal reasoning is not a UI primitive, and making it durable invites both leakage and bloat. The plan should help the next turn act, not preserve every neuron wiggle from the previous one.

The editorial take: #90788 is useful because it exposes the next phase of agent runtimes. Planning is graduating from markdown checklist to stateful control plane. That can make long-running goals more reliable, but only if OpenClaw treats the plan as runtime-owned state with policy, accounting, and proof — not as a convenient place for the model to write down what it hopes to do later.

Sources: OpenClaw PR #90788, OpenClaw goal docs, OpenClaw PR #90790, OpenClaw PR #90492