How to add AI agents to JD Edwards World on IBM i
Short answer
Put a small tool layer between the agent and World: read tools over DB2 for i (SQL views on the F-files), and write tools that only stage a proposal for a person to approve and post through World's own programs. The model can run on a GPU box beside the IBM i, so nothing leaves the building.
Most JD Edwards World shops run on a Power server that has been stable for decades. The logic lives in RPG and COBOL, the data sits in DB2 for i files such as the Address Book (F0101), Item Master (F4101), Sales Order Detail (F4211) and Purchase Order Detail (F4311), and the people who know where everything is are few. Agents are attractive here because the work is repetitive and rule-heavy: chasing late purchase orders, reading MRP messages, reconciling receipts.
An agent is not a chatbot with a bigger prompt. It plans a few steps, calls tools, reads the results and decides what to do next. On World the tools are the hard part, because there is no modern REST layer by default. You build one thin and deliberately, and you decide which tools can only read and which can propose a change.
The goal of this page is a realistic path: what to expose, how to keep the agent from posting anything on its own, and how to run it where the IBM i data is allowed to be.
What teams use it for
Late purchase order chaser
Scan open PO lines past the promised date, group by buyer and supplier, draft the follow-up email, and propose a revised promise date for the buyer to accept.
MRP message triage
Read planning messages (expedite, defer, cancel), cross-check against open work orders and on-hand, and rank them so planners start with the ones that stop a line.
Receipt and voucher match investigator
When a voucher will not match a receipt, pull the PO line, receipt and price history and explain the variance in a sentence a clerk can act on.
Customer order status desk
Answer 'where is order 48213' from sales order detail, shipment confirmation and open work orders, without a planner stopping to look it up.
Item master hygiene worker
Find items with missing lead times, zero cost or inconsistent units of measure across branches and queue a correction list for the data owner.
JD Edwards World (IBM i) integration surface
- DB2 for i over ODBC, JDBC (the jt400 driver) or the IBM i Access ODBC driver. This is the practical read path: build SQL views over the F-files in a separate library so the agent never touches raw tables.
- RPG and COBOL programs and CL commands that already post transactions. Write tools should call these, not insert into files, so World's own edits and audit fields run.
- Data queues and user spaces, plus journal receivers if journaling is on, for event-driven triggers when a record changes.
- IBM i Integrated Web Services (IWS) or ILE procedures exposed as REST or SOAP, if your IBM i team already publishes services. Names and availability vary by OS release.
- World's inbound interface (Z-file or EDI-style staging) files, where supported in your release, as a safe landing zone for proposed transactions.
How it works
- 1
Inventory the questions first
List the 20 questions your planners and buyers actually ask. Each one maps to a view or a procedure. That list, not the model, decides the project scope.
- 2
Create a read-only service profile and views
Make a dedicated IBM i user profile with object authority only to a views library. Decode World's Julian dates (the CYYDDD format) and join descriptions inside the views so the agent sees clean columns.
- 3
Wrap views as typed tools
Expose each view as a function with a schema: open_po_lines(supplier, days_late), item_availability(item, branch). Keep result sets small and capped.
- 4
Add propose-only write tools
A write tool inserts a row in a proposals table with who, why and the exact values. It never calls a posting program. A person reviews it.
- 5
Post through World after approval
An approved proposal is posted by a CL or RPG job, or typed through the normal World screen, so edits, security and audit remain World's.
- 6
Log every tool call
Store the prompt, tool, parameters, row count and outcome. This is what lets an auditor and the IBM i team trust it.
Example flows
Monday late-PO sweep
Trigger: A scheduled job at 6am
- Agent calls open_po_lines for lines more than 3 days late for critical items.
- It joins on-hand and open work order demand to see which delays hit a build this week.
- It drafts one email per supplier with the PO and line numbers.
- It writes a proposal row for each suggested new promise date.
Result: Buyers open a ranked queue with drafted emails, approve or edit, and nothing posts until they do.
Voucher variance explainer
Trigger: AP clerk pastes a voucher number
- Agent reads the voucher, the matching PO line and the receipt quantity and cost.
- It checks price history for the item and supplier.
- It states whether the variance is price, quantity or unit of measure.
Result: The clerk gets a one-line cause and the exact lines to correct, and keeps control of the correction.
Keeping data on-prem
A Power server will not run a large model, so put a GPU server on the same network segment and keep it separate from the IBM i. The agent runtime, the tool service and an open-weight model (Llama, Qwen or Mistral class served with vLLM or Ollama) all run there. The tool service connects to DB2 for i over the local network with the service profile, so no prompt, row or log goes to a public API. If the policy is air-gapped, keep the model weights and Python packages on an internal mirror. IBM i itself needs only a user profile and the views library; you do not install the agent on the partition.
Security checklist
- Dedicated IBM i profile with authority limited to the views library; no access to base files or command line.
- Row and column access control (RCAC) in DB2 for i can hide cost or pay fields from the agent profile if the release supports it.
- Write tools only stage proposals; posting needs a named person and happens under that person's World security.
- Journal and audit (QAUDJRN) the service profile so unusual query volume is visible.
- Treat free text in supplier emails or notes as untrusted input to the agent, to limit prompt injection.
Ways to get it done
Build in-house with your IBM i team
Effort: About 6 to 10 weeks for a first read-only agent plus approval queue.
You have IBM i developers who can write SQL views and a Python or Node developer for the agent runtime.
Use Oracle or third-party add-ons
Effort: Days to weeks, depending on the product and your release.
You only need general reporting or alerts, and a rules-based tool is enough. An LLM agent is overkill for fixed rules.
Work with a partner such as Netray
Effort: A scoped pilot over a handful of tools, then widened by use case.
You want the tool layer, a private model and approval workflow built together, with a World expert in the loop.
Pitfalls
- !Pointing the agent at raw F-files. Packed decimals, Julian dates and cryptic column names confuse the model and produce wrong answers. Use views.
- !Letting a write tool insert directly into files. You bypass World's edits and break its audit trail.
- !Missing library lists. Data may live in different libraries per environment or company, so the connection must set the right library list.
- !Unbounded queries against large history files that slow the production partition. Cap rows and run on a replica if you have one.
- !Treating the agent's first draft as truth. Show the SQL and source rows next to every answer.
Frequently asked questions
Can an AI agent write to JD Edwards World directly?
Technically yes, but it should not. Have the agent stage a proposal and let a person approve it, then post through a World program or screen. That keeps World's edits, security and audit intact, and it limits the damage from a wrong or manipulated model output.
Do we need to upgrade World or move to EnterpriseOne first?
No. The agent talks to DB2 for i and to your existing programs, which work on the release you run today. Moving to EnterpriseOne is a separate decision with its own cost, and an agent layer can survive that move if you keep the tool schemas stable.
Which model should run the agent on-prem?
An open-weight model with solid tool-calling, such as a Qwen, Llama or Mistral class model served with vLLM or Ollama. Size depends on the number of concurrent users and how much reasoning the tasks need. Test on your own questions before buying GPUs.
How is this different from a report writer or query tool?
A query tool answers the one question you built it for. An agent chains steps, like finding late lines, checking demand and drafting a message. If your needs are fixed reports, keep the report writer. Agents earn their place on messy, multi-step work.
What does it cost to start?
Mostly people time: IBM i views, a tool service and a review queue. A modest GPU server can be enough for a pilot with a few users. We avoid quoting numbers without seeing your environment, but a pilot should be measured in weeks, not quarters.
Want AI agents working on your JD Edwards World (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