Tools for robotic process automation: the 28 named primitives an RPA runtime is actually built from.

Two different things, depending on who is asking. A buyer at a CFO offsite uses the phrase to mean a vendor product, and the listicles that rank for the phrase return UiPath, Automation Anywhere, Power Automate, and Blue Prism. An engineer scoping a build uses the phrase to mean the catalogue of named primitive operations the runtime publishes: click_element, type_into_element, get_window_tree, and so on. Most listicles answer the first version of the question. This page answers the second one, because the second one is the layer at which any RPA program is actually graded. A vendor with a smaller, sharper toolset that you can read end to end will outperform a vendor with a larger toolset that you cannot.

The count is a tell. UiPath ships over 200 activities, Power Automate Desktop ships over 400 actions, Automation Anywhere ships over 600. The Mediar runtime ships 28 named tools. The first three numbers grow because the vendor adds a new activity for every common workflow shape they want to sell support for: send an email, post to Slack, query a SQL database, parse a CSV. Each new activity is a new surface to maintain and a new selector grammar to learn. The 28-tool catalogue takes the opposite bet: a small set of OS-level primitives plus a YAML executor, and the workflow itself composes the higher-order behavior. "Send an email" stops being an activity and becomes a four-step sequence (open_application Outlook, click_element compose, type_into_element body, click_element send). The smaller surface is the durable one, because the OS primitives change less often than the SaaS connectors do.

Because no single vision source covers every screen a buyer brings. The cheapest and most reliable source is the Windows UI Automation tree, which works for SAP GUI, Oracle EBS, Jack Henry, Fiserv, FIS, Epic, Cerner, Office, and most line-of-business apps. The browser DOM source covers Chromium tabs. OCR catches Java Swing, Citrix sessions, and old terminal emulators. Omniparser catches custom OpenGL surfaces and games. Gemini Vision is the fallback for anything that none of the others can describe, used inside gemini_computer_use to pick a next-click target from a screenshot. The honest tool says which source it used for a given click in the trace, so a buyer auditing a deployment can see when the runtime fell off the deterministic path. The five-source enum is in node_modules/@mediar-ai/terminator/index.d.ts under the VisionType type.

UiPath organises its activity library around use cases (UI Automation, Mail, Excel, PDF, System, etc.) and ships hundreds of activities, many of them paid add-on packages. The Mediar catalogue is organised around runtime primitives. Excel is not a category; it is the application Mediar drives via click_element and type_into_element. Mail is not a category; it is a sequence against the active mail client. The activity-library approach is friendlier to a designer who wants to drag-and-drop a complete flow without reading a tree. The primitive-catalogue approach is friendlier to anyone who has to debug a flow at three in the morning when the screen has changed and the activity is still passing. Both shapes are real choices; the right one depends on whether your team is sized for designer-led builds or for engineer-led debugging.

Functionally overlapping, structurally different. A UiPath Studio activity is an XAML node that wraps a .NET assembly. The activity definition lives in a vendor-published package, the runtime is the UiPath Robot, and the catalogue is closed source. A Mediar tool is a named handler exposed by the terminator-mcp-agent process over the Model Context Protocol. The handler source code is in the public repo at github.com/mediar-ai/terminator under the terminator-mcp-agent crate. An RPA team can read what click_element actually does, fork it, swap the underlying find strategy, and pin a custom build. UiPath does not allow this. Whether that matters depends on whether your security or compliance review needs to inspect the runtime end to end.

Computer-use models still use tools. They just hide them. An OpenAI computer-use call ultimately calls click(x,y), type(text), screenshot(), and key(name) inside the harness. The tools are there; they are just unnamed and unloggable from the buyer's side. The honest computer-use product publishes the toolset it is calling and lets the buyer audit it. Inside Mediar's runtime, the model lives behind gemini_computer_use, and every click the model issues is captured as a click_element call with a selector synthesised from the screenshot. The trace shows which tool the model picked, what selector it gave, and which vision source it used. "Zero tools" is a marketing posture, not an architecture; if you cannot see the tool list, the product is not actually toolless, it is just opaque.

Element interaction tools (click_element, type_into_element, set_selected, validate_element) all consume a selector. The selector is resolved at runtime by a four-strategy match cascade: exact role-plus-name match against the live tree, fuzzy name match within the same role, tree-path match using the captured ancestry, and visual fallback through the vision sources above. The cascade is the reason the catalogue does not need a separate find_by_role, find_by_name, find_by_xpath, find_by_image quartet of activities, the way UiPath does. One selector type, four strategies under the hood, one named primitive on the public side. The cascade lives in apps/desktop/src-tauri/src/focus_state.rs in the Mediar product monorepo.

It grows, but slowly, and additions get pushed back hard. The default move when a customer asks for a new behaviour is to compose it from the existing primitives rather than to ship a new tool. A new tool gets added only when the existing ones cannot reach the behaviour at all (the addition of capture_dom, for example, was forced by browser flows where the accessibility tree was strictly weaker than the DOM). The discipline is deliberate. A larger catalogue is easier to demo, harder to maintain, and a worse experience for an engineer who has to remember which of 600 actions to pick. The current 28 is a long way from the 600+ that Automation Anywhere ships, and the gap is the point.