The Agent Got Stuck. Why Did the Entire Mission Stop?
When one agent stalls, the mission should not stall with it. Handing work over safely needs a trustworthy checkpoint and controls on duplicate effects.
Consider a routine customer request. An agent begins. It completes four steps, reaches a stubborn website and gets stuck. For the next twenty minutes it retries the same failing move. The customer sees a spinning icon. The organization sees “in progress.”
Nobody is doing what a good operations manager would do: reassign the work.
One agent should not own the fate of a mission
Human teams survive individual failure because work can be handed over. A colleague reads the notes, checks what was done and takes the next step. Autonomous systems need the same discipline—but handing off to another model is not enough.
The replacement agent needs a trustworthy checkpoint: what was attempted, which actions already had real-world effects, what evidence exists, which credentials are permitted and which next steps remain safe.
Without this, reassignment can make things worse. A payment can be issued twice. A ticket can be reopened. An order can be duplicated. A customer may receive conflicting messages.
Design around the mission, not the worker
MissionFlow is a useful way to think about this problem. The mission has an intended outcome, constraints and acceptance criteria. Agents are execution resources, not the owners of truth.
A supervisor should notice lack of progress, compare alternate routes, decide whether to retry, change tools, request help or transfer the remaining work. The decision should account for time, cost, risk and the amount of completed work that can be preserved.
The MissionFlow simulation shows the pattern in a fictional mission. A supplier portal fails halfway. The supervisor does not start over: the two invoices already collected stay collected, and the third is switched to an Invoice API the mission is permitted to use and handed to the agent that holds that access. The report is marked verified only after its totals are checked.
Critically, the system needs idempotency checks and explicit human approval for consequential actions. “Another agent will finish it” is not a recovery strategy until duplicate effects are controlled.
What to put on the dashboard
Show mission health rather than just agent health. Report percent of outcome verified, time since useful progress, blocked dependencies, recovery attempts, pending approvals and current accountable owner.
The frightening scenario is not an agent failing. Some failure is inevitable. The frightening scenario is an organization that cannot detect the stall, preserve the work or safely change course.
Customers don't care which agent did the job. They care whether the job got done.
Tracston works on these questions in Excapia and Observatory.