AI for enterprise functions, through the accessibility tree.

By enterprise functions I mean the org-chart units that own a class of repetitive desktop work: AP, Treasury, Claims, Patient Intake, Bank Onboarding, IT Operations, HR. Each one has at least one legacy Windows desktop app at the center of its workflow, and most of those apps never got a public API. Accessibility matters because Windows publishes a UI Automation tree for those apps automatically. The tree is what screen readers consume. It exposes ControlType (role), Name, AutomationId, and patterns like ValuePattern and SelectionPattern. An AI agent reading off the same tree can drive the field deterministically, regardless of which function the workflow belongs to. That is why one input layer can replace one bot army per function.

No. Traditional RPA tools resolve elements through brittle selectors against a recorded path or, when those break, through pixel matchers and OCR. Both approaches assume the agent's input layer is the rendered surface of the app. The accessibility-tree approach assumes the input layer is the published structure underneath the rendered surface, the same structure a Windows screen reader uses. The practical difference is what survives a patch. If a B1 9.3 to 10.0 upgrade reflows the line item matrix, a pixel-matcher bot breaks. The UIA element with name 'Item No.' and AutomationId still resolves on the new layout, because the form definition keeps the field's identity even when the geometry changes.

Where APIs exist, use them. The question this page answers is what to do when they do not. AP into SAP B1 on Microsoft SQL Server has no Service Layer. Mainframe terminals running 3270 emulators have no REST. Jack Henry, Fiserv, and FIS expose batch interfaces but the day-to-day teller and middle-office screens that ops actually uses do not. Epic has APIs for some operations and not others, and the chart UI is the union surface for the ones that are missing. The accessibility tree is the universal fallback because Windows publishes it for every UI thread, whether the app shipped in 1997 or last week.

Two things, in different parts of the system. At record time, an LLM watches the user perform the workflow once, attaches semantic field names to the captured UIA events, generates the input schema, and writes the workflow file. At runtime, the executor mostly does deterministic UIA calls (type_into_element, click_element, set_value, get_text). The model only re-enters the loop when something deviates: a new dialog appears, a field name changed, a validation message blocked the path. That is when the agent reads the current tree, decides which branch to take, and proceeds or escalates. The deterministic core is what makes the runtime auditable, and the model layer is what lets the bot self-heal instead of failing on every UI change.

Every step the executor runs produces a StepResult: step_id, tool_name (the UIA primitive that ran), status (Pending, Running, Success, Failed, Skipped, Retrying), the structured result, the error string if any, duration in milliseconds, and the retry count. The struct is defined at crates/executor/src/models/execution.rs lines 75-95. The execution row stores the full step list as jsonb under execution_logs alongside a screenshot per step, the trace_id, the client_id, the started_at and completed_at timestamps, and the error_category (Infrastructure or WorkflowLogic). For an AP function moving cash entries, the audit team can replay any execution as a sequence of role plus Name interactions, compare to the original recording, and confirm that no step touched a field outside the workflow's declared schema.

The honest order, from real deployments: insurance claims intake (one mid-market carrier went from 30 minutes per claim to 2 minutes, $750K per year), bank onboarding across Jack Henry or Fiserv terminals (8 weeks to 2 weeks per onboard), patient intake on Epic or Cerner (one regional health system at $210K per year), AP cash posting in SAP B1 (an LG-customer F&B chain saving 70 percent on costs versus their previous UiPath spend). The pattern is: high volume, high-touch, no good API, and a function head who can name the dollar value of an hour saved. Treasury and IT ops are real but tend to ship later because the volume per workflow is lower.

Yes, in 30 seconds per app. inspect.exe ships with the Windows SDK at C:\Program Files (x86)\Windows Kits\10\bin\10.0.x.x\x64\inspect.exe. Open it, set Hover Mode, launch your app, and walk through the form your function uses. For most enterprise apps you will see ControlType.Edit on the editable fields, populated Name properties pulled from the form definition, and AutomationId values on most controls. If those properties are populated, any UIA-based runtime can drive them deterministically. Where a node shows ControlType.Unknown, the runtime falls back to position relative to a parent window plus visible label, which is the only path that resembles classic OCR.

The execution layer is open source under MIT at github.com/mediar-ai/terminator. It exposes the MCP tools (type_into_element, click_element, set_value, get_text, run_command) that the workflow file references. A team can drive any Windows desktop app through Terminator alone, no Mediar cloud, no orchestrator, just the UIA primitives and a Rust binary. The recording app, the cloud orchestrator, the no-code workflow builder at app.mediar.ai/web, the SOC 2 control plane, and the audit trail are commercial. The split is intentional: an enterprise security team can read the source of the runtime that touches their desktops before signing the order form.

The sibling pages on this site go deep on a single surface. The SAP Business One page walks through inspect.exe against the B1 client and shows the locator strategies for ControlType.Edit and the line item matrix. The legacy desktop systems page argues why the accessibility tree is the right fallback when no API exists. This page is the function-level synthesis: the same accessibility tree, applied to AP, Treasury, Claims, Patient Intake, Bank Onboarding, and IT ops, with the role plus Name plus AutomationId triplet you would actually use for each. Read this if you are mapping enterprise function ROI; read the other pages if you are doing the implementation for one specific app.

Three things, in order of frequency. First, an app that renders into a pure DirectX or canvas surface and never registers a UIA provider; you fall back to OCR for that app, which is the worst case but rarely the whole workflow. Second, an app that publishes UIA but with empty Name and missing AutomationId on the field you care about; you have to use position relative to the parent window, which is more brittle than role plus Name. Third, a major version that renames the field across the board (B1 9.3 to 10.0 reflowed the line item grid). The runtime emits structured failures on the unresolved step so a human can re-record that branch in the recording app, instead of silently retrying. For a posting function like AP cash, silent retry is disabled by default because half-posting an invoice is worse than not posting it.