openclaw - 💡(How to fix) Fix Feature request: unified execution planner and background task status dashboard [2 comments, 1 participants]

Summary

OpenClaw is powerful, but once you start using it heavily, two UX gaps become very obvious:

1. Execution routing is too implicit
2. Background task visibility is too fragmented

I'm opening this issue because these two problems create a lot of operator overhead for both users and agents.

Problem 1: execution routing is implicit and mentally expensive

Today, a lot of task routing logic lives in prompts, skills, conventions, and agent experience.

For many requests, the agent has to implicitly decide:

• should this run in the main session?
• should this be delegated to a sub-agent?
• should this go through ACP?
• does this require a skill load first?
• does this require explicit confirmation?
• is this a channel-sensitive action with special reply rules?

The system can do all of these things, but the decision process is not explicit enough.

This creates friction:

• more hesitation before execution
• more hidden policy complexity
• more inconsistent tool selection
• more room for silent mistakes in channel-sensitive operations

Proposed direction: unified execution planner

Introduce a lightweight planning/routing layer that classifies each task before execution.

Example output shape:

{
  "mode": "direct",
  "reason": "simple local lookup",
  "risk": "low",
  "recommended_tools": ["read", "exec"],
  "skill_to_load": null,
  "requires_confirmation": false,
  "channel_policy": "reply_in_current_chat"
}

Useful dimensions:

• task kind: question / search / local edit / external write / long-running
• risk level: low / medium / high
• expected duration: seconds / minutes / background
• execution target: main / subagent / acp / confirm-first

This could start as:

• an internal planner used before execution
• a debug/inspection API or CLI (openclaw route ...)
• later a visible UI hint for explainability and override

Problem 2: background tasks need a unified status dashboard

OpenClaw already supports async work well across:

• main sessions
• sub-agents
• ACP sessions
• exec/process flows

But status visibility is still too low-level and fragmented.

Right now, operators often have to mentally stitch together state from:

• sessions
• subagents
• process logs
• tool results
• ad hoc runtime events

That means the system is technically observable, but not semantically legible.

What users and agents actually want to know is:

• what is this task doing right now?
• is it blocked?
• why is it blocked?
• does it need intervention?
• is it done and just waiting to be reported?

Proposed direction: unified background task dashboard

Introduce a task-centric status model that is separate from raw sessions/processes.

Suggested per-task fields:

• task name
• owner / executor (main, subagent, ACP, process)
• current phase
• block reason
• latest meaningful update
• suggested next action

Suggested normalized phases:

• queued
• starting
• reading_context
• researching
• planning
• editing
• testing
• waiting_user
• waiting_approval
• waiting_dependency
• summarizing
• done
• failed
• stalled

Suggested block reasons:

• waiting for user input
• waiting for confirmation
• waiting for approval
• waiting for OAuth / auth
• waiting for subagent
• waiting for external API
• suspected stall (no heartbeat / no new output)

Important design point

A task should not be treated as identical to a session.

A single user-visible task may involve:

• main session planning
• one or more sub-agent runs
• one or more exec processes
• retries
• final summarization back in the main session

So the model likely needs:

• Task = user intent unit
• Run = one execution attempt
• Worker = actual runtime/session/process

Why this matters

These are not just convenience features.

They directly improve:

• reliability
• explainability
• operator confidence
• long-running task ergonomics
• safety for externally visible actions
• consistency across tools and channels

In short:

• an execution planner helps OpenClaw decide how to start work
• a unified task dashboard helps OpenClaw explain what is happening after work starts

Together, they would make the system feel much more like a coherent agent runtime and much less like a powerful set of loosely coordinated mechanisms.

MVP suggestion

Execution planner MVP

A lightweight planner that outputs:

• mode
• reason
• recommended tools
• skill to load
• whether confirmation is required

Status dashboard MVP

A normalized task event model with:

• task id
• phase
• summary
• last update time
• blocked/stalled detection

Even a simple read-only view would already be very useful.

Happy to help refine

If this direction makes sense, I'm happy to help break it down further into:

• planner heuristics
• event schema
• task/run/worker model
• CLI/UI entry points
• minimal integration points in current OpenClaw architecture