How to add AI agents to Sage X3
Short answer
Build agents as a thin tool layer over Sage X3 SData REST or published web services, with a database read replica for analysis. Let the agent read, reason and draft; route every write through a user's approval and the X3 user's own rights.
Most Sage X3 manufacturers already have the raw material for agents: MRP messages nobody clears, purchase orders drifting past their promised dates, and work orders short of components. The problem is not data, it is that a planner needs to open several functions (purchase order inquiry, MRP messages, stock by lot) to answer one question.
An agent is useful when it chains those lookups for you and drafts the next action. For X3 that means deciding which of your folders, legislations and endpoints the agent may touch, because a multi-folder, multi-site X3 installation behaves differently from a single-company one.
The sensible path is read-only agents first, one narrow job each, then drafted writes with approval. A broad agent with write access to purchasing is a risk, not a feature.
What teams use it for
MRP exception triage
An agent pulls open MRP messages, groups them by buyer and item, checks supplier lead times and stock, and proposes which to action, defer or cancel.
Late purchase order chaser
Finds purchase order lines past the expected receipt date, drafts a supplier email, and proposes a revised date in a note for the buyer to confirm.
Shortage explainer for work orders
For a released work order, lists missing components, matching open supply, and which customer orders are exposed if nothing changes.
Customer order status desk
Answers where a sales order is across production, picking and delivery, so customer service stops hopping between functions.
Master data hygiene checker
Scans items and suppliers for missing lead times, zero safety stock or duplicate suppliers, and queues corrections for a data owner.
Sage X3 integration surface
- SData 2.0 REST services published by Syracuse under a path such as /sdata/x3/erp/FOLDERNAME/, exposing representations like sales orders, purchase orders and items. Which representations exist depends on version and your configuration.
- SOAP web services published from X3 classes and subprograms through the web services pool, still common on older v6 and v7 estates.
- Newer releases add a GraphQL layer on Syracuse (check your version and patch level before relying on it).
- Direct database reads on Oracle or SQL Server, where tables carry X3 names such as SORDER, SORDERQ, PORDER, PORDERQ, ITMMASTER, STOCK and MFGHEAD. Use a read replica, never the live schema for heavy queries.
- X3 workflow rules and alert hooks to raise an event when a business object changes, so agents can react instead of poll.
How it works
- 1
Pick one job and one folder
Choose a single process, such as MRP triage for one production folder. Agent scope tied to one folder keeps rights and data volumes manageable.
- 2
Create a dedicated X3 user
Give the agent its own user and role limited to the functions it needs. Do not share a power user's login.
- 3
Define typed tools
Wrap SData or web service calls as tools such as get_open_mrp_messages(buyer) and get_po_lines(supplier). Return compact JSON, not whole records.
- 4
Add a read replica path for analysis
For multi-table questions, expose parameterised SQL views on a replica. Never let a model compose free SQL against the live database.
- 5
Run the model and orchestration
Use an open-weight model served with vLLM or Ollama for on-prem, or a cloud model if policy allows. Log each tool call and result.
- 6
Draft writes, then approve
The agent prepares a purchase order change or supplier note; a named user approves in a queue and the write runs under the right account.
Example flows
Weekly MRP triage
Trigger: Planner opens the triage view on Monday morning
- Agent pulls open MRP messages for the buyer's items.
- It reads stock, open purchase orders and supplier lead time for each.
- It classifies each message as action, reschedule or cancel with a reason.
- It prints the exact SData or SQL it used for each line.
Result: The planner reviews a ranked list with evidence instead of reading hundreds of raw messages.
Late supplier follow-up
Trigger: A purchase order line passes its expected date with no receipt
- Workflow rule or nightly job flags the line.
- Agent checks prior receipts and the supplier's history of lateness.
- It drafts an email in the buyer's tone and a proposed new date.
- Buyer approves, edits or rejects the draft.
Result: Follow-ups happen on the day the line slips, with a record of what was sent.
Keeping data on-prem
Many Sage X3 sites are on-prem or in a partner-hosted private cloud, and that fits agents well. Run the model on a GPU server in the same network as Syracuse, call SData over the internal address, and read from a replica of the Oracle or SQL Server database. Nothing about item costs, supplier terms or customer prices has to leave your boundary. Model weights are open-weight (Llama, Qwen or Mistral class) so you control updates. If your X3 is hosted by a third party, confirm whether you may add a service next to it or must reach it over a VPN, since that decides latency and what network paths are available.
Security checklist
- Dedicated X3 user per agent, with function and site rights as narrow as the job allows.
- Read-only by default; writes only as drafts that a human approves.
- Log prompt, tool calls, SQL or SData URLs and results for audit.
- Mask or exclude fields such as bank details and customer pricing where the job does not need them.
- Rotate credentials and keep them in a secrets store, not in prompts or code.
Ways to get it done
Use Sage's own AI features and standard workflow
Effort: Low, mostly configuration.
Enough if your need is notifications and simple automation. Check what your X3 version and licence include.
Build in-house with SData and a framework
Effort: Weeks for one agent, plus ongoing tuning.
Good if you have an X3 developer and someone comfortable with LLM tool calling.
Work with Netray and your X3 partner
Effort: A scoped pilot over several weeks.
Fits when you want on-prem models, tested tools and approvals, with your partner covering X3 specifics.
Pitfalls
- !Assuming every SData representation is published. Many need setup, and customised classes may not appear.
- !Letting the agent query the live database during MRP or batch jobs, which hurts users.
- !Ignoring multi-folder and multi-site context so answers mix data from different entities.
- !Skipping approval on writes because the first demos looked fine.
- !Forgetting that custom fields and screens added in your folder change the data shape between sites.
Frequently asked questions
Can an AI agent write into Sage X3?
Technically yes through SData or web services, but start read-only. When you add writes, keep them as drafts that a named user approves, executed under an account with limited rights, so the X3 audit trail and your own controls still apply.
Do I need SData enabled for agents?
It is the cleanest route, but web services or a read replica can also work, depending on version and what your partner has published. Check with your X3 administrator which services are available before choosing the design.
Will agents slow down my X3 system?
They can if they hit the live database heavily. Use compact API calls, caching, and a replica for analysis, and schedule heavy agent runs away from MRP and period-end processing.
Can this run without sending data to the cloud?
Yes. An open-weight model on your own GPU server, reaching X3 over the internal network, keeps data inside your boundary. Quality depends on the model size and how well the tools are defined.
How is an agent different from a report?
A report shows data you already asked for. An agent chains several lookups, reasons across them, and drafts an action, while showing the evidence. The tradeoff is more engineering and control than a Crystal report.
Want AI agents working on your Sage X3?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment