Automation you can watch

Every agent demo looks the same: a browser fills a form by itself, the audience claps, the video ends. Nobody shows the part where the portal asks an unexpected question at step seven of nine, or logs the session out during a document upload, or sits on the application for four days before anything happens. Government portals are made of those parts. If your automation story doesn't have an answer for them, you have a demo, not a system.

We automate visa submissions on embassy and e-visa portals, which is roughly the most hostile environment you can pick for browser automation. There are no APIs. Forms are conditional and multi-step. Sessions time out. One-time passcodes arrive by email. Fees get paid by card on government payment gateways. And the cost of a wrong submission is not an exception in a log; it can be a rejection on someone's immigration record.

That environment forced a set of design rules on us. In hindsight they are the product.

Rule 1: The run must be watchable

Every automation run exposes a live view of the actual browser session. An operator can open it at any moment and see exactly what the system sees, as it happens. Not a progress bar, not a status enum: the real page, live.

This started as a debugging tool and became a trust feature. Operators don't extend trust to a black box that returns "submitted" forty minutes later, and they shouldn't. They extend it to a colleague whose screen they can look over. The live view makes the automation that colleague. Alongside it, every run writes a step-by-step log: pages visited, actions taken, what was captured and where. Replayable months later, when a client or an audit asks what happened.

Rule 2: Pausing is a feature, not a failure

The system knows the difference between work it should do and decisions it should not make alone. When it hits one of those moments, an upload the portal rejects, a question the case data doesn't answer, an ambiguous choice with consequences, it does something most automation refuses to do: it stops.

A pause is not an error state. The run packages up the situation: a screenshot of the page, an explanation of what it found, the options it sees, and a recommendation. That lands in the operator's queue. The operator answers, and the run resumes exactly where it stopped, with the answer recorded on the case like every other event.

My favorite small example of this philosophy is the OTP path. Portals love sending one-time passcodes by email. Naive automation stalls there and waits for a human to go check an inbox. In our system, the inbound email is classified, the code is extracted, and it is delivered to the browser session standing at the form, in seconds, without a person in the loop. We put humans where judgment is needed and pulled them out of everywhere else. Copying six digits from an inbox is not judgment.

Rule 3: Nothing is accepted blind

The most dangerous moment in visa automation is not filling the form. It is the moment the system decides it's done. An approval letter downloaded from a portal might be the wrong document, the wrong traveler, or a receipt that merely looks like a visa.

So nothing the automation captures is trusted by default. A downloaded visa or approval enters the case as a candidate, with its provenance recorded: which step captured it, from which page, at what time. It must be verified before the case is allowed to close. The same skepticism applies upstream: payments run on controlled single-use cards, one per case, so every government fee is traceable to exactly one application and capped by design.

Rule 4: Progress must survive death

A real visa application is not a session; it's a saga. Submit on Monday, payment confirmation Tuesday, a status check Thursday, a document download the following week. In between, sessions expire, portals go down for maintenance, and infrastructure does what infrastructure does.

Runs are checkpointed accordingly. The system records what it has accomplished, the facts it has learned along the way (application numbers, portal accounts, reference codes), and the milestones it has passed. If a server dies mid-run, the work doesn't. The run resumes from its history rather than starting over. And it can schedule its own future: "check this portal again in 48 hours" is a first-class operation, not a sticky note on a processor's monitor.

Playbooks, because portals change

Classic RPA dies by selector. Somebody re-renders a button, and a thousand scripted workflows break at 3am. We don't script portals; we describe them. Each supported portal gets a playbook: how the application flows, what each step expects, what a good outcome looks like, how to recover when a session dies. The automation reads the actual page and follows the playbook the way a trained processor follows a procedure. Cosmetic changes don't break it, and when a portal genuinely restructures, the playbook is updated once, centrally, for every customer at the same time.

What this costs us

These rules make our automation slower than full autonomy on a good day. A system that never pauses, never verifies, and never waits for a human will finish first, right up until the day it confidently submits something wrong on a government system, where there is no undo button.

We also don't claim coverage we don't have. Automation rolls out portal by portal, starting where it has proven reliable, with manual workflows as the fallback for everything else. Operators choose how far to turn the dial. That is a less exciting sentence than "we automate everything", and it is the sentence that happens to be true.

The bet underneath all of this is simple: in high-stakes domains, the winning automation is not the most autonomous one. It is the most accountable one. Watchable, interruptible, verifiable, recoverable. Build those four properties first, and the autonomy you add on top of them is worth something.