Computer-use agent reliability lives in the tool schema, not the prompt.

Step accuracy compounds. A 95% accurate step across a 20-step real workflow lands at 0.95^20 = 36% end-to-end success. The popular computer-use tools (Anthropic computer_20251124, OpenAI CUA, Gemini Computer Use) ship action verbs only: screenshot, click, type, key, mouse_move, scroll. The model is supposed to compose retry and verification logic in its own chain of thought, on every step. That works on benchmarks where the model is fresh, the context is short, and OSWorld's harness gives it a stable VM. It does not survive real desktop sessions where the same model has to remember to verify each click on hour two of an agent loop. The fix is to push the retry-and-verify into the tool's JSON schema so the executor enforces those semantics on every call without burning model tokens.

Every action tool exposed by Terminator's MCP server (click_element, type_into_element, press_key, scroll_element, select_option, invoke_element, activate_element, open_application, navigate_browser, and others) flattens an ActionOptions struct into its parameter set. That struct lives at crates/terminator-mcp-agent/src/utils.rs lines 216 to 239 and declares four fields: retries (Option<u32>), verify_element_exists (String), verify_element_not_exists (String), and verify_timeout_ms (Option<u64>, default 2000). The MCP server's executor runs the retry loop in Rust with a 250ms sleep between attempts; the post-action verification polls UIA or AX until the predicate holds or the timeout fires. The agent's tool call just says retries: 3, verify_element_exists: 'role:Document'. The model never writes a try/catch.

Alternatives race in parallel; fallbacks run sequentially after the primary times out. Both live in SelectorOptions at utils.rs lines 141 to 169. alternative_selectors fires every selector at once and the first match wins; useful when the same element might be addressable by role:Button|name:Save or role:Button|automationid:btnSave depending on app version. fallback_selectors is sequential, attempted only after the primary times out; useful when the cheap selector fails and you want to fall through to a more expensive one (a regex name match, a deeper window walk). Combine them: primary tries the fast path, alternatives race a couple of variants, fallbacks pick up legacy classnames.

retries handles transient failure of a single step (UI was busy, element appeared 200ms late, the click landed before the listener attached). fallback_id, defined on SequenceStep at utils.rs line 1485, handles permanent failure: when retries are exhausted, the workflow jumps to a named recovery step instead of stopping. You declare a troubleshooting block of steps (utils.rs:1517) and point your action's fallback_id at one of them. Example: if 'click_save' fails after 3 retries, jump to 'fallback_id: dismiss_unsaved_changes' which closes any blocking modal and falls back through to 'click_save' a final time. The whole graph is encoded as JSON; the model writes the happy path and names the recovery handlers.

You can. Anthropic's own computer-use docs recommend prompting the model with 'After each step, take a screenshot and carefully evaluate if you have achieved the right outcome.' Two costs. First, every verification is a full agent turn: screenshot, encode to PNG, ship to the model, wait for the analysis, parse the response. That is roughly one to two seconds and 1,000 to 1,800 input tokens per check. Second, the model can drift. Long agent loops accumulate state; under context pressure, verification gets skipped, hallucinated, or papered over. The Rust executor doesn't drift. It polls UIA or AX until the predicate is true or the timeout fires; cost is microseconds; cost in tokens is zero.

A wrapper retries the same action with the same coordinates. If the model picked (412, 38) because it misread the screenshot, retrying (412, 38) three times does nothing useful. Terminator's retry runs find_and_execute_with_retry (utils.rs:2521), which re-resolves the selector from the live accessibility tree on every attempt. If the dialog moved 20 pixels between attempts, the selector still binds to the right element because role:Button|name:Save is a structural address, not a coordinate. The retry actually has a chance of working because the inputs change every time the tree is re-walked.

verify_element_not_exists is the second of the two verification fields. Same polling behavior; the executor waits until the matching element is gone from the tree or until verify_timeout_ms fires. Useful pattern: click 'Save', then verify_element_not_exists: 'role:Dialog|name:Save As' to confirm the modal closed. If the action ran but the dialog stayed up (because Save was greyed out, because the form was invalid, because focus was on the wrong control), the tool returns an error instead of pretending success. The next step never runs on the assumption that the dialog is gone when it's still up.

find_and_execute_with_retry in crates/terminator-mcp-agent/src/utils.rs at line 2521 sleeps Duration::from_millis(250) between attempts. That number balances two things: long enough that an app under transient load has time to recover (typical UI redraw budget is one frame at 16ms, but post-click handlers can run 100 to 200ms), short enough that 3 retries finishes inside a second. There's also find_element_with_fallbacks ahead of it which has its own timeout per selector, so a primary that times out at 1000ms then a fallback that times out at 1000ms then 250ms sleep then another attempt all adds up to a worst-case budget of a few seconds for a 3-retry step. That's tight enough not to drag on long workflows and loose enough to absorb realistic UI flake.

The tree-walking approach has a real ceiling. If the target element doesn't publish AX or UIA properties (custom-rendered Canvas, WebGL, native game engines, raster image regions in Photoshop), no selector resolves. Terminator's MCP exposes capture_screenshot and gemini_computer_use tools for exactly those cases; the pixel loop is still available when you need it. The bet is that 95% of the desktop apps a production agent has to drive (Excel, Outlook, Chrome, Slack, SAP, Salesforce, CRMs, banking portals, IDEs) do publish a tree, and the reliability primitives on the tree-walking side make those 95% dramatically more boring to automate. The remaining 5% can fall back to vision when they have to.

Install the MCP server once: claude mcp add terminator 'npx -y terminator-mcp-agent@latest'. Or in Cursor/VS Code/Windsurf settings, point at the same npx command. The MCP server registers 35-odd tools, each of which already accepts retries, verify_element_exists, and the selector redundancy fields. Your agent gets those primitives by tool description; the model picks them up the next time it inspects the tool schema. If you've got an agent harness today that uses Anthropic's computer_20251124, keep it for the screenshot fallback; route the structural calls (open app, click button by name, type into named field, verify state) through Terminator's MCP tools and watch your retry-loop tokens drop.