Many of the world’s most important business processes still run on IBM i systems, often known by their older name: AS/400. These systems are reliable, deeply embedded, and business-critical. They also tend to be hard to automate with modern agentic workflows because their primary interface is still the 5250 green screen.

Reindeer now bridges that gap.

We’ve added support for headless TN5250 automation, allowing agents to connect to IBM i hosts, read true 5250 screen structure, fill fields, press function keys, and drive legacy green-screen applications without brittle screen scraping or terminal emulation hacks.

Why This Matters

Most automation tools are built for APIs, databases, web apps, or file drops. But many enterprise workflows still depend on interactive green-screen applications: customer maintenance, order entry, inventory updates, claims processing, pricing screens, finance operations, and internal approvals.

Historically, automating these systems meant one of three things:

• Teach a person to do the work manually.
• Build custom integrations against host-side programs or database tables.
• Use fragile screen scraping tied to visual text positions.

Reindeer’s AS/400 automation takes a different approach. It speaks the 5250 protocol directly.

That means the agent sees the screen as structured data: fields, positions, lengths, labels, protected states, hidden fields, cursor position, and screen text. It can act like a trained operator, but with a machine-readable model of what is actually happening.

Why This Is Different From “Computer Use” Agents

Computer-use agents operate by looking at pixels and controlling a mouse and keyboard. That works well for many browser and desktop workflows, but it treats every application as a visual surface. The agent has to infer structure from what it sees. This is both difficult and expensive.

Reindeer’s AS/400 automation is different because it speaks the 5250 protocol directly.

Instead of seeing a screenshot of a green screen, the agent receives the actual screen model: fields, labels, row and column positions, field lengths, protected status, hidden/password attributes, cursor location, and modified-field state. It can tell which fields are editable because the host says they are editable, not because a vision model guessed correctly.

That gives us several advantages:

• Protocol-level structure: The agent works with real 5250 fields, not pixels or OCR text.
• Lower brittleness: Screen changes that preserve field structure are easier to handle than visual layout changes in screenshots.
• Safer input: The client can avoid writing into protected fields and can submit modified fields the way a real terminal would.
• No UI focus problems: There is no mouse cursor, window focus, clipboard, browser tab, or desktop state to lose.
• Hidden-field awareness: Password fields are recognized as hidden 5250 fields and redacted from output.
• Headless execution: The workflow can run in a backend sandbox without a graphical desktop.
• Human visibility when needed: The browser viewer is just an observer of the protocol session, not the automation substrate.

Computer use asks: “What does the screen look like, and where should I click?”

Reindeer’s AS/400 skill asks: “What did the host define as the current 5250 screen, which fields can I modify, and which AID key should I send?”

For legacy green-screen systems, that distinction matters. We are not automating around the terminal; we are automating through the same protocol the terminal uses.

What Reindeer Can Do Now

The new AS/400 skill lets an agent:

• Open a TN5250 session to an IBM i host.
• Authenticate through a standard sign-on screen using connection-profile credentials.
• Read the current green screen as JSON.
• Identify input fields by index, label, or row/column.
• Fill field values safely.
• Submit AID keys such as Enter, PF keys, Roll Up, Roll Down, Help, Clear, and Print.
• Maintain a live session across multiple tool calls.
• Expose a read-only browser viewer so a human can watch the same green-screen flow during demos or supervised runs.

This is not a terminal renderer. The goal is not to make a prettier green screen. The goal is to let agents operate existing IBM i applications programmatically while preserving the real workflow and host behavior.

Built for Real Green-Screen Workflows

The skill uses a three-part architecture.

First, it handles TN5250 transport: TCP or TLS, telnet negotiation, terminal type, device naming, CCSID selection, and 5250 record boundaries.

Second, it parses the 5250 data stream into a display model. Instead of giving the agent a blob of terminal text, Reindeer exposes fields with metadata: whether a field is protected, hidden, numeric, high intensity, modified, and where it lives on the screen.

Third, it builds outbound input records the way an actual 5250 terminal would: field changes plus an AID key.

This allows an agent to do things like:

as400 connect

as400 login --session "$sid"

as400 fill --session "$sid" --json '[{"field":"Selection","value":"1"}]' --aid ENTER

as400 screen --session "$sid"

Credentials and connection details are supplied through the platform’s connection-profile environment contract, including host, port, TLS mode, device name, terminal type, CCSID, username, and password.

Human-Visible Agent Operations

A key part of this work is the viewer.

In many AS/400 workflows, trust matters. Operators and stakeholders often want to see what the agent is doing, especially during rollout. Reindeer’s viewer mirrors the live daemon-held session in a browser, so a user can watch the agent navigate menus, filter records, open detail screens, and submit changes.

This makes demos much more natural: the human sees the green screen, while the agent drives the same session through structured commands.

Example: Customer Management on IBM i

In testing, we used a real IBM i environment and a customer master green-screen application. The agent was able to:

• Sign on to the IBM i host.
• Open the customer management application.
• Filter customers by state.
• Locate Iowa customers.
• Open a customer detail screen.
• Extract structured customer details.
• Create a demo customer through the green-screen add flow.
• Verify the record.

The important point is that the agent did this through the green screen itself. It did not bypass the app with direct database access. That means the workflow respects the same validation, prompts, function keys, and host behavior a human operator would encounter.

Why This Is Different From Screen Scraping

Traditional screen scraping often depends on plain text at fixed coordinates. That breaks easily when layouts shift, fields are hidden, or the host uses protected fields and subfiles.

Reindeer’s AS/400 automation uses the 5250 protocol model directly. The agent gets the field structure, not just the rendered text.

That lets it reason about the interface more safely:

• Which fields are editable?
• Which field is hidden?
• Which field was modified?
• Which row has an option input?
• Which AID key should be submitted?
• Did the host return an error message?

For agentic automation, that distinction is huge.

What This Unlocks

This opens the door to agent workflows over legacy systems that previously required custom integrations or human handoffs:

• Customer record lookup and updates.
• Order entry assistance.
• Claims or case inquiry.
• Inventory checks.
• Back-office exception handling.
• Guided operations where a human supervises the viewer.
• Regression tests for green-screen applications.
• Hybrid workflows where agents combine email, documents, APIs, and IBM i screens.

AS/400 systems are not going away. They run important work because they are dependable. Reindeer’s goal is to let modern agents participate in that work without requiring customers to rewrite core systems first.

The Bigger Picture

Enterprise automation cannot stop at modern SaaS APIs. Real businesses run across old and new systems together: email, PDFs, spreadsheets, ERPs, CRMs, internal web apps, and green screens.

With AS/400 support, Reindeer agents can now reach deeper into that operational reality.

The result is not just “automation for legacy systems.” It is a way to let agents operate where the business already runs.