In 1986, IBM released EHLLAPI for the 3270 PC. It let programs send keystrokes to a terminal emulator and read characters off the screen. The practice was called screen scraping, and it existed because mainframe applications had no APIs. If you wanted to automate something, you automated what the human saw.
A practitioner who built one of these tools in the late 1980s described it plainly:
"Sent commands to the mainframe and received responses back via the PC 3270 terminal emulator," pretending to be an interactive user. He called it a "PC robot."
The assumption was that this was temporary. Proper interfaces would arrive. Applications would expose their functionality through structured protocols, and the fragile business of reading screens and parsing text would become unnecessary. That was forty years ago. IBM stopped manufacturing 3270 terminals long ago, but the protocol remains active in banking, claims processing, and government systems. Some of those systems now have web interfaces built by screen-scraping the old green screens.
The pattern keeps repeating. In network engineering, equipment vendors added JSON and XML output to their command-line interfaces, which should have eliminated text parsing. But as one network automation resource documented in 2025, vendors often added structured output as an afterthought. It was faster to sprinkle printf statements throughout the code than to build proper data models, so numerous commands still can't produce anything but human-readable text. Engineers still write regular expressions to extract data from output designed for readability, not machines. In healthcare, the HL7 v2 messaging standard has been the backbone of clinical data exchange since 1989. Its modern successor, FHIR, introduced RESTful APIs starting in 2014. Over a decade later, hospitals that adopted FHIR APIs still struggle with seamless data exchange because the standard exists but consistent implementation doesn't. The APIs arrived, and the gap persisted anyway.
The financial services version is the most instructive because it's the most contested. Companies built entire businesses on screen scraping bank websites, logging in as the customer and reading account data off the page. When open banking APIs began arriving, the expectation was that scraping would end. Plaid estimates that more than 60% of its traffic now runs through APIs. The rest still uses screen scraping wherever it lacks a data-sharing agreement. The Financial Technology Association prefers the term "permissioned login" to what it calls the "potentially derogatory" label of screen scraping. The terminological softening is itself a signal: the workaround has become infrastructure worth defending.
Every generation follows the same arc. Structured interfaces are incomplete, so automation falls back to parsing whatever the human sees. The fallback is declared temporary. It becomes load-bearing. Eventually it gets a better name.
Browser agents are the latest iteration. WebDriver became their substrate because it was the most mature, most thoroughly standardized version of the same workaround that EHLLAPI performed in 1986: letting software pretend to be a person interacting with an interface built for people. Testing infrastructure became agent infrastructure because testing had already solved, at production scale, the problem of making that pretense reliable.
The surface area of what users can do through an interface always exceeds what any structured protocol anticipates. That gap is why the cycle keeps repeating. Every previous generation believed it was temporary. Whether the current one builds differently remains an open question, but the pattern suggests that the gap between what APIs expose and what users can do has never fully closed. There's no particular reason to expect this time is different.