Somewhere in most companies over a certain age, there's a green screen. A terminal connected to a system older than a lot of the people using it. It runs orders, or claims, or billing, and the business can't function without it. It has no API. Since the 1980s, the only way in has been a person who knows which keys to press.

A retailer we work with has one of these. A 1980s Pick-style mainframe, reachable only over SSH, that every order passes through on the way to a delivery truck. Their auditors review orders before delivery to catch the things that would otherwise ride the truck to someone's home: a missing part, a status that doesn't match, a note saying the order changed after the pick ticket printed. They're good at it. There just aren't enough of them. Coverage is about a quarter of daily order volume, concentrated on appliances, the highest-risk category: roughly 700 of about 2,600 delivery orders a day. The other 1,900 ship unexamined.

For decades, a company in this position has had two choices. Replace the system, or live with the risk. Both are bad. Gartner now predicts more than 70 percent of mainframe exit projects started in 2026 will fail to deliver what they promised, mostly from overestimating what AI-driven migration tooling can do, and the business has to keep running the whole time. Doing nothing means the handful of people who know the system keep getting closer to retirement, and most of what they know has never been written down.

There is a third choice now. Put the AI agent at the keyboard the system already has. The mainframe stays where it is, doing what it has always done. Nothing about it changes. The only thing that changes is who's typing.

‍

When we proposed this, the client's reaction was excitement and caution in about equal measure. The caution came in three parts.

They were already using RPA on another workflow, scraping the screens and writing back, and it was fragile in a specific way. Forty years of business logic lives behind those screens, and the same screen can behave differently depending on how you got there. Their IT lead put it plainly during our first week on site: "there is so much business logic behind those screens. Every time it behaves differently." His caution was fair. Don't assume you know this system. A script that plays back keystrokes doesn't know it either. It handles the happy path and breaks on everything else, and on this system the judgment is the job.

They were worried about security, and about the model seeing what it shouldn't. The model runs inside their own Azure tenant, and the screens never leave their network.

And the biggest one: this system is the business. Who lets an AI agent into something with that much access and control? Nobody had put this option in front of them before, so there was no precedent to lean on. Months later, their IT lead described the decision this way: "When we kicked it off… there were a lot of questions on why we are doing this. I think we justified that there is enough ROI and we moved forward." He also said the ROI still needs to be quantified more rigorously, and I'd rather include that than pretend otherwise.

That last concern is the right one, and it shaped how we built it. The agent can't type. It can only call one of a handful of defined tools: press a key, fill a field, submit, back out, read the screen. Each tool does exactly one thing. There's no way to express an action outside that list. The model handles the judgment in the middle. Deterministic code handles the parts that don't need judgment, like paging through every order in a manifest. And every write goes through an approval gate the client controls. They can set it to fully autonomous where the work is well-defined, or to a human confirming before anything gets committed. Switching between the two is a configuration setting.

We took it in stages, and I'd do it the same way again.

First we sat with the operators and wrote down every screen, every keystroke, and every rule you only learn by breaking it. Forty-six actions across sixteen phases. None of them had ever been documented. Some the operators had never put into words, because nobody had asked. One example: an order might be a simple drop-off or a full-service delivery with in-home setup, which changes the whole checklist later, and the screens look identical either way. The operators just knew.

Then we ran the agent in a sandbox and had the senior auditors watch it. We didn't ask for an accuracy scorecard. The bar was recognition. Does it navigate the way you would? They said yes. On a system with no undo, that's the question that matters first, and it's a lot cheaper than precisely measuring the wrong thing.

The first piece of this work, an exception engine that flags risky orders before the auditors see them, has been in production since summer. The operations leader who owns the audit team told us what she was hearing from her people a week in: "the sentiment that I've gotten from our stakeholders are all positive… having to view so many less… and just really focusing on the exceptions has been very positive for them." That's the outcome we're after. Fewer orders to look at, and the right ones.

The terminal agent is the second piece, and it's the one that changes the ceiling. In the sandbox it completed the full audit workflow end to end, fully autonomous, through the same screens the auditors use: every page, every product line, the complete note history. It wrote the audit comment for each order and committed it back. The mainframe hasn't changed a line of code. It was built to walk every order, not a sample. Deployed across the full manifest, that's 2,600 orders a day audited instead of 700, and the 1,900 that ship unexamined today would not. How far and how fast to roll it out is now the client's decision.

The obvious read is that this lets you defer the migration. It does. The client has modern intelligence working on their oldest, riskiest system years before any migration could have delivered the same result, and they didn't have to bet the business to get it.

The less obvious thing is what the work left behind.

The 46-action map is now a versioned document. It trains the next hire whether or not an agent ever touches the system again. And everything the agent reads comes out the other side as structured records: orders, line items, statuses, notes, all as clean JSON. Data that only existed as characters on a green screen is now queryable.

Their IT lead saw this before we did. When we were deciding where the agent's output should land, he said: "we build a history, we learn from it, right? It's not only just handling day-to-day, but the idea is if we can group it, understand it, learn from it, get better."

Anyone who has scoped a mainframe migration knows those two artifacts are exactly what the migration needs and never has. Nobody funds "go write down what the veterans know" as a standalone effort. It happened here as a side effect of getting the agent to work.

I want to be careful with that claim. We haven't fed those assets into a migration for this client. What I can say is that if they ever start one, they'll start with a map of the workflow and a structured dataset of what runs through it. That's a very different starting line.

The pattern holds anywhere a valuable workflow sits behind a terminal and inside an expert's head. Claims review in insurance. Billing reconciliation in logistics. Account maintenance in banking. Inventory research in distribution. If a trained person can do the work through a green screen, an agent can be built to do it, and the people who do it today can judge whether it's doing it right.

The first step is small. Pick the one workflow you already know is the problem, the valuable one that depends on three people. Map it with them. Prove the agent can drive, and let them be the judges.

Jordan Gurrieri is Co-founder and CEO of BlueLabel, an AI strategy and delivery firm that builds production AI systems for mid-market and enterprise companies. He started his career at Microsoft in business process automation and has spent the last 15 years building software for organizations that can't afford to break what already works.

‍