[Feature Request]: Add Strict Agentic Mode (Reject Non-Actionable / Empty-Action Outputs)

Summary

OpenClaw is already strong for general-purpose agent workflows, but in industrial / execution-heavy environments there is still a costly failure mode:

the model emits a conversational ACK instead of an actionable turn.

Examples:

• “Okay, I’ll check.”
• “Got it, working on it.”
• “Let me investigate.”
• “I’ll handle it.”

In casual chat this is harmless.

In serious agentic environments (ops automation, financial workflows, execution pipelines, monitoring, remediation, high-frequency task routing), this is not harmless at all. It is effectively a null-action turn that:

• consumes tokens,
• delays execution,
• pollutes user-facing output,
• creates false progress,
• and can break deterministic operational expectations.

Problem

Today, the system appears optimized for flexibility and general conversational usability, which is correct for broad adoption.

However, there is currently no first-class framework-level way to say:

“For this session / agent / environment, non-actionable conversational filler should not be considered a valid successful reply.”

That creates a gap for users who run OpenClaw more like:

• an execution engine,
• a command router,
• an industrial operator,
• a monitoring / remediation layer,
• or a deterministic workflow controller,

rather than a chat assistant.

In these environments, an ACK without action is not “a style preference”.
It is an execution bug class.

Real-world impact

In production-like workflows, this shows up as:

1. Action illusion

   • The model says it will do something.
   • No tool call happens.
   • No meaningful result is produced.
   • The turn still appears “successful”.

2. False operational confidence

   • The user sees a confident reply.
   • The system has actually done nothing.

3. Waste amplification

   • More turns are needed to push the model into actual execution.
   • More tokens are consumed.
   • Latency increases.
   • In automated pipelines, retries or watchdogs have to compensate for something the framework could have filtered earlier.

4. Poor fit for strict automation

   • In some workflows, “chatty but empty” output should be rejected by design.

Proposed solution

Option A — Strict Agentic Mode

Expose a configuration switch such as:

{
  "agents": {
    "strictActionOnly": true
  }
}

Or scoped variants like:

{
  "agents": {
    "defaults": {
      "strictActionOnly": true
    },
    "byAgent": {
      "ops-guard": {
        "strictActionOnly": true
      }
    }
  }
}

Expected behavior in strict mode

When enabled, before a turn is accepted as a valid assistant reply, OpenClaw should evaluate whether the turn is meaningfully actionable or final.

For example, reject replies that are:

• short conversational acknowledgements,
• promises of future action without present action,
• “I will check” / “working on it” style filler,
• and other non-result, non-tool, non-final-output responses.

If the reply is rejected:

• do not deliver it to the frontend,
• emit a structured internal error / validation failure,
• optionally trigger a retry path,
• and allow the runtime to request a regenerated answer.

Option B — Output Validation Hook

If a hardcoded strict mode is too opinionated, then please expose a first-class hook such as:

• before_output_accept
• onBeforeAssistantOutput
• validateAssistantTurn
• or similar

Example conceptual API:

type OutputValidationResult =
  | { accept: true }
  | { accept: false; reason: string; retryable?: boolean };

registerHook("validateAssistantTurn", async (event, ctx) => {
  const text = event.text ?? "";

  if (isEmptyAck(text) && event.toolCalls.length === 0) {
    return {
      accept: false,
      reason: "Non-actionable ACK reply rejected in strict execution mode",
      retryable: true
    };
  }

  return { accept: true };
});

This would let users implement their own policy without patching runtime internals.

Why this should live in the framework

Right now, users who need this behavior may be forced to patch runtime internals or implement fragile local workarounds.

That is undesirable because:

• upgrades overwrite local patches,
• the behavior is not standardized,
• policy enforcement becomes ad hoc,
• and the most serious users end up fighting the framework instead of extending it cleanly.

A framework-level mechanism would be better because it is:

• explicit,
• configurable,
• auditable,
• composable,
• and much easier to maintain across upgrades.

Important nuance

This request is not asking OpenClaw to ban conversational behavior globally.

For many users, conversational ACKs are perfectly fine.

This is specifically a request for:

• strict execution-oriented deployments
• industrial / operational / deterministic agent environments
• where “non-actionable assistant filler” should be treated as invalid output

So the ideal design is:

• opt-in
• scoped
• configurable
• and possibly hook-based

Suggested acceptance criteria

A good implementation would allow users to:

• enable strict mode globally or per agent/session
• reject assistant turns that contain no meaningful action/result
• differentiate between:
  • valid final answer
  • valid tool-driven action
  • invalid conversational filler
• suppress rejected filler from user-facing delivery
• emit structured telemetry / logs for rejected turns
• optionally mark the rejection as retryable

Example “should reject” outputs in strict mode

• “Okay, I’ll check.”
• “Got it.”
• “Understood, working on it.”
• “Let me look into that.”
• “I’ll handle it now.”

Example “should accept” outputs in strict mode

• actual tool calls
• concrete final conclusions
• concise result-bearing replies
• user-visible messages that are intentionally sent via messaging tools
• valid short answers that are genuinely final (not placeholder acknowledgements)

Closing

OpenClaw is already very close to being an excellent execution-grade agent runtime.

Adding either:

1. a native Strict Agentic Mode, or
2. a first-class assistant output validation hook

would make it significantly more suitable for serious automation environments where “ACK without action” is not a UX quirk, but a real operational defect.

Thanks — happy to help refine the shape of the API if this direction sounds useful.