Automation

What an automation is

A tree of steps, run top to bottom against one profile. The steps that touch the page run inside that profile's own browser session — its proxy, its cookies, the fingerprint you built — so a site sees the identity rather than an automation harness bolted to it.

Steps are built in the launcher on a canvas — each step a card, branches drawn as lanes, loops as groups you drop steps into — or handed over the API as JSON. Same tree either way: the canvas is only where the program is drawn, and execution order never follows where a card was dragged.

Either way the tree is validated before anything is stored, and a rejection names the exact path that failed rather than saying the shape is wrong.

An automation can also be pinned, from its editor, to every profile's browser start page — a tile next to the bookmarks, so it can be run from inside the browser.

The 22 step types

Every field below is read from the schema Argus itself serves, so this is the vocabulary an agent gets when it calls argus_automation_schema.

What every step carries

Six fields belong to every step regardless of type, which is why they are not repeated 22 times above.

id

Required, and unique across the automation — the run log addresses steps by it, so never reuse one.

label

Your own name for the step, shown instead of the generated summary.

enabled

Off skips the step without deleting it.

timeoutMs

How long this one step may take.

onError

stop, continue or retry.

retries

How many times to retry. Capped at 5.

Variables and conditions

Any field marked as interpolated substitutes templates before the step runs: {{vars.name}} for something an earlier step stored, {{profile.email}} and {{profile.password}} for the profile's own saved credentials, and {{loop.item}} inside a loop.

One field is deliberately excluded. A Run script step never interpolates its script — templates are not substituted into code, so a value that happens to contain a quote cannot rewrite what runs.

Conditions are not an expression language, on purpose. One interpolated left side, one of five comparators, and one literal right side — enough to branch on what a page says, and too little to become a language nobody can read six months later.

Parameters

An automation can declare parameters — the inputs it asks for before it runs. A workflow that searches Dortmund and one that searches Essen should be one automation with a city parameter, not two copies of twelve steps.

Every parameter is readable from any interpolated field as a variable. A value can come from three layers — the automation's own default, under the profile's saved value, under whatever the run dialog or an agent supplies for that run — and the most specific one wins.

Secret parameters are masked in the interface and redacted out of the run record. List parameters become real arrays, so one can feed a loop's items directly.

Schedules

An automation can carry a schedule: every N minutes (5 to 1440), daily at a wall-clock time, or weekly on the days you pick — against a list of profiles it runs on. No cron strings; the modal, the card badge and an agent authoring over MCP all read and write the same small shape.

The schedule fires while the launcher is running. It is part of the automation itself, so creating or changing it over the API is the same create and update call.

Runs and notifications

Every run is recorded: which profile, which steps ran, per-step timing, and the verdict — succeeded, finished with errors, failed, or cancelled. A partial run did every step it could and tells you which one it could not, which is a different thing from a failure.

Starting a run returns as soon as it is registered; it continues in the background and lands in the history, which an agent reads back with the runs tool.

When a run finishes — at three in the morning, on a schedule, or started by an agent — Argus can send the verdict to Telegram: what ran, on which profile, and whether it succeeded. One bot serves the whole workspace, but every message is personal: you link your own chat once, then subscribe per automation to every run or failures only. Your subscriptions never ring a teammate's phone.

Automations can also notify through any messaging connector when they finish, separately from the notify step — a run that fails halfway still tells someone, even though the step that would have said so never ran.

Authoring over the API

Automations can be written by hand in the launcher or created over the local API — which is what a coding agent does. Ask for the step vocabulary first; the field names are not guessable, and a tree that does not validate is refused.

{
  "name": "Sign in",
  "steps": [
    { "id": "s1", "type": "goto", "url": "https://example.com" },
    { "id": "s2", "type": "waitFor", "for": "selector", "selector": "h1" },
    { "id": "s3", "type": "extract", "selector": "h1", "what": "text", "into": "heading" }
  ]
}

Creating, changing and deleting an automation needs a key with no folder scope, because automations are shared across every folder and have none of their own. A folder-scoped key may still list, read and run them.

Parameters and schedules ride the same calls — parameters and schedule are fields of create and update, validated exactly the way the editor validates them. Running one returns as soon as the run is registered — it continues in the background, lands in the run history, and a notify step or a Telegram subscription is how it reaches you when it is done.