The problem
In a multi-step browser workflow, several actions may already have completed and been verified successfully before a later action fails. I want to evaluate whether that workflow can recover from the failed point without unnecessarily repeating browser actions and reasoning that are already known to be valid.
A useful test would allow several actions to complete successfully, introduce a controlled transient failure later in the workflow, and compare the normal recovery path with a selective recovery approach that preserves valid upstream execution and continues from the smallest justified recovery point.
The goal is to measure final task correctness, repeated browser actions, model/tool calls, recovery time, and how much valid work has to be redone.
I’m building Consistency, a proprietary runtime recovery system for autonomous AI workflows, and I’d like to test this as a narrow external pilot with WebOperator.
https://consistency-runtime.netlify.app/
What you have in mind
A narrow recovery integration point around WebOperator’s plan → act → verify loop.
The rough idea is that, when a later step fails, an external recovery runtime such as Consistency can use the existing execution trace/checkpoint information plus stage validity to determine which completed actions are still trustworthy, preserve those actions, repair the failed boundary, and continue from there instead of restarting the entire goal.
This could be exposed through callbacks/events around verified actions, failures and checkpoints, with a controlled way to resume execution from a selected recovery point.
The goal is not to replace WebOperator’s existing retries, verification or checkpoints, but to add validity-aware selective recovery on top of them.
Area
MCP bridge / external agents
What you tried instead
I have not modified WebOperator itself yet. The closest existing mechanisms are retries, execution history, checkpoints and restarting the goal.
These are useful, but they solve a slightly different problem. A retry can repeat the failed action, and a checkpoint can restore previous state, but neither by itself determines which parts of an already-completed execution are still semantically valid after a later failure.
Full restart is safe but can repeat browser actions, model calls and tool work that already completed correctly.
The missing capability I want to evaluate is selective recovery based on validity: preserve what is still trustworthy, repair only the failed boundary, invalidate dependent downstream state when necessary, and continue.
The problem
In a multi-step browser workflow, several actions may already have completed and been verified successfully before a later action fails. I want to evaluate whether that workflow can recover from the failed point without unnecessarily repeating browser actions and reasoning that are already known to be valid.
A useful test would allow several actions to complete successfully, introduce a controlled transient failure later in the workflow, and compare the normal recovery path with a selective recovery approach that preserves valid upstream execution and continues from the smallest justified recovery point.
The goal is to measure final task correctness, repeated browser actions, model/tool calls, recovery time, and how much valid work has to be redone.
I’m building Consistency, a proprietary runtime recovery system for autonomous AI workflows, and I’d like to test this as a narrow external pilot with WebOperator.
https://consistency-runtime.netlify.app/
What you have in mind
A narrow recovery integration point around WebOperator’s plan → act → verify loop.
The rough idea is that, when a later step fails, an external recovery runtime such as Consistency can use the existing execution trace/checkpoint information plus stage validity to determine which completed actions are still trustworthy, preserve those actions, repair the failed boundary, and continue from there instead of restarting the entire goal.
This could be exposed through callbacks/events around verified actions, failures and checkpoints, with a controlled way to resume execution from a selected recovery point.
The goal is not to replace WebOperator’s existing retries, verification or checkpoints, but to add validity-aware selective recovery on top of them.
Area
MCP bridge / external agents
What you tried instead
I have not modified WebOperator itself yet. The closest existing mechanisms are retries, execution history, checkpoints and restarting the goal.
These are useful, but they solve a slightly different problem. A retry can repeat the failed action, and a checkpoint can restore previous state, but neither by itself determines which parts of an already-completed execution are still semantically valid after a later failure.
Full restart is safe but can repeat browser actions, model calls and tool work that already completed correctly.
The missing capability I want to evaluate is selective recovery based on validity: preserve what is still trustworthy, repair only the failed boundary, invalidate dependent downstream state when necessary, and continue.