Skip to main content
Missions are not fire-and-forget. The orchestrator is an agent, and you can talk to it. When something goes wrong, the most effective move is to pause the orchestrator, describe what you are seeing in plain language, and ask it to recover. The scenarios below cover the issues we see most often, with example prompts you can adapt.
If the mission appears stuck and nothing is happening, pause the orchestrator and tell it what you are seeing. Be direct: explain that the mission appears frozen or broken, describe what the last visible activity was, and ask it to recover. The orchestrator can re-assess the state and pick back up.Example: “The mission seems frozen — the last worker finished 10 minutes ago and nothing new has started. Re-assess and continue.”
If one worker is spinning on a task for too long without making meaningful progress, you do not need to wait for it to finish. Pause the orchestrator and tell it to mark the current item as complete and move on. You can always come back to that item later, or handle it manually.Example: “The worker on the auth integration has been stuck for 20 minutes. Mark it as complete and move to the next feature.”
Sometimes the orchestrator hits a milestone that has become blocked — maybe an earlier assumption was wrong, or a dependency is missing. When this happens, ask the orchestrator to re-assess the remaining work and figure out why it has become blocked. It can re-plan around the obstacle, reorder features, or adjust the milestone scope.Example: “We are stuck on Milestone 3. Re-assess the remaining work and tell me what is blocking progress.”
If you realize the plan needs to change — a feature should be dropped, a new requirement has come in, or the approach is wrong — pause and tell the orchestrator. It can update the plan, re-scope milestones, and continue from the new direction.Example: “Drop the email notification feature and add Slack integration instead. Re-plan the remaining milestones.”
A message like “Feature retry limit reached. A feature kept failing…” means a single feature has failed repeatedly and the orchestrator has stopped retrying it. Inspect the latest worker for that feature to figure out why it keeps failing. Often this is a user-testing validator, which indicates the application cannot be QA’d correctly — the mission has no reliable way to stand up and exercise the app. Make sure your project provides a script that stands up or mocks the app’s dependencies so QA can simulate real user flows, and that logs are written to the filesystem where Droid can inspect them. See Planning & Validation. If the project does not need QA-style validation, disable it in the mission settings inside Mission Control.
If validation workers repeatedly fail, the mission often lacks a reliable way to exercise the running application. Make sure your project has a script that stands up or mocks the app’s dependencies so QA can simulate real user flows, and that logs are written to the filesystem where Droid can inspect them. See Planning & Validation. If your project does not need QA-style validation at all, you can disable it in the mission settings inside Mission Control.

​
See also