Decisions, Decisions: Agentic Mainframe Process Automation

Can a small AI model navigate an IBM mainframe? An experiment with TypeSafe AI's Jev, Claude Haiku and a different approach to process automation.

Process Automation Decisions

Like many of you, I'm fascinated with System One models.

My first introduction was through TypeSafe AI's Jev.

Much of my work over the past three years has been in agentic process automation, and LLMs have either felt like an all-powerful oracle predicting every next move or a toddler throwing a tantrum when it didn't get what it wanted.

The agent harnesses built around these LLMs were often a great fit for controlling (mitigating?) the toddler, but they also came up short in very specific scenarios involving judgment and decisions.

If you've spent any amount of time in process automation, you know that judgment and decisions are the most valuable part of the automation.

Of course you can address the happy path. That's why it's happy!

But logic branching, routing, scoring, ranking, question answering, escalations, etc. are the hard parts.

LLMs often felt slow, clunky and misused in these applications. But because they were the intelligence available to us, we spent hours tinkering with and adapting the harnesses.

It always felt a little off, but I found it difficult to explain why.

It wasn't until I started using Jev that I could better frame the problem.

I won't go into all my thoughts on that here, but here's a video TextLayer shared from some of our research lab experiments with Jev.

We made more than 100,000 Jev requests for under $10.

Navigation Decisions

A great use of this technology is navigation judgments and decisions, or next-best-action recommendations.

My first use of Jev was with document processing, extracting, scoring and structuring data from unstructured documents, then routing low-confidence extractions to an LLM responsible for closing the confidence gap.

But it wasn't until I saw decision models being used to perform browser automation at breakneck speed that I was truly amazed at what this could mean for navigation technologies, not just routing technologies.

Here's an example:

Browser-use: Jev ultrafast navigation

But there are so many other navigation technologies outside the browser.

Have you ever watched humans navigate a mainframe?

It's wild.

And painful to watch.

And makes you itch for a better way.

So I had a hypothesis.

If Jev can automate browser navigation, why can't Jev automate mainframe navigation?

Mainframe Decisions

Spoiler alert: the answer, of course, is yes.

A System One model can assist with mainframe navigation.

I built a demo to test whether a small AI decision model could navigate an IBM mainframe using natural-language instructions.

The demo converts plain-English (well, business-language) intent about a business process into actions on an IBM mainframe, live, on a TK5 system running MVS.

You type a question such as:

"Which branches are holding too much vault cash?"

Ordinary code drives the terminal, while Jev decides which screens to read and pulls the values off them.

Claude Haiku steps in only where Jev isn't confident, and then writes the answer.

Every step is on screen as it happens: the screens read, the choices made, where each value came from, and the time and cost of each call.

The point is to show that a mainframe's green screens can be queried in natural language, cheaply and transparently.

Watch the Demo

Now imagine this harness, which only needs to be built once on top of a mainframe, replacing the brittle RPA scripts that do this today.

If the intent behind existing navigation technologies could be translated into natural language, a System One model on a mainframe could become the means by which both humans and other machines interact with mainframe data.

Both reads and writes.

That's where this gets interesting.

Some Potential Benefits

There are three potential benefits I see with this approach.

1. New workflows without new code

Each new RPA workflow typically requires building and maintaining a script.

With this technology, you could define your intent in the natural language of the business instead.

The harness handles the navigation decisions, rather than requiring every workflow to have its own predefined sequence of steps.

Of course, you still have to build and maintain the harness. But that's a different maintenance problem than managing a collection of individual scripts.

2. Screens that change

If screens or layouts change (infrequently for mainframes, I concede), RPA workflows need to go through the typical software development lifecycle to account for those changes.

With this approach, the position or location of data was never encoded into the individual workflow in the first place.

And new screens are simply a new entry in the harness's operation manual.

There's still work involved, but you aren't necessarily rebuilding the navigation logic every time.

3. Transparency

Every answer shows which screens were read and where each value came from.

The ability to programmatically capture navigation decisions, screens read, data positions, etc. at the time of capture is invaluable for audit and compliance.

Being able to see what the system did, rather than just receiving its final answer, is particularly interesting in environments where evidence matters.

So, Is This Better Than Traditional RPA?

Well, it depends.

A script is better when the screens and questions are fixed, and you'd rather maintain static scripts than maintain a dynamic harness.

But a harness based on a System One model and an LLM or SLM may be more appropriate when you want a single harness adaptable to multiple mainframes, faster development of new workflows, and an appetite to maintain the harness rather than maintain the scripts.

That's the realistic pitch.

The experiment shows that a System One model can assist with mainframe navigation. It doesn't tell us that every existing RPA workflow should be replaced.

There are still questions worth exploring, particularly around reliability, maintaining the harness and how the approach behaves across different workflows.

But if we're already seeing these models navigate browsers at remarkable speeds, it's worth asking where else they could be useful.

Mainframes turned out to be a pretty interesting place to start.

Appendix: Screenshots

Here are some screenshots of the other pieces of data that were captured in the demo but not explicitly shown in the recordings:

Screenshot: Jev's choice of screen(s) + confidence

Screenshot: Jev's choice of fields & rows

Screenshot: Extracted data, Jev + Haiku fallback

Screenshot: audit + evidence

SBOM

SBOM: Mainframe Environment

SBOM: Terminal Access

SBOM: Application Code

Appendix: Technical Details

For anyone interested in what's running behind the scenes, here's the software bill of materials from the experiment.

Mainframe Environment

Terminal Access

Application Code

Related Resources

• TypeSafe AI

• Jev ultrafast browser navigation

• Original article on LinkedIn

TextLayer Labs is a place for our team to share experiments, technical explorations and ideas they're working through. Articles reflect the author's own perspectives and findings, not necessarily established TextLayer practices or positions.

Originally published by Gareth Sharpe on LinkedIn on October 26, 2026. Adapted for TextLayer Labs.