The officer at counter fourteen had a rubber stamp, a ledger, and a memory for faces that no database has yet matched. Thirty years later the stamp survives as a souvenir, the ledger is an audit table, and the memory has been replaced by a dozen automated processes: appointment allocation, document scoring, fee reconciliation, status messages, queue forecasting. Somewhere in that transition every consulate, agency and travel business crossed the same invisible line — from people performing process to people supervising processes that perform. The name the industry is slowly settling on for managing that new reality is AutomationOps, and the state of the field in 2026 is stranger than the vendors’ brochures suggest: the practice is mature, the vocabulary is not, and the incidents keep writing the syllabus.
The Quiet Takeover Nobody Scheduled
No committee ever voted to automate the visa desk. It happened the way it happens everywhere — one spreadsheet macro, one reminder script, one integration at a time, each justified by a busy Tuesday. The result is a layer of machine behaviour sitting between the applicant and the decision, largely undocumented and largely unreviewed. The Ops Atlas, which keeps the most-cited definition on its AutomationOps reference page, describes the needed posture plainly: choose what deserves automating, make its repetitions safe, limit how much damage one bad run can do, and keep a named human answerable until the job is deliberately switched off. That sentence would have sounded abstract a decade ago. Today it reads like a description of Tuesday.
AutomationOps Is a Label With Baggage
Honesty requires a detour through the word itself, because the field’s vocabulary is genuinely contested. Robocorp promoted a methodology under the AutomationOps name and has since archived it; UiPath has sold a product with the same name since its general availability in April 2021; the Atlas uses the term editorially, for governing run-time actions — restarts, clean-ups, failovers, credential rotations, fleet-wide configuration runs — as opposed to infrastructure code, workflow engines, chat-triggered tooling or network change. When two vendors and one reference site use one phrase for three things, confusion is not a possibility but a schedule. Practitioners cope by defining terms in writing at the start of every project, and you should copy that habit: the phrase costs nothing, the ambiguity costs weekends.
The Year the Incident File Became Required Reading
What turned a loose craft into a discipline was not a theory but a run of public failures, each one an automated action meeting an unguarded assumption. In 2012, Knight Capital pushed unreviewed code into production and watched roughly 460 million dollars evaporate within the hour. In 2017, a mistyped input during routine maintenance at AWS S3 took a storage region and a slice of the internet with it. In 2021, Facebook’s backbone collapsed after a faulty audit tool let a faulty change through — the guard itself was sick. In 2022, Atlassian’s pipeline, fed the wrong kind of identifier, erased 883 customer sites in just twenty-three minutes. In 2025, AWS DynamoDB traced an outage to an empty DNS record that no repair job ever picked up. Study these five together and the pattern is almost embarrassingly consistent: small tooling decisions — an unreviewed deploy, a free-typed input, an untested guard — scaled by automation into public events. The field’s response, a grading scheme that runs from read-only work up to a fourth tier for destructive jobs demanding second-person approval, is best understood as a promise that the next list will be shorter.
Bainbridge’s Irony, Running on Schedule
The oldest wisdom here predates every incident above. In 1983, Lisanne Bainbridge published “Ironies of Automation”, arguing that handing a task to machines does not abolish human mistakes — it moves them upstream, into design-time assumptions that nobody re-examines until they fail. A visa system that auto-rejects applications over mismatched names has not eliminated error; it has concentrated it in the moment someone decided what a “mismatch” is. Every hyphenated surname, every transliterated passport, every changed date becomes fresh evidence for her thesis. The discipline inherits her conclusion in two working habits: keep the manual path rehearsed rather than letting it decay into folklore, and treat each automated decision rule as a standing hypothesis awaiting revision, never as furniture. On-call staff, the Atlas adds, should be able to pull any stop switch first and justify it afterwards — trust placed in people, not in the machine’s self-image.
What AutomationOps Looks Like at the Counter
Between the vocabulary and the incident file sits the daily practice, and it is less exotic than the name implies. A desk that governs its automation well has simply agreed on a handful of habits:
- Every job rehearses before it acts, showing what it would do — and empty target lists are refused outright, never read as “everyone”.
- Bulk actions move in small waves with a health check between waves, and a run halts itself once failures cross a number chosen in calmer times.
- One-time actions — a payment, a submission, a cancellation — carry request IDs so a replay fails by design rather than by luck.
- Stop switches exist per job and globally, and get pulled in drills twice a year, because an untested switch is decoration.
- Each job’s registration records its owner, its limits and a review date, so accountability never depends on anyone’s memory.
None of this requires new infrastructure; most of it requires only the willingness to say no when a script asks to run unchecked.
AutomationOps Maturity: Where the Field Stands
Strip away the conference slides and reality looks like a ladder with most of the world on the bottom rungs. The Atlas describes five levels — improvised, shared, guarded, governed, self-correcting — and observes that teams typically stall at the second: scripts shared through Git, no named owners, one credential doing everything. Below that rung lie the home-directory script and the departing engineer’s USB stick; above it lie dry runs, batched rollouts and drilled switches. The tooling to climb is unglamorous and largely free. Configuration runners such as Ansible and Puppet handle repeated state; runbook platforms such as Rundeck and StackStorm wrap jobs in access control and logging; cloud-native options like AWS SSM Automation and Azure Automation bring the same ideas to managed estates; and ShellCheck, ansible-lint and Molecule catch mistakes before execution — Molecule even testing idempotence by default. What separates the rungs is not budget but insistence: the refusal to let a job run unowned for even one quarter.
What to Ask For in the Next Procurement Meeting
Because the field is converging, buyers finally have pointed questions for any vendor or integrator touching their processes:
- Which jobs will carry named owners, and what happens to ownership when that person changes roles?
- When a target list arrives empty, does the job stop and complain, or does it quietly assume “all”?
- Can a run be previewed, batched and stopped by someone holding no administrator rights at all?
- How is the one-time action prevented from firing twice, and can you show me the receipt trail?
- Which of these answers exist as configuration in a repository, and which exist only in a sales deck?
Vendors with answers are describing governance; vendors with brochures are describing hope. The gap between those two replies is where the next incident is currently waiting, and 2026’s lesson is simply that you get to choose which side of the gap your own queue lives on. The stamp is gone. The ledger is a table. What remains in our hands is the care we take with the machines that took over the counter.
