What Automat (YC) is, and the one thing its pages never compare: who owns the engine

What Automat actually does

Automat is one of the stronger entries in the new wave of AI-native RPA companies. The original YC launch described it plainly: robotic process automation for Chrome using ChatGPT and computer vision. Since then it has broadened. Today it pairs UI agents (a proprietary transformer-based RPA engine that mimics how a person uses an interface) with API-driven automations and intelligent document processing, and it says it runs across Windows apps, Citrix, web portals, and legacy systems without API access.

The way you adopt it matters as much as the technology. Automat's own three-step process is: you upload a screen recording or process docs, then Automat's team and AI agents build, validate, and test the automation, then it deploys via hosted cloud, on-prem, or a custom API. The company hires forward deployed engineers and sells a done-with-you model. That is a deliberate choice, and for some buyers it is exactly the right one. It is also the thing that separates it most from how Mediar is built.

Two ways to own an automation

Strip away the marketing and there are two structurally different answers to the question “where does the automation live, and who can change it?” Automat answers it one way. Mediar answers it the other. Neither is wrong; they optimize for different teams.

The anchor fact: you can read Mediar's engine before you trust it

Here is the part you can verify yourself, today, without a sales call. A Mediar workflow is not a black box that a vendor operates on your behalf. It is a plain-text file: a list of steps, each with a tool, a target, and its own error strategy. The same engine that runs it, the Terminator SDK, is open source under the MIT license and primarily written in Rust, at github.com/mediar-ai/terminator.

Notice the selector lines. They do not say “the box at x=412, y=290” and they do not hand a screenshot to a vision model. They name the control: role:Edit|name:Vendor Code. That is a lookup against the Windows accessibility tree, the same structured list of controls every well-behaved app publishes for screen readers. The on_error field is equally concrete: each step is stop, continue, retry, or fallback, so a failed step does something you specified rather than something a hosted runtime decided for you.

And because the lookup is by role and name, you can confirm a given app is automatable before you write a single step. Run the engine's inspector against the window and it prints the controls it can see, sourced from the accessibility tree rather than a picture of the screen:

This is the difference that does not appear on any page ranking for Automat. Their pages tell you what the product does and who funds it. None of them let you read the engine and decide whether your own legacy screen exposes the fields by name. With an open-source engine, that is a five-minute check, not a procurement question.

Why the targeting layer is worth arguing about

The reason any of this matters is that the expensive, stuck workflows in most enterprises sit on no-API desktop software, and that is exactly where recognizing a field from its rendered image is the hardest. When the targeting layer holds, the savings are real and the workflow is named, not a press-release rounding.

For the underlying mechanism, see the pixels-versus-accessibility-tree breakdown (written about another vision-based RPA company, Sola, but the engine argument is the same), and why no-API legacy desktop apps are the real moat.

Where Automat's model is the better fit

If you want a funded partner to own automation delivery, you have the budget for a forward-deployed engagement, and your workflows live on surfaces a vision engine handles cleanly, Automat is a credible choice, and its $15.5M Series A says the market agrees that AI agents are eating legacy RPA. The honest dividing line is not which company is better in the abstract.

It is two questions about your own situation. Do you want to own and extend the engine yourself, or have it operated for you? And do the systems you are automating publish a usable accessibility tree, or do they only exist as pixels on a screen? If your answers are “own it” and “the data is in SAP GUI, a mainframe terminal, Jack Henry, Fiserv, FIS, Epic, or Cerner,” the open-source, tree-reading approach is usually the one that survives in production.