Thanks! When a browser action fails or times out, the repair agent should step in to fix the integration and prevent retries from looping. There are also a few conditions where we automatically kick off a repair without a failing job, such as a streak of rejected inputs or site errors. This is to try and prevent silent failures.
Makes sense. But what happens if the repair agent itself gets stuck looping?
If the MCP call returns a 200 OK while the underlying browser times out silently, you're just burning tokens. Are you using a deterministic state hash to hard-kill the run, or relying entirely on the repair agent?