Automation scripts for Windows, when one API covers every app

Where the existing playbooks leak

Walk through the common advice online. PowerShell gives you cmdlets, pipelines, and WMI queries. Perfect for services, registry edits, and system hygiene. You do not use it to click the Send button in Outlook. AutoHotkey compiles a tiny script into a global hotkey that can simulate keys and Win32 control clicks. Perfect for swapping Caps Lock to Escape or remapping a macro pad. You do not use it to drive a UWP Calculator or to work inside a Chromium-based app where the DOM is not a Win32 handle.

AutoIt adds window and control manipulation on top of key-simulated input. Task Scheduler runs your scripts at fixed times. All useful. None of it solves the actual problem of 2026: an AI assistant should be able to read the state of any window on your desktop, decide which control to touch, and touch it. The input surface has to be the accessibility tree, not a keystroke and not a pixel.

That is the shape Terminator takes. The selector engine (the core primitive) is a single Rust enum with 24 variants. The execution surface is a Playwright-style locator API in Rust, TypeScript, and Python. The AI surface is an MCP agent with 35 tools, served over stdio or HTTP, installable in one line.

The anchor fact: 24 primitives, one file

Open crates/terminator/src/selector.rs in the Terminator repo. The pub enum Selector at the top of the file declares every way a script can identify an element in a Windows app. Count the variants, skip the Invalid error variant, and you get 24. They are the entire vocabulary of a Terminator selector string, and every SDK parses into the same enum.

The grammar: prefix with role: / name: / nativeid: / classname:, chain sub-selectors with |, combine with && / ||, anchor by spatial relation with rightof(), near(), and filter descendants with has() (Playwright-style :has). That is the full alphabet.

The shape, in numbers

Four numbers to keep in mind when you compare this to the older tooling. They come from the Terminator source, not a benchmark post.

A hotkey macro versus a selector script

Both scripts below open Calculator and compute 1 + 2. The left one is the AutoHotkey shape that pages on this topic still teach in 2026. It hardcodes pixel offsets and the window title, so a Windows 11 layout change or a high-DPI monitor kills it. The right one is the first example in examples/win_calculator.py in the Terminator repo. It targets semantic names through the accessibility tree, so the same script works on Windows 10, Windows 11, arm64, and a Citrix remote desktop.

; autohotkey_v2.ahk
; Open Calculator and compute 1 + 2.
; The script hardcodes a pixel ordering plus
; a controlled window title, so it breaks the
; moment the Calculator layout changes.
Run "calc.exe"
WinWait "Calculator"
WinActivate "Calculator"

; Click (1) by relative coordinates.
ControlClick "x50 y180", "Calculator", , "Left"
Sleep 200
; Click (+)
ControlClick "x150 y180", "Calculator", , "Left"
Sleep 200
; Click (2)
ControlClick "x100 y180", "Calculator", , "Left"
Sleep 200
; Click (=)
ControlClick "x200 y220", "Calculator", , "Left"
Sleep 500

; Read the result via OCR on a screenshot.
; That part is not included here.

How an AI coding assistant actually runs this

Installing the MCP agent is one line per client. Once that is attached to Claude Code, Cursor, VS Code, Windsurf, or anything else that speaks MCP, the assistant that already writes your code also gets 35 tools for controlling every app on your desktop. This is the diagram of the loop.

The MCP agent is a single npx-installable server. The tools match the locator API so the assistant does not need special prompting to use them. When a selector goes stale, the assistant calls get_window_tree, reads the JSON, and picks a new selector. The loop recovers without giving up the script.

Install, in a single terminal session

Pick the shape that matches the rest of your stack. Each of these installs points at the same underlying Rust core, so a script written in one ports cleanly to the others.

What the 35 MCP tools actually do

Every one of these is defined as a #[tool(...)] attribute in crates/terminator-mcp-agent/src/server.rs. They are the same primitives an SDK script calls; the MCP agent just puts them on the wire so a language model can use them directly.

A workflow, not a macro

The @mediar-ai/workflow SDK wraps steps, state, and error recovery around raw calls. Each step is a typed function with execute and onError, sharing context through a Zod-typed object between steps. This is how you write a Windows automation script that survives flaky production conditions without turning into a pile of try / except.

Record once, replay deterministically

If you prefer not to write the script by hand, there is a workflow recorder. It lives at crates/terminator-workflow-recorder and captures mouse, keyboard, clipboard, hotkeys, text input completion, and UI focus / property / structure changes. Double clicks are detected with the Windows-standard 500 ms time window and a 5-pixel distance tolerance (see the README for the tracker tests). The output is timestamped JSON with the full accessibility-tree metadata for each interaction, so the replay uses selectors, not coordinates.

The config lets you filter noise from system UI: clock updates, taskbar, notifications, dwm.exe, and explorer.exe are all ignorable out of the box via the ignore_applications and ignore_focus_patterns fields. Once the recording is saved, you can feed the JSON back through the same MCP tools that would run a hand-written script.

Three numbers worth memorizing

Watch one script execute, in three frames

Terminator versus the traditional tooling

Frequently asked questions