It's one of the most frustrating failure modes in agentic AI: you give an agent a task, it produces a thoughtful, well-structured response explaining exactly how it would approach the problem — and then stops. No file was edited. No command was run. No tool was called. The agent planned, but it didn't act.
OpenClaw's latest update adds a new opt-in execution contract called “strict-agentic mode” that directly addresses this behavior. When activated, the platform monitors agent responses for plan-only turns — responses that contain prose descriptions or structured bullet lists of intended actions but no actual tool calls — and intervenes automatically.
How It Works
The mechanism is straightforward. When strict-agentic mode detects a plan-only response, it retries the turn up to twice, injecting steering instructions that prompt the model to execute tools rather than describe future actions. If both retries still produce plan-only responses, the turn fails closed with an explicit blocked-state response. No plan-only output reaches the user or downstream systems.
The detection logic is deliberately narrow. It looks for responses that consist entirely of prose plans or structured bullet lists describing intended actions. A response that includes both a plan and at least one tool call passes through normally. The goal is to catch agents that substitute planning for execution, not to penalize agents that think out loud while also acting.
GPT-5 First, Others Later
The feature currently targets GPT-5 family models running through OpenClaw's embedded PI harness. Other providers maintain their default behavior unless explicitly configured. This scope makes sense: the plan-only failure mode is most prevalent in models that are simultaneously capable enough to produce detailed plans and cautious enough to hesitate before executing them.
The configuration lives at agents.defaults.embeddedPi.executionContract for global defaults, with per-agent overrides available through agents.list[].embeddedPi.executionContract. This means you can enforce strict-agentic behavior on your automation agents while leaving conversational agents unconstrained.
The update_plan Tool Got a Quiet Rework
Alongside the execution contract, OpenClaw reworked how the update_plan tool behaves. Previously, plan updates were treated as user-visible content and counted as “progress” for retry logic. Now, the tool operates as internal progress state — it returns structured data with empty text content, and it's explicitly excluded from the retry counter.
This distinction matters because it prevents a subtle escape hatch. Without the change, an agent in strict-agentic mode could call update_plan to technically satisfy the “made a tool call” requirement while still not performing any real work. Now, plan updates don't count as action. The agent has to actually do something.
“Fails closed with an explicit blocked-state response if retries exhaust.”
— OpenClaw execution contract documentation
The Bigger Picture
Strict-agentic mode is part of a broader pattern in OpenClaw toward more opinionated agent behavior contracts. The platform has always been relatively hands-off about what agents do with their turns — it provides tools, manages sessions, and delivers outputs, but the agent decides how to respond. This feature represents a shift toward infrastructure-level guarantees about agent behavior.
The practical value is clearest in automation pipelines. If you're running an agent that's supposed to deploy a service, process a batch of files, or respond to customer tickets, a plan-only response isn't just unhelpful — it's a silent failure. The agent looks like it succeeded from the outside, but nothing happened. Strict-agentic mode turns that silent failure into an explicit one, which is almost always preferable.
The approach also raises a design question that the OpenClaw team will eventually need to revisit: what happens when the correct response actually is a plan? There are legitimate scenarios — a user asking “how would you approach this?” for instance — where plan-only responses are exactly right. Per-agent configuration handles this for now, but it requires operators to know in advance which agents need which behavior. Dynamic intent detection might be the next step.
For now, the feature is opt-in and scoped to specific model families. That's a cautious rollout for a change that fundamentally alters the contract between agent and platform. But for anyone running GPT-5 agents in production automation workflows, it addresses one of the most common reliability complaints in the space.