A workflow automation platform is 11 lines of dispatch. Everything else is the editor.

A runtime that defines, schedules, executes, and monitors automated workflows across multiple applications and machines. It includes a place to author workflows (a recorder, an editor, or both), a place to store them (rows in a database, files in source control, or both), a scheduler that decides when each one fires, an executor that drives the actual clicks and typing, and a queue that distributes executions across worker machines. A platform is the runtime, not the editor that ships next to it.

Three things, all visible in the open-source executor crate. First, a workflow row carries a preferred_format column, and the queue processor's dispatch at queue_processor.rs lines 201 through 211 picks between a TypeScript executor and a YAML executor based on that single string. Second, workflow source can come from two places: a GitHub release zip downloaded by uuid for TypeScript workflows, or a workflow.yaml file fetched inline from a GitHub folder for YAML workflows. Third, every execution shares one MCP endpoint, one 600-second per-execution timeout (line 194), and one MAX_CONCURRENT_EXECUTIONS semaphore (defaulting to 10) so a single worker pool serves every team. None of those three things are user-visible features; they are the runtime contract that lets the user-visible features compose. That contract is what a platform is.

Because they cover different authoring populations. YAML is what the recorder produces and what an analyst can hand-edit; the steps array, the on_error and retry_count fields, the cron string, and the typed inputs map are all serializable in 30 lines per workflow. TypeScript is what an engineer reaches for when a workflow needs branching, retries with bounded backoff, structured error handling, or a real loop. Both are first-class on the same runtime: the queue processor calls TypeScriptExecutor::new or YamlExecutor::new without making the rest of the system care which one ran. A platform that locks you into one syntax forces every author into that one syntax; this one does not.

Two paths, picked by format. TypeScript workflows live as a packaged release on GitHub and are downloaded by uuid through https://app.mediar.ai/api/workflows-uuid/download?uuid=<uuid>, with an MCP_SERVICE_TOKEN in the request header. The desktop agent unpacks the zip into a per-uuid folder under the workflows directory before the executor runs it. YAML workflows are fetched inline by the GitHubLoader at services/github_loader.rs, which uses octocrab to GET {folder}/workflow.yaml at a pinned git ref. The legacy github_folder field on the workflow row points at that folder; the new uuid field plus a github_release_url and a github_release_checksum point at the release artifact. Both paths land in the same MCP execute_sequence call.

Ten by default. The QueueProcessor at services/queue_processor.rs reads a MAX_CONCURRENT_EXECUTIONS environment variable, falls back to 10, and gates execution on a tokio Semaphore of that size. Each running execution holds one permit until it returns, fails, or hits the 600-second per-execution timeout (line 194). The machine identifies itself with hostname-{uuid} (line 256), which is what the queue uses to lease a row to one and only one worker. Scaling out is more workers, not a bigger box: the same code on a second machine picks up an unleased row and runs it.

MCP is the model context protocol; the executor talks to a local server on http://localhost:3000 by default (configurable via MCP_ENDPOINT or the execution row's mcp_endpoint field). Every step in either workflow language eventually becomes a tools/call with a tool_name like open_application, type_into_element, or click_element. The reason the platform talks through MCP is that the same set of step primitives can be called by a workflow, a chat agent, or a one-off script with no glue code: there is one transport for all three. The transport also makes the executor trivial to swap; nothing in the queue processor cares whether the MCP server runs the desktop agent, a Windows VM, or a remote runner.

Partial. The WorkflowSequence model in models/workflow.rs has explicit start_from_step and end_at_step fields, plus a follow_fallback flag and an execute_jumps_at_end flag. The intended use is debugging or recovery: re-run a workflow from the step where it failed, or stop at a checkpoint and inspect state, without rebuilding the run from scratch. This is policy, not preference; vendor RPA platforms usually expose a 'rerun from step' button as a UI affordance but bake nothing into the workflow row itself, so a script that calls the platform programmatically cannot use it.

Three timers. First, the per-execution wall clock: 600 seconds in the queue processor's tokio::time::timeout call. If a workflow takes longer than that, the executor's future is dropped and the execution is recorded as a timeout. Second, the desktop scheduler's MAX_SCHEDULED_EXECUTION_SECS at workflow_scheduler.rs line 161, hard-coded to 30 minutes, which terminates a long-running scheduled run via stop_mcp_execution. Third, the SSE buffer cap at MAX_SSE_BUFFER (10 megabytes), which stops a chatty execution from filling memory. None of the three are configurable per-workflow today; they are runtime policy.

UiPath, Power Automate, and Automation Anywhere are platforms in the same sense: they have a runtime, a queue, a workflow shape, and a way to dispatch a row to an executor. The differences are in what the runtime is willing to expose. Mediar's runtime is open source under github.com/mediar-ai/terminator, which means the dispatch, the source loaders, the timeout constants, and the MCP transport are readable. The proprietary platforms ship the same primitives in compiled form behind a license. Honest answer about coverage: where the proprietary platforms invest more is in the visual studio that authors workflows; where Mediar invests more is in keeping the runtime small enough that an engineer can read it on a Saturday and an ops lead can extend it without filing a vendor ticket.

Runtime is billed at $0.75 per minute of execution. There is no per-seat license, no per-bot license, and no per-process license. The $10K turn-key program fee converts to credits with a bonus and is effectively prepaid usage covering the first pilot, including the porting of an existing UiPath or Power Automate workflow. A workflow that runs for 30 seconds costs about 38 cents whether one user kicked it off or a queue of 50 users did. The pricing follows the runtime contract: minutes of executor time, not seats of authoring tool.