How to add AI agents to Infor M3
Short answer
Add AI agents to Infor M3 by wrapping the M3 API (MI programs such as PPS200MI, OIS100MI and MMS200MI) as a small set of typed tools, then letting an agent call them under a service account with read-only scope first. Writes go through an approval step, and ION events can trigger the agent instead of polling.
M3 shops, often in food and beverage, fashion and apparel, chemicals, and discrete manufacturing, have a lot of exception work that lives between screens: late purchase orders in PPS200, manufacturing orders that cannot release because of a material shortage, customer orders on hold in OIS100, and planned orders that nobody has firmed. Planners spend the day moving between programs and spreadsheets to decide what to do next.
An AI agent is useful here when it does the looking and drafting, and a person does the approving. The agent reads the same data a planner would, reasons over it, and proposes an action such as a PO date change request to the supplier or a firmed planned order. It does not need to replace anyone to save hours a week.
M3 is well suited to this because almost everything is exposed as MI programs with documented inputs and outputs, and ION gives you events and an authenticated gateway. The hard part is not the model, it is choosing a narrow set of tools and a safe approval path.
What teams use it for
Late PO triage
Each morning the agent lists open PO lines past their confirmed delivery date, checks which ones feed released manufacturing orders, and drafts a ranked chase list with suggested supplier messages.
Material shortage explainer
For a manufacturing order that cannot start, the agent walks the product structure, compares allocations to on-hand balance, and names the specific component and the PO or planned order that would fix it.
Order hold resolution
When a customer order line is blocked on credit or a status, the agent gathers the order, customer balance and last payments and prepares a short brief for the person who can release it.
Planned order review
The agent reviews MRP planned orders against lead times and safety stock, flags ones that look wrong, and proposes which to firm, leaving the actual firming to a planner.
Item master hygiene
It scans item and warehouse records for missing planning parameters or inconsistent units and produces a correction list for data stewards.
Supplier confirmation follow-up
Combined with an inbox, the agent matches supplier replies to PO lines and proposes the date updates, with a person confirming each change.
Infor M3 integration surface
- M3 API: MI programs are called with a program name, a transaction and named fields, for example MMS200MI for item warehouse data, PPS200MI for purchase orders, OIS100MI for customer orders, CRS610MI for customers. Available transactions vary by version and installed updates, so enumerate them from the MI metadata in your own environment.
- REST access: on cloud tenants the ION API Gateway fronts M3 API calls with OAuth 2.0 using a service account and an .ionapi file. On-premises installs typically expose the M3 API through the grid with basic or token-based auth; confirm the exact base path for your version.
- ION: Business Object Documents and ION Messaging let you subscribe to events such as order or item changes, which is the right trigger for agents instead of polling.
- Infor Process Automation (IPA): can run approvals and call M3 as a governed workflow, useful as the human-in-the-loop step.
- Database: on-prem M3 sits on SQL Server, Oracle or Db2 with tables such as MITMAS, MITBAL, MPLINE, OOLINE and MWOHED. Direct reads are possible but bypass M3 authorisation, so prefer the API for anything an agent will explain to users.
- Data Lake and Compass: for analytical context across history, agents can query the Infor Data Lake instead of loading the transactional system.
How it works
- 1
Pick one narrow job
Choose a task with a clear owner and a measurable queue, such as late PO triage. Resist building a general assistant first.
- 2
Create a dedicated service account
Give it an M3 security role limited to the MI programs the job needs, read-only to begin with. Do not reuse a person's credentials.
- 3
Wrap MI transactions as typed tools
Expose functions like get_po_lines_overdue(supplier, days) and get_mo_shortages(facility). Validate parameters, cap row counts, and return trimmed JSON, not raw screens.
- 4
Add the reasoning loop
Run the model with the tool list and a system prompt that states what it may and may not do. Log every tool call and its arguments.
- 5
Insert an approval step
Anything that writes, such as changing a PO line date, becomes a proposal sent to a person through IPA, Teams, or email. Only on approval does a separate write tool run.
- 6
Trigger from events
Subscribe through ION to relevant changes, or schedule a daily run, so the agent works the queue rather than waiting to be asked.
- 7
Evaluate on real history
Replay last month's exceptions, compare the agent's proposals to what planners actually did, and widen scope only when it matches.
Example flows
Morning late-PO brief
Trigger: Scheduled run at 06:00 per purchasing group.
- List open PO lines where confirmed date is earlier than today.
- For each, look up the demand: which released manufacturing orders consume the item.
- Rank by the earliest start date at risk.
- Draft a supplier chase message and a suggested revised date.
- Post the ranked list to the buyer for review.
Result: Buyers start the day with a prioritised list that already names the production impact.
Shortage explanation on request
Trigger: A planner asks why a manufacturing order will not release.
- Fetch the order header and material lines.
- Compare required quantity to available balance by warehouse.
- Find inbound POs and planned orders for the short component.
- Summarise the gap and the earliest fix date.
Result: A two-minute answer instead of walking five programs, with the data shown for the planner to verify.
Keeping data on-prem
Run the whole stack inside your network: the M3 API on your grid, an agent service on a server in the same segment, and an open-weight model served with vLLM or Ollama on your own GPUs. The agent talks to M3 over the internal API and to the model over a local endpoint, so no order, pricing or customer data leaves the building. This matters for defense, aerospace and regulated-chemicals customers whose data classifications forbid public model APIs. For modest workloads a single GPU server is often enough because the agent sends compact tool results, not whole tables. Keep the model host out of the ERP database network and allow only the API port.
Security checklist
- Dedicated service account with a least-privilege M3 role, reviewed like any integration user.
- Read-only tools first; write tools are separate, off by default, and require an approval token.
- Log every tool call, arguments, and result summary to an immutable store for audit.
- Cap rows and fields returned so a prompt cannot pull the whole customer master.
- Treat text inside orders or supplier emails as untrusted input to avoid prompt injection steering a write.
Ways to get it done
Infor OS and the vendor's own AI features
Effort: Low to medium; limited control over custom logic and models.
Good if your tenant already includes them and the use case is generic, such as reporting questions.
Build in-house on MI programs
Effort: Typically a few weeks for one workflow, then ongoing tuning.
Fits teams with M3 developers and an AI engineer who can maintain tools and evaluation.
Partner such as Netray with an M3 domain expert
Effort: Scoped pilot on one queue, then extended workflow by workflow.
Fits teams wanting a private, on-prem deployment with open models and an approval design done once.
Pitfalls
- !Exposing every MI transaction as a tool; the model then picks wrong ones. Curate fewer, clearer tools.
- !Letting the agent write without approval because early tests looked good.
- !Ignoring facility and warehouse context, so answers mix data across sites.
- !Using raw database reads that skip M3 authority checks and show users data they could not see in M3.
- !No evaluation set, so nobody knows if a prompt change made things worse.
Frequently asked questions
Can an AI agent change data in Infor M3?
Yes through MI program write transactions, but it should not do so directly. A safer pattern is that the agent proposes a change, a person approves it in IPA or a chat tool, and a separate write tool executes with the service account and logs the result.
Do we need ION to use agents with M3?
Not strictly. The M3 API alone supports on-demand agents. ION becomes valuable when you want event triggers, such as reacting to a changed order, and when your cloud tenant requires the ION API Gateway for authenticated access.
Will it work on an older on-premises M3 version?
Often yes, because MI programs have existed for many releases. Available transactions and authentication differ by version, so inventory your MI metadata first and plan a small proof of concept before committing.
Which model should the agent use?
For private deployments, open-weight models in the Llama, Qwen or gpt-oss class served locally work for structured tool use. Cloud models can be stronger on hard reasoning, so decide by data sensitivity and run an evaluation on your own cases.
How is this different from asking questions of M3 in natural language?
Question answering is read-only retrieval. An agent plans several steps, uses multiple tools, and may prepare actions. Many teams start with the question layer and add agents once trust in the data access is established.
Want AI agents working on your Infor M3?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment