CloudCruise, traced through BADGER: a guide to the architecture and where it stops.

Layer one

BADGER: every workflow is a typed graph of browser actions.

The first thing to know is that there is no script. A BADGER workflow is a graph file. The README at github.com/CloudCruise/BADGER calls out the structure directly: nodes are clearly defined browser actions (NAVIGATE, CLICK, INPUT_TEXT, BOOL_CONDITION, EXTRACT_DATAMODEL, and so on), edges are explicit control flow between nodes, including conditions and loops. The unit of authoring is a node; the unit of replay is the graph.

That shape carries a real architectural commitment. A graph file can be diffed in a pull request. A graph file can be statically validated against an input and output schema before a run starts. A graph file can be rewritten by a different agent without breaking everything that referenced it. None of those properties hold for a thousand-line Playwright script. They are the reason most of the new RPA platforms in this generation, including the one this site sells, store workflows as files rather than as recordings.

BADGER also draws an explicit firm line, in the README's own words, between where models help and where they do not. Models help during authoring (turn English into a graph) and during repair (classify a failure, propose a patch). Models do not run the steady-state replay. The runtime walks the graph and executes typed actions; that is it. Most enterprise compliance teams will not accept a model on the runtime path because it makes the bot non-reproducible. BADGER's authoring-AI plus deterministic-replay split is the design choice that lets a browser bot pass a SOC 2 audit and still benefit from frontier models when writing the workflow.

Layer two

Five execution strategies, picked per node, in one ladder.

The interesting part of BADGER is not the node taxonomy. Most browser DSLs have a NAVIGATE and a CLICK. The interesting part is that every node carries a selector_strategy field that picks one of five ways to find the target element. The CloudCruise docs at docs.cloudcruise.com list them under the workflow editor overview. The author picks the strategy when the node is written; the runtime can fall back to a different strategy on retry; the maintenance agent can rewrite the strategy when a node breaks repeatedly.

Read the ladder top to bottom and the design becomes obvious. STATIC is the unit-economics floor: a deterministic XPath, no inference cost, runs in milliseconds. LLM_DOM is the first point where the model enters the loop, but only the trimmed DOM, which the runtime can pre-process to a few kilobytes. LLM_VISION is the slowest and most expensive node type, and the README admits it: vision retries up to fifteen times before a step fails. COORDINATES is the escape hatch when neither selector nor model can describe the target. PROMPT is the agent-shaped escape hatch when the step is genuinely free-form and the graph is willing to spend a model call on it.

What this ladder buys you is graceful degradation. The 2003-era selector-only RPA tools had one strategy, an XPath, and one failure mode, the run stopped. A five-strategy ladder absorbs small UI shifts (LLM_DOM picks the field even though the id changed), medium ones (LLM_VISION picks the button even though the DOM is canvas), and the long-tail of unrepresentable cases (COORDINATES on the last five percent). The price is that every node now has to declare its level of paranoia up front, and the maintenance agent has to know how to walk the ladder when something breaks.

Layer three

The maintenance agent, where the second model lives.

The selector ladder absorbs predictable failure. Unpredictable failure (a portal that ships a new auth screen, a payer that adds a captcha, a vendor that switches to a single-page app framework) needs a different shape of help. The CloudCruise home page calls this the maintenance agent, and the docs describe it as a separate concern: classify the error, repair or retry, escalate when neither works. It is the place where the second model lives, and the place where the most interesting product judgments happen.

The diagram above is the canonical happy-and-unhappy path. A STATIC node runs and matches. An LLM_DOM node runs and the element is not there. The runtime escalates to the maintenance agent, which classifies the failure (the field id changed in the latest portal release), proposes a patch (rewrite the node to a new XPath, or change the selector_strategy to LLM_VISION), re-runs from the failed node, and writes the patch back to the graph file so the next run never sees the failure. That is the self-healing claim, and it is a real one.

The honest limit on this loop is what the maintenance agent can see. It can see the DOM. It can see a screenshot. It can see the network responses the page made. It cannot see a modal that a different Windows process popped up over the browser, it cannot see the system print dialog that an export action triggered, and it cannot see the desktop SAP GUI window that opened when the user clicked a deep link in an EHR. Those are not browser events; they happen in processes the BADGER runtime has no handle on. The maintenance agent is sharp inside its window, and silent outside it.

The boundary

One architectural sentence decides whether CloudCruise can run your workflow.

Every BADGER selector strategy reads the same input surface. STATIC reads document.evaluate. LLM_DOM reads a trimmed copy of document.documentElement. LLM_VISION reads a screenshot of the rendered viewport. PROMPT reads the run context, which is built from prior nodes, which were built from the same DOM. COORDINATES reads literal pixels inside the same browser window. Five strategies, one surface: the browser tab. That is the genius and the limit of the design.

For a workflow that lives entirely inside Chromium, that surface is enough. Vendor portal logins, insurance form fills, payer claim status checks, lead enrichment, document downloads, the long tail of B2B SaaS interfaces, all of those are a tab. The BADGER runtime has the right vocabulary and the maintenance agent has enough signal to keep the runs green. CloudCruise is sharp on this surface and the public customer stories (healthcare browser automation in particular) reflect it.

For a workflow that crosses out of the tab, the surface stops being enough. A SAP GUI window is not a DOM. A Jack Henry green-screen is not a DOM. An Oracle Forms session is not a DOM. A Hyperspace patient chart in Epic is not a DOM, even though the surrounding citrix or browser shell may be. An Excel sheet that the user edits in place is not a DOM. None of these systems expose a document.querySelector to read against, and none of them render through the screenshot pipeline a browser-managed VM understands. The input surface is the Windows operating system itself, and the way to read it is the OS-level accessibility tree.

The same pattern, different surface

How the same architecture looks when the input surface is UIAutomation, not the DOM.

This is the part that is harder to read about, because most comparison pages stop at the marketing claim that one tool is for browsers and another is for desktop. The architectural sentence is more interesting. Mediar's open-source SDK, Terminator (MIT), uses the same overall shape as BADGER: a workflow file, an AI authoring stage, and a deterministic replay engine that walks a small ordered list of match strategies before it gives up. The difference is what each strategy reads.

In apps/desktop/src-tauri/src/focus_state.rs between lines 168 and 196, the restore_focus_state function tries four strategies in order. Strategy one matches on the recorded automation or accessibility id. Strategy two matches on the parent window plus the element bounds. Strategy three matches on visible text content. Strategy four falls back to focusing the parent window so the next step retries from a known anchor. None of the four strategies call a model. All four read the live Windows UI Automation tree, which is the same tree screen readers use to describe a Windows application to a blind user.

That tree exposes role, name, automation id, bounding box, and parent chain for every visible control in every running Windows process. SAP GUI exposes it. Jack Henry exposes it. Oracle Forms exposes it. Epic Hyperspace exposes it. Chrome and Edge expose it as well, which means the same runtime can also drive a browser tab, but through the OS surface rather than through the DOM. Five strategies became four because the data the strategies read is more uniform: a node in UIAutomation has a stable set of attributes that a node in a DOM does not.

The takeaway is not that one architecture is better. It is that they are doing the same job on different surfaces, and the choice of surface is a choice of which legacy systems you can touch. Nothing about CloudCruise's ladder is wrong; it is the right ladder for the surface it reads. Nothing about Mediar's ladder is more sophisticated; it is the right ladder for the surface it reads. Pick the tool by the surface your workflow actually lives on, not by the strategy count.