Robotic desktop automation, without a Studio: the robot as an importable library your AI coding assistant calls

The shape every other guide assumes

Read any of the canonical writeups on this topic and you will see the same diagram. A user sits at a desktop, a bot process runs on the same machine, the bot was built in a Studio application, the Studio exported a package, an orchestrator schedules the package. That is a reasonable shape, but it assumes the builder is a human with a mouse.

The industry that popularized this shape:

Good products. Wrong shape for a world where your pair programmer is an LLM. An LLM cannot open UiPath Studio, cannot drag activities onto a canvas, cannot read an XAML package back into its context window, cannot make a pull request against a proprietary bot format. It can, however, read a YAML file, edit it, diff it, and commit it.

The fourteen variants, one by one

Each variant exists because replaying without it would be lossy or fragile. These are not Lego blocks in a visual IDE; they are the full surface area of a recording. If a kind of user action is not expressible as one of these 14 variants, the recorder does not capture it, and the replay cannot reconstruct it.

The variant that makes the recorder worth using: TextInputCompleted

The six high-level events are all useful. One of them is the reason a recorder for an AI coding assistant has to exist in the first place. When a user types hello@world.com into an email field, the raw event stream looks like a wall. 16 keyboard-down events, 16 keyboard-up events, a handful of focus updates, three or four accessibility tree refreshes. Replaying that exact sequence breaks the moment the target field has autocomplete, autocorrect, or an input mask that consumes keystrokes in its own way.

TextInputCompleted replaces all of that with one event that carries the text_value verbatim, plus the field metadata and the timing. The replay calls typeText once. The downstream application sees a clean final value, whatever its input pipeline does.

How the synthesis actually works

The function that builds a TextInputCompletedEvent is get_completion_event in crates/terminator-workflow-recorder/src/recorder/windows/structs.rs. It reads the focused field's text once, sleeps 50 ms on failure, reads again, and falls back to a tagged error string rather than silently dropping the typing burst.

The 50 ms retry is not arbitrary. UIA's tree snapshot is eventually consistent; a focus change on a busy window sometimes lands before the property cache refreshes. A single retry at 50 ms catches almost every transient failure in practice without adding observable latency to the recording.

From hooks to YAML, step by step

The full pipeline, from the moment the user starts a recording to the moment an AI assistant reads the resulting YAML, runs six stages. Each stage has exactly one job and hands a fully-formed event or file to the next stage.

What the YAML looks like

Here is a real shape of a recording, lightly abridged. Two text inputs into an Excel sheet, a clipboard copy, a browser tab navigation to a Google Sheet. Notice what the recording does not contain: no pixel coordinates, no raw key codes, no position of the Excel window. The selectors are structured and portable.

What the replay looks like

The replay is whatever code your AI coding assistant writes around the library. No canvas, no bot runtime. In TypeScript, it is ~40 lines that switch on the event kind and call the right library method. The TextInputCompleted branch is the point of all of this: one typeText call replaces the 16 raw keyboard events the user made.

Studio vs library, side by side

The practical difference between the two shapes is not a feature list; it is whether the artifact your automation produces is something an AI assistant can read and modify on its own. Flip between the two views to see how the same work changes shape.

Why one typeText beats 16 key events in the wild

The synthesis matters most on applications that add logic between keystrokes: address fields with autocomplete, IDE-style editors with suggestion popups, forms with input masks that insert separators as you type. A raw-keystroke replay fights those features and usually loses. A typeText call writes the final value and lets the field's input pipeline do whatever it would do if the user had pasted from the clipboard.

The other synthesis wins come from the remaining high-level events. ApplicationSwitch captures why a window change happened (AltTab vs TaskbarClick vs WindowClick), so the replay picks the right method to bring a window to front. Hotkey records the combination as a string, so the replay triggers the application-level handler instead of hoping raw key events line up. FileOpened carries the absolute path, so the replay can recreate the file before re-opening it if the path moved.

Getting started in three commands

There is no installer, no license key, no orchestrator signup. The recorder is a Cargo dependency; the replay is a CLI; the AI-assistant integration is an MCP server. Each is a single command.

The MCP agent ships 35 tools exposed to your AI assistant through a standard stdio or HTTP transport. Add claude mcp add terminator "npx -y terminator-mcp-agent@latest" and Claude Code can call get_window_tree, invoke selectors, record a flow, and edit the resulting YAML, all without leaving your terminal.

A closing note on counting

The count of 0 variants is not marketing. It is whatever is defined in the enum the day you run grep -c "^ *\S.*(" crates/terminator-workflow-recorder/src/events.rs. If the project adds a fifteenth variant next month, you will see it in the YAML the moment you upgrade the crate. The only promise this page makes is that the vocabulary is a Rust enum, checked in, readable, editable, and strictly the source of truth for what a recorder can capture and what a replay can do.