How to add AI agents to Infor XA on IBM i
Short answer
Add AI agents to Infor XA by putting a narrow tool layer between the agent and the IBM i: read-only SQL views over Db2 for i for lookups, and calls to existing XA programs or a staging table for any write. A human approves every write. The model can run on your own GPUs next to the IBM i, so nothing leaves the building.
Infor XA (the successor line to BPCS and related products) is still the system of record for a large number of discrete manufacturers who never moved off the IBM i. The business logic sits in RPG and CL programs, the data sits in Db2 for i, and the people who understand both are few and busy. That is exactly the environment where an agent that can read exceptions and prepare the next action is attractive, and also where a careless agent can do real damage.
An agent here is not a chatbot. It is a loop: observe something in the ERP (a late purchase order, an MRP action message, a shop order short of material), reason about it using data it fetched through defined tools, and propose an action. The value for an XA shop is mostly in the planner and buyer workload: hundreds of action messages every MRP run, most of which are noise, a few of which matter.
The honest constraint is that XA has no modern public REST API for every transaction. Which integration path you have depends on your release, whether you run Infor ION, and how much custom RPG you own. This page walks through the realistic surface and the safe pattern, so you can judge the effort before talking to anyone.
What teams use it for
Triage MRP action messages
After each MRP regeneration the agent reads action messages, groups them by item family and supplier, drops the ones that net out within lead time, and hands the planner a ranked short list with the reason for each.
Expedite late purchase orders
The agent finds open PO lines past promise date that feed a short shop order, pulls supplier contact and past delivery performance, and drafts the chase email for the buyer to approve.
Shop order shortage watch
For released shop orders starting in the next few days, compare component allocation to on-hand and open receipts, and flag orders that will stall with the specific missing component and its inbound date.
Draft non-conformance records
From a receiving inspection note or a floor message, the agent drafts the NCR text, attaches the lot and supplier details it looked up, and leaves it as a draft for quality to confirm.
Customer order promise checks
When a large customer order line lands, the agent checks capacity, material and routing, and suggests a realistic promise date plus the assumptions behind it, for the order desk to accept.
Month-end exception sweep
Negative inventory, orphan shop orders, receipts without invoices and cost roll anomalies are found by a scheduled agent that writes a summary a controller can clear in an hour.
Infor XA (on IBM i) integration surface
- Db2 for i is directly queryable over JDBC (the open-source jt400 driver) or ODBC through IBM i Access. Read-only access is the safe starting point. File and library names depend on your XA release and naming; BPCS-lineage installations use short three-letter file names for items, orders and purchasing, so expect to map them once with someone who knows your install.
- The IBM i Db2 services in the QSYS2 schema (for example system status and active job views) let an agent monitor the machine as well as the data, useful for batch run health before it trusts what it reads.
- IBM i Integrated Web Services (IWS) can expose an RPG program or a service program as a REST or SOAP endpoint without rewriting it. This is the cleanest way to give an agent a controlled write: it calls the same program a user screen would, with the same validation.
- Data queues (DTAQ) and journaling (the Db2 journal and its receivers) give you a way to react to changes. An agent can wake on a new row or a queue entry rather than polling tables all day.
- If your site runs Infor ION, business documents and ION APIs may be available for some XA transactions. Availability and document coverage vary by version, so confirm with your Infor contact before planning around it.
- Spooled files hold many classic XA reports. A job can write them to a stream file or PDF so the agent can read an MRP or exception report that has no table-level equivalent.
How it works
- 1
Pick two or three agent jobs, not twenty
Start with one read-heavy job, such as PO expedite or MRP triage. The tool list for each job is short and testable. Sprawling agents fail because nobody can say what they are allowed to do.
- 2
Create read-only SQL views for the tools
Define views in a dedicated library over the real files: open PO lines with promise dates, shop order components with allocation, item availability. The agent never sees raw production files, only these views, and a dedicated read-only user profile owns the connection.
- 3
Build the tool layer as a small service
A service on a Linux or Windows host next to the IBM i exposes functions such as get_open_po_lines or get_shortages over the views. Each function has typed inputs, a row limit and logging. The agent only ever calls these functions.
- 4
Route every write to a proposal table
Instead of updating XA files, the agent inserts a proposed action (new promise date, reschedule, draft email) into a staging table with the evidence attached. A person approves it in a simple screen, and only then does an existing XA program or IWS endpoint apply it.
- 5
Serve an open-weight model locally
Run a tool-calling capable model on vLLM or Ollama on a GPU server in the same network. Item numbers, supplier names and costs then never leave your site.
- 6
Run in shadow mode before it matters
For two to four weeks the agent makes proposals nobody acts on. Compare them to what planners actually did, tune the prompts and views, and only then let approved proposals flow into XA.
Example flows
Late PO chase before a shop order starves
Trigger: Nightly job after MRP finishes
- Agent calls get_late_po_lines for lines more than two days past promise.
- For each, it calls get_dependent_shop_orders to see which released orders need the part.
- It ranks by earliest starve date and fetches the supplier's last six receipts for typical lateness.
- It writes an email draft and a proposed new need date into the staging table.
- The buyer opens the approval screen, edits, and sends.
Result: The buyer starts the day with five lines that matter instead of scrolling a list of eighty.
Weekly reschedule suggestions
Trigger: Monday morning schedule
- Agent reads action messages for reschedule-in and reschedule-out.
- It filters out moves smaller than the item's planning fence or inside the frozen window.
- For the rest it checks whether the move releases cash or prevents a stockout.
- It posts the grouped list to the planner's queue with one-line reasons.
Result: Planners accept or reject in bulk, and accepted moves are applied through the normal XA maintenance program.
Keeping data on-prem
Most Infor XA customers run it on-prem on Power hardware, and the natural architecture mirrors that. Keep Db2 for i where it is, put a small integration host and a GPU server in the same network segment, and let the IBM i accept connections only from the integration host. The model, the vector store for any document retrieval, and the agent logs all stay inside. Because the IBM i is often scheduled around batch windows, run heavier agent queries against a replicated copy (Db2 Mirror, a journal-based replica, or a nightly extract) if daytime interactive response matters. Air-gapped plants can run the entire stack disconnected, updating model files by approved media.
Security checklist
- Use a dedicated IBM i user profile with object authority limited to the agent views, never QSECOFR or a human's profile.
- Keep the agent read-only at the database level; writes only through a staging table and an approved XA program call.
- Log every tool call, its inputs and the rows returned, and keep the log outside the IBM i so it cannot be altered from the same account.
- Mask or exclude cost and margin columns from views the agent does not need, so a prompt cannot surface them.
- Treat text from supplier emails or notes as untrusted input; the tool layer, not the model, enforces what can be changed.
Ways to get it done
Build in-house on jt400 and a tool-calling framework
Effort: A focused pilot is typically a few weeks; hardening and approval screens take longer.
You have a developer who knows both IBM i SQL and Python or Java, and a clear first use case.
Use Infor's own AI and automation where it covers the job
Effort: Low effort to try, but coverage of older on-prem XA releases is often limited.
Your release and Infor cloud footprint include the capability and your data can leave the site.
Work with a partner such as Netray
Effort: Scoped as a pilot on one workflow, with XA domain input from your own team or an XA partner.
You want private, on-prem agents over XA without taking on the model serving and guardrail work yourselves.
Pitfalls
- !Pointing the agent at raw files with cryptic field names. It will guess wrong; give it views with plain column names and descriptions.
- !Letting the agent call update programs directly. One bad prompt injection from a supplier note becomes a real transaction.
- !Ignoring unit of measure, lot size and planning fence rules that live in RPG, not in the tables. Check that views reproduce what the screens show.
- !Running heavy queries during the nightly batch or MRP window and slowing the machine for everyone.
- !Measuring the agent on how impressive the output looks rather than on how often planners accept its proposals.
Frequently asked questions
Do I need Infor ION to add AI agents to XA?
No. Many XA sites use direct Db2 for i access for reads and IBM i web services or existing programs for writes. ION can help if you already run it and your release exposes the transactions you need, but it is not a prerequisite. Check coverage for your version first.
Can an agent safely write back to Infor XA?
Yes, if writes pass through a staging table and a human approval, then execute via the same program a user screen would call. That keeps XA validation in force. Direct file updates by an agent bypass business rules and should be avoided.
Which model should I use on-prem?
An open-weight model with solid tool-calling, in the Qwen, Llama, Mistral or gpt-oss class, served by vLLM or Ollama. Size depends on your GPU. Evaluate on your own exception data rather than public benchmarks, because ERP vocabulary is unusual.
Will agents slow down my IBM i?
They can if they run large unindexed queries. Use views with proper indexes, row limits and off-peak scheduling, or point the agent at a replica or nightly extract. Monitor active jobs through the QSYS2 services during the pilot.
Is this better than just using MRP reports?
For small item counts, standard reports are enough. Agents pay off when action messages number in the hundreds and a planner spends hours deciding which matter. If your volume is low, fix the report filters first and skip the agent.
Want AI agents working on your Infor XA (on IBM i)?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment