TaskSultan turns a process description into a TypeScript automation and runs it. The automation is the artifact. It is readable, it is reviewed in a pull request like any other code and it keeps working if this platform is not around to run it.
That last point drives most of the design. Plenty of automation tools hold your process in a proprietary file that
only their own runtime can open. Here the automation is a .ts file that imports a small runtime and calls it.
#The pieces
Automations are TypeScript files in automations/. Each one declares what it is, which capabilities it needs and
what its steps are.
Targets are the elements an automation addresses, kept apart from the automation itself in targets/. A target has
a name, a description and an ordered list of ways to find the element on screen. When the first way stops working the
platform falls through to the next one rather than failing the run.
The Robot executes automations. It is deliberately small. It has no designer, no AI and no business rules. All of that lives in the platform, which means a Robot is roughly "a container with a browser and the runner in it".
The Orchestrator is the queue, the scheduler, the credential vault, the robot registry and the record of what ran. It sits beside the Robot rather than inside it.
The Studio is where you write and watch work. It runs in a browser and there is a desktop shell that can point at a live Windows control and hand it back to the Studio as a locator.
#What "deterministic" means here
The same automation takes the same path every run. There is no model deciding what to click at execution time. If the platform cannot find an element you pointed at, it stops and says which element it wanted and what it saw instead:
ctx.desktop.press: no element on the desktop matches <locator> — the desktop is up and rendered, and the
accessibility tree offers no such control. Nothing was pressed and nothing was guessed
→ DESKTOP_TARGET_NOT_FOUND
That refusal is the product working. A run that guesses is a run you cannot put in front of an auditor.
AI is used where it belongs, which is writing the automation with you. Once written, the automation is ordinary code and a model is not in the execution path.
#Where it runs
On your machine, with your data. The vault is a file on disk, the runs write artifacts to a folder you choose and the Queue lives in the local state root. Nothing is sent to us unless you point a remote model at the authoring step, and you can leave that switched off and write the TypeScript yourself.
#How this compares
Against UiPath: the shape is familiar on purpose. Transactions, retries, business against system exceptions, an object repository, a queue, a credential store and a human approval step all exist here and there is a migration path that reads a UiPath project and tells you what converts and what does not. The difference is the artifact. Yours is a UiPath workflow file. Ours is TypeScript you can read.
Against Playwright on its own: you get the same browser engine, plus the parts a Playwright script does not have. Transaction loops, exception lanes with the two kinds of failure kept apart, retries with backoff, named targets with fallbacks, screenshots and traces on every run, a credential vault and a queue.
#What is not finished
The platform is under active development and we would rather say so than let you find out during a pilot. The database and desktop capabilities are newer than the web and Excel ones. The Orchestrator is a local service, not a hosted control plane. There is no multi-tenant cloud. Where a page describes something that is not built yet, it says so on that page.