> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anchorbrowser.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Self-healing

> How Anchor keeps Automation Tasks reliable — agentic completion during runs and durable workflow improvements afterward.

## Overview

Automation Tasks combine **deterministic Playwright code** for speed and consistency with **agentic steps** when the page needs more flexibility. As websites change, Anchor helps your tasks stay reliable in two ways:

| Layer                     | When it runs                                        | What it does                                                           |
| ------------------------- | --------------------------------------------------- | ---------------------------------------------------------------------- |
| **AI fallback**           | During a run, when a segment needs agentic help     | Completes the step with an AI agent so the run finishes successfully   |
| **Workflow self-healing** | After a run, when any segment completed agentically | Analyzes what worked and creates a new draft version for you to review |

AI fallback keeps today's run on track. Self-healing turns what worked agentically into a stronger deterministic workflow for tomorrow.

## AI fallback

When a step needs more flexibility than deterministic code alone, Anchor completes it with an AI agent. The run keeps going — you get the result, and you can see exactly where the agent stepped in.

### How to spot agentic steps

**On the execution.** Runs that used AI fallback show an **AI Fallback** badge in the task execution list and on the [run detail page](https://app.anchorbrowser.io/tools). Look for it next to the run status.

**On the workflow graph.** Open a run to view the **Workflow Graph**. Any segment that completed agentically shows an **AI Fallback** badge on that segment's card — during the run and after it finishes.

**In the steps panel.** The right-hand **Steps** panel lists each segment in order. Expand a segment to see its logs. When the agent completed that step, an **Agent Logs** section appears underneath — these are the agentic actions taken for that segment.

<Tip>
  Segments designed to run agentically from the start (not fallback) are marked with a **Bot** icon on the workflow graph. AI fallback is when a normally deterministic segment completed agentically instead.
</Tip>

## Workflow self-healing

After a run where any segment completed agentically, Anchor can study the execution and propose an updated workflow that captures what worked. **Nothing goes live automatically** — self-healing creates a draft version and waits for your approval.

### When it triggers automatically

Self-healing runs automatically after workflow runs that give Anchor enough signal to propose an update:

* The task is a **workflow** task that **completed its run** (Anchor can study the full execution and produce a new draft version)
* At least one segment completed **agentically** — via AI fallback — or a **logic segment** surfaced a condition worth updating in the workflow

This often happens on runs that **finished successfully**. The task completed, but one or more steps relied on the agent instead of deterministic code. Self-healing learns from that run so the next execution can stay on the deterministic path.

### Review and approve

<Steps>
  <Step title="Open the execution">
    In the [Tasks UI](https://app.anchorbrowser.io/tools), open the task and find the run that triggered self-healing. Expand the execution to see the **summary** and **suggested improvement**.
  </Step>

  <Step title="Review the proposed changes">
    Click **Apply fix** to open a side-by-side comparison of the current workflow and the healed draft. Switch between **Code** and **Graph** views to inspect what changed.
  </Step>

  <Step title="Test the healed version">
    Click **Test Run** to execute the draft with the same inputs as the original run (or your own). Confirm the updated workflow runs deterministically before promoting it.
  </Step>

  <Step title="Deploy to production">
    Click **Deploy** to promote the healed draft to the task's latest version. Until you do, production runs continue using the previous version.
  </Step>
</Steps>

You can also approve via API — see [Code Tasks](/advanced/legacy-tasks#api-process-for-editing-a-workflow) for reading draft versions and calling `POST /v2/tasks/{taskId}/publish-draft`.

## Webhooks

Subscribe to `task.healed` to get notified when self-healing creates a draft version ready for review:

```json theme={null}
{
  "type": "task.healed",
  "data": {
    "task_id": "tsk_4f8w9n2b",
    "healed_task_version_id": "tv_demo_v4",
    "source_execution_id": "exr_8d2c1fda",
    "error_explanation": "Submit button moved into a new container.",
    "fix_suggestion": "Use accessible label selector instead of XPath.",
    "confidence_score": 0.82,
    "published_as_draft": true
  }
}
```

`published_as_draft: true` means the healed workflow was saved as a draft — not deployed. Use `healed_task_version_id` in your CI or ops pipeline to review, test, and promote the update when ready. See [Webhook events](/webhooks/events) for the full event catalog.

## Next steps

* [Run a Task](/tasks/run-a-task) — execute workflows and inspect execution results
* [Code Tasks](/advanced/legacy-tasks#manually-editing-workflow-json) — read draft versions and deploy via API
* [Webhook events](/webhooks/events) — automate on `task.healed`