CloudCruise, the company

CloudCruise at a glance

What it is

Developer platform for browser agents

Founded

2024 (Y Combinator W24 batch)

Headquarters

San Francisco

Founders

Adrian Ziegler and Felix Eckert

Funding

$5M seed (2026), after a YC W24 pre-seed

Backers

Floating Point, Meridian Street Capital, Twine Ventures, Refract Ventures; angels Zachary Lipton (CTO, Abridge) and David Singleton (former CTO, Stripe)

Focus

Healthcare automation: payer-portal and EHR workflows on managed infrastructure

Website

cloudcruise.com

Funding and headcount move fast at an early-stage company. Treat the figures above as a snapshot from mid-2026 and confirm the current numbers on cloudcruise.com or a funding database before you quote them.

How a CloudCruise automation actually runs

The shape of the product is developer-first. Instead of clicking around a low-code canvas, you define a workflow once and call it like any other endpoint. The actual execution is the part worth understanding, because it is also where the boundary lives: every step happens inside a real, managed Chrome session.

This is a clean design for web work. It is fast to call, it scales on managed infrastructure, and the maintenance agent takes real maintenance pain off your plate. The unavoidable consequence is the third actor: a Chrome session. A CloudCruise agent can only see and act on what a browser renders.

The boundary every profile page skips

PitchBook, Tracxn, Crunchbase, and the YC page will all tell you the same things: browser agents, design once, trigger via API, $5M seed, healthcare. None of them tells you the one architectural fact that decides whether the tool fits your stack: it runs in a browser, so it reaches what is in a browser tab and nothing else.

That matters most in exactly the verticals CloudCruise targets. Plenty of healthcare and back-office work lives in native Windows thick clients, not web pages: the SAP GUI client, Epic Hyperspace, Cerner, eClinicalWorks, banking cores like Jack Henry and Fiserv, and mainframe green-screens published over Citrix. A browser agent cannot open those, because they never render as a website.

That is the whole reason a second category of tool exists. Where the workflow lives outside the browser, you need to read the interface at the operating-system level. Windows exposes an accessibility tree (the same interface screen readers use) for native apps. Reading and driving an app through that tree is how you reach a thick client with no API, and it is the line Mediar is built on.

Browser agent vs desktop accessibility agent

This is not a takedown. The two approaches are good at different things, and the right answer is usually decided by one question: does your workflow live in a browser tab, or in a native window?

Where Mediar fits in the same conversation

Mediar replaces enterprise RPA (UiPath, Automation Anywhere, Power Automate) with AI agents that watch a workflow once and then execute it through Windows accessibility APIs. There are no brittle pixel matchers or selectors, so automations self-heal when interface labels or layouts change. It is roughly 20% of UiPath's cost and reaches production in days instead of months, and there is an open-source SDK, Terminator, for teams that want to extend it.

Concretely, we moved an LG-customer F&B chain off UiPath onto Mediar and their CFO told the board they are now saving 70% on costs. At one mid-market insurance carrier, claims intake went from 30 minutes per claim to 2 minutes, which is roughly $750K a year in their AP-team headcount math. None of that runs in a browser; it runs in SAP and in claims desktops, which is precisely the layer a browser agent cannot reach.