Self-healing is the feature everyone demos and nobody instruments. A locator stops matching, the agent finds the element anyway, the run passes. Useful — right up to the moment the element it found was the wrong one.
How a heal actually works
The step stores intent, not a CSS path: 'the primary Checkout button in the cart summary'. When the stored locator fails, the agent re-resolves against the accessibility tree by role and accessible name, scoped to the nearest stable landmark. If confidence is low it fails the step rather than guessing.
The failure mode nobody talks about
A silent heal turns a regression into a green tick. If a deploy removes the primary Checkout button and the agent settles for a secondary one, the journey completes and the report says everything is fine. Healing is only safe when every heal is a visible, reviewable event attached to the run.
Metrics that keep it honest
Track heal rate — the share of executed runs where at least one step healed — alongside pass rate. Track retry success, the share of heals that produced a passing step. And watch the per-step telemetry: a step that heals on every single run isn't self-healing, it's an unmaintained scenario asking to be regenerated.
The cost side
Heals consume tokens and seconds. A stable run costs a fraction of a cent; a run that re-grounds three selectors costs measurably more and saves a human roughly fifteen minutes of triage. Both numbers appear in the cost and usage widget, so the trade is explicit rather than assumed.
When to stop healing and fix the scenario
If a step's heal rate stays above roughly one in three runs, regenerate that scenario against the current UI and pin the result. Healing is meant to absorb incidental churn between regenerations, not to substitute for coverage that has drifted away from the product.
