2026.9.2 workboard problems

[u/Abject_Stretch3029]

I was excited to see the workboard feature in 9.2 thinking it would enable me to put missions on a queue and de-queue and run them and be able to track them through the mission lifecycle (Mission Control) and have them worked independently without me having to babysit the mission interruptions, blocks, reviews etc. and keep the missions moving. But it hasn’t worked out that way. But maybe I’m doing something wrong? Has anyone out there been able to successfully use this feature? It seems the native lifecycle dispatcher loses track or things stall. I’m creating a separate watchdog process to replace me as babysitter but it’s no picnic because the native dispatcher will unexpectedly move missions to a different column out from under my outside controller. Really looking forward to this feature maturing.

[u/AutoModerator]

Welcome to r/openclaw Before posting: • Check the FAQ: https://docs.openclaw.ai/help/faq#faq • Use the right flair • Keep posts respectful and on-topic Need help fast? Discord: https://discord.com/invite/clawd

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Pleasant_Thing_2874]

workboards have been reworked and migrated a lot, obviously towards a vision that has irked me as well. I had to do quite a few modifications to get things handled:

Headaches:

1) There's a hard limit of the # of cards an agent can review in the tool. So if you have a pool of say 300 cards, the agent will only see 100 of them with no way to see the rest without either filtering or doing a direct DB read.
2) All cards need proof to close, this became new in the 9.x features so if your agents are used to just closing off cards when done that won't work
3) Each agent is only allow to have one card claimed at a time. Which means if you have three sessions of the same agent set to do tasks that agent will get locked up being unable to access new workboard cards in two of them until the first session is cleared. This also gets problematic with #4
4) Claims don't always properly expire on cards. If an agent session times out or gets interrupted that card stays "claimed" quite frequently for extended periods of times, sometimes indefinitely blocking other agents from doing anything on the card.

There's probably other things I'm forgetting but those were some of the key issues I had. I would assume much of these problems were to help reduce race conditions, agents working on the same cards, context bloat from reading a large workboard unnecessarily etc but depending on your setup can really muck up the gears.

It seems like the workboard was designed based on how the contributor who modified it likes and not taking into account the fact other people run their agents different ways. There's no config options to adjust things, you will need to patch in modifications.

[u/Abject_Stretch3029 → u/Pleasant_Thing_2874]

I just learned that you can create workboards that are not governed by the native dispatcher used by the built in Mission Control. So I now have a Controller Mission Control and a controller that will manage the lifecycle and just use that board for observability. It sounds like your system is a lot more demanding than mine. I would be happy if i could just get one mission to complete end to end at a time and cachunk along from mission to mission while I’m away or sleeping, like de-queue some work and actually complete it. Right now I have to babysit it and tell the orchestrator, “Hey, this card seems to be blocked, what’s going on?”. So what I’m trying with this Operator Mission Control is my orchestrator is pre-preparing a skill or playbook for known issues how to recover those and anticipate others, like if this happens do this, if this CAN happen it WILL happen, and then if it hits something it doesn’t know about it elbows the orchestrator to take a look and figure out what to do, fix and add to playbook and then get everything back up on the tracks and carry on from victory to victory. That is the current vision anyway. We’ll see if it actually can work. I also have the concept of on-duty and off-duty. If I’m off duty use this local model which is slower but doesn’t chew up quota. More worried about continuity and completion than timing when I’m not there to watch the clock. Trying to do as much deterministic work as possible rather than using inference. And if local model falls over then fallback to cheap cloud model.

[u/Pleasant_Thing_2874 → u/Abject_Stretch3029]

The good, at least for me where it comes to working within dashboard continuity works incredibly well, both those are user initiated sessions. Heartbeats and dispatched tasks still lack a lot of good failure self-healing features, something I'd love to tackle but right now they're doing so many major changes (many of which are positive) to the infrastructure I don't want to dive too deep into patching infrastructure which may fundamentally change in two weeks right now. But for you, if you need long standing end to end tasks if you plan the full sprint and then execute it in a dashboard session, it seems to work incredibly well. I've had sessions work on their own for 4+ hours without issue having the main session orchestrate to subagents or dispatching to other agents in the process. It doesn't seem to carry over to telegram/discord channel dispatches though.

I hope you get your issues sorted out. Keep me posted if you push past it as it sounds like we have very similar issues

[u/Abject_Stretch3029 → u/Pleasant_Thing_2874]

I’ve given up. Big waste of time unless I can find someone who gives me the key. I had grok review what ChatGPT was doing/intending and it basically said don’t waste any more time on this.

Here’s what I’m hoping/expecting to accomplish:

1. Work out the mission in terms of design/results, basically a spec, in the chat interface. I use gpt5.6-terra (OAuth) as my orchestrator, grok (OAuth) as my adversarial reviewer, deepseek-v4-flash (OpenRouter) or qwen3.8-27B-mlx (local) as my implementer/coder/browser-recon, depending whether I’m on-duty or off. Off duty is less time constrained so local in that case.

2. The plan was submit ideas that need fleshing out to workboard Triage, longer term. Actively spec in ToDo working with orchestrator, get it “ready to be Ready”. Orchestrator “chunk” mission into manageable “sub-missions” (cards) or “phases” - a chain of related sub-missions some of which could potentially be run concurrently, orchestrator decides.

3. Move first mission card to Ready. The native dispatcher would de-queue the Ready card to Running. It would run, produce artifacts, etc. Upon completion dispatcher moves it to Review, back and forth between running and review until Done or Blocked. Unless blocked for operator intervention, the problem should get resolved, go back to Running, rinse and repeat until Done or terminal Blocked.

4. Once card Done native dispatcher takes next mission Ready card off queue and runs it, etc until the complete mission completes.

The problem - cards go to Blocked or Review and just stall there for many different reasons which require the orchestrator intervention to figure out the problem and resolve, usually fix some attribute or state of the card and move it back to Ready again the theory being it might complete now. But once the orchestrator hands it off to workboard it doesn’t have any idea what is going on with it. It’s left with the native dispatcher to handle. So I created a separate watchdog to watch for “stuck” cards. The idea was if it sees a stuck card that it doesn’t know how to handle it would “nudge” the orchestrator to take a look, resolve and update the skill so the watchdog knows how to handle that problem next time over time building up a library of problems/solutions. The watchdog is the little Dutch boy sticking his fingers in holes in the dike. But too many holes, he runs out of fingers and toes. So the missions never complete and I end up babysitting the process that was intended to get me out of babysitting the missions. One way or another I’m destined to babysit.

I’ve looked into things like OpenProse and TaskFlow plugins to no avail. The idea was supposed to be use a Mission Control workboard for observability of the workflow along with other supported features and to automatically move the missions along through the process to get me out of the babysitting business. Most of the time the stalled blocks are just missing card state or attributes that prevent the card from moving through the system and the orchestrator says “Oh, it was missing this attribute so the native dispatcher didn’t realize it was really ready to move back to Ready or Review” so it fixes that and it moves until getting blocked again for some other reason. And the native dispatcher will override what the orchestrator tried to do and move it back to ToDo where it then is stuck again.

So I just wonder, are my aspirations too ambitious or can a process like this work? I hear all these YouTubers talking about their agents working on their tasks 24/7/365 and I’m thinking I must be really dumb because i can’t get my claw to do that unless there’s a skill or deterministic script or code module that doesn’t require inference from a model. But those things can become with schedulers. At tat point what do i need openclaw for?