The AI in “Mediar AI” runs once, offline. Then it leaves the room.

A small note on which Mediar this is

The name is shared with at least three unrelated companies (an ad-sales platform, a Boston biotech, and a Brazilian retail-analytics firm). This page is about Mediar AI, the Y Combinator backed company at mediar.ai building Windows desktop automation. The open-source executor underneath ships as terminator-rs. If you wanted the company background instead of the architecture, the company page is over here.

The thesis: two phases, one model boundary

Look at the lifecycle of one workflow as a sequence diagram. There are two distinct actors, the desktop recorder and the production executor, and the LLM only talks to one of them. Everything to the left of the boundary is intelligence. Everything to the right is mechanical.

The first six messages happen once per workflow, at authoring time. The last three repeat every time the workflow runs. Notice that the production executor never sends anything to Vertex AI. That is the part most write-ups about this product skip, and it is the only part that matters when a CTO asks about latency, predictability, or what happens when a model provider has an outage.

Evidence one: the AI calls in the recording path

The desktop agent calls Vertex AI in exactly one file: apps/desktop/src-tauri/src/recording_processor.rs. That file imports crate::vertex_ai and calls vertex_ai::call_vertex_ai from four points in the file. Each call is part of the four-stage processing pipeline described in recording_prompts.rs: step analysis, label suggestion, workflow synthesis, and per-step generation.

Two models do that work. The default for step analysis is gemini-2.5-flash, because the volume is one call per meaningful click and Flash is fast enough to keep up with a recording session. The re-labeling pass that turns “Clicked Submit” into “Submitted the new vendor master record” runs on gemini-2.5-pro because the prompt is reading three neighboring steps at once. Both are wired up in vertex_ai.rs with an explicit allowlist of model names; an unknown name falls back to Flash.

Evidence two: the AI calls in the runtime path

Here is the same exercise on the production runtime crate. This is the binary that picks a workflow off a queue, executes it against a Windows session, and writes the result back to the database. It runs in the cloud, it runs on customer infrastructure, and on heavy days it runs the same workflow tens of thousands of times. If a model were involved in the hot path, its name would show up here.

Zero matches. The executor crate is a Rust binary whose only network surface is to the internal database, the MCP server that wraps Terminator, and a workflow downloader for fetching the .ts file from cloud storage. Replace the model layer above with a different provider tomorrow and this binary does not change a line. That decoupling is what makes the system survive an OpenAI outage, an Anthropic price hike, or a frontier-model deprecation notice. The model only matters during recording.

What the recording path actually does

Zoom in on the left side of the boundary. While you record a workflow, the desktop agent is quietly turning every meaningful event into a structured step. The pipeline runs as soon as the session ends, not in real time, so a long recording takes a couple of minutes to process and a short one is ready before you have closed the lid.

The output is a TypeScript file that imports from @mediar-ai/workflow. You can read it, you can edit it, you can put it in source control. The model has compiled your behavior into something that looks like the kind of code an RPA developer would have written by hand, only without the months of selector debugging.

What the runtime path actually does

The right side of the boundary is the same shape but a different kind of machine. The executor reads the .ts file, hands each step to Terminator over MCP, and Terminator does what Terminator does: walks the live UIA tree, picks the matching element, and dispatches a real Win32 input event.

The four-strategy match in step three is the single most important deterministic primitive in the runtime. It is implemented in apps/desktop/src-tauri/src/focus_state.rs and tries, in order: the stored automation ID, the recorded window plus bounds, the visible text content, and finally the parent window. The first three are what absorb a typical UI tweak (a button moves five pixels left, a panel reorders). The fourth is a fallback that asks the next step to retry from a known-good window. None of those four strategies call a model.

For the deeper walkthrough of the recording-to-replay primitive, the inside-look guide opens up the eight-field semantic record per step and the YAML accessibility-tree snapshot that backs it.

Counter-evidence: where the AI does come back

The argument is “the model leaves the room after recording,” not “the model is never invoked again.” Three honest exceptions are worth naming, because most claims of this shape are absolutist and none of them survive contact with reality.

First, on a failed step. If the four-strategy cascade in focus_state.rs cannot find a matching element, the runtime can mark the step for re-recording. The next time a human walks that part of the workflow, the recording pipeline runs, the model authors a fresh step, and the workflow updates in place. The model is invoked, but not on the hot path; it is invoked on what is effectively a code patch.

Second, in the no-code workflow builder. The web app at app.mediar.ai/web has an AI assistant that can write or edit a step from a natural-language description. That is a tool inside the editor, not a runtime dependency. The .ts file it produces still ships to the same deterministic executor.

Third, on parts of the input itself. If a workflow needs to extract structured data from a PDF or a scanned document, the extractor is a model call. That happens at the workflow boundary, not inside the click loop, and it is declared explicitly in the workflow file as an input transform. Compliance teams treat it the same way they treat OCR: it is a documented step, not an emergent action.

Why this split is the actual product

The reason “AI watches your workflow” gets repeated everywhere is that it is the half of the story that fits on a homepage. The half that is harder to put on a homepage, and that does most of the heavy lifting, is the deterministic runtime. Three real consequences fall out of the split.

Latency stays in the milliseconds. A UIA tree walk plus a Win32 click is roughly 50 to 200 milliseconds on modern hardware. A Gemini call would add 1 to 4 seconds per step. Across a 40-step claims-intake workflow, that is the difference between two minutes and two and a half hours per claim.

Cost decouples from volume. Recording is a one-time cost in tokens. Replay cost is dominated by the Windows session, not by an LLM provider. That is the reason Mediar can quote $0.75 per minute of execution honestly: there is no per-step inference bill underneath that has to be subsidized at scale.

Auditability is preserved. The .ts file checked into source control IS the workflow. A reviewer can read it, a security team can diff it, and a compliance officer can sign off on it. That is hard to do when the action sequence is generated fresh by a model every run.

The split, in numbers

Counts come from a fresh ripgrep over the current monorepo: four call sites in the recording path, zero in the executor crate, two model identifiers used in production, and one authoring pass per workflow. Numbers are reproducible if you clone the repo.

The resolution

So what is the right one-line description of Mediar AI? Something closer to: a desktop automation platform that uses Gemini to compile a recorded workflow into a deterministic TypeScript program, then runs that program on Windows with no model in the loop. The product is genuinely an AI product, in the sense that no traditional RPA tool could be built without a frontier-class model authoring the steps. It is also genuinely a deterministic product, in the sense that the runtime would not change if every model provider on earth went offline tomorrow.

The two halves of that sentence are the entire pitch. Most write-ups keep the first and drop the second, which is how you end up with the “AI watches and runs 24/7” line. The version that survives a second read of the source is more boring and more useful: a model writes the script once, and a Rust binary reads the script every other time.

Frequently asked questions