How to add AI agents to Epicor Vantage and Epicor 9
Short answer
Build the agent as a thin tool layer over Epicor's read paths (ODBC against the OpenEdge database or BAQ exports) and a very small set of write paths (business objects or Service Connect workflows), with a human approving every write. The model runs on your own hardware if the data cannot leave the plant.
A lot of shops are still on Vantage 8.x or Epicor 9 and 9.05. The system works, the customisations are deep, and nobody wants a forced move to Kinetic just to get AI. The good news is that an agent does not need the vendor to ship anything: it needs a way to read the same data your planners read, and a controlled way to propose changes.
What makes agents on this generation of Epicor different from newer cloud ERPs is the plumbing. There is no modern REST API to point a tool at. You have a Progress OpenEdge database, a .NET business object layer, and the older Service Connect integration engine. Each of those is usable, but each has quirks, and the agent design has to respect them.
The practical pattern is narrow agents with a clear job: one that triages late jobs and shortage lists, one that drafts purchase order change requests, one that reviews quality holds. Each gets read access to a few tables and a single approval queue for anything that changes data.
What teams use it for
Shortage and late-job triage
An agent walks open JobHead and JobMtl rows against PartWhse on-hand and open PODetail releases, then writes a ranked list of jobs that cannot start and the single PO line most likely to unblock each.
PO expedite drafting
For open PO releases past due, the agent drafts a supplier email with part, quantity and the sales order it feeds, and queues a proposed due date change for a buyer to approve in Epicor.
Quote-to-order review
Before a quote converts, the agent checks the part methods, lead times and last actual costs and flags lines priced below recent job cost.
Non-conformance drafting
When a receipt is rejected at inspection, the agent assembles supplier, PO, lot and inspection notes into a draft NCR for the quality engineer to edit.
Month-end exception sweep
The agent scans for negative on-hand, jobs closed with unissued material, and receipts without matching invoices, and produces a worklist for the controller.
Epicor Vantage / Epicor 9 integration surface
- OpenEdge (Progress) database: read through ODBC or JDBC using the Progress SQL-92 driver, typically against a read replica or a nightly restore so agents never load the production broker.
- Business Activity Queries (BAQs) in Epicor 9 / 9.05: saved queries that can be exported or called through the application layer, useful for pre-shaped result sets that match what users already trust.
- Business objects (BOs) exposed through the Epicor 9 service layer and the .NET client assemblies: the supported way to write, since they run Epicor's own validation and triggers. Exact endpoint style varies by version and patch level.
- Service Connect (Epicor 9 integration engine): workflows that can receive XML or file input and call business objects, a reasonable landing zone for agent-proposed writes.
- Customer-defined UD tables and UD fields: heavily used in older installs, and often where the real business rules live, so the agent's schema notes must include them.
How it works
- 1
Pick two or three jobs, not a platform
Start with shortage triage and PO expedite. Both are read-heavy, both have an obvious human owner, and both show value in a week.
- 2
Stand up a read path off production
Point a Progress SQL read-only user at a replica or restored copy. Confirm the ODBC driver version matches your OpenEdge release, and set a query timeout so a bad agent query cannot hang the shop.
- 3
Write a schema card per job
Document the handful of tables, key joins (JobNum, AssemblySeq, MtlSeq; PONUM, POLine, PORelNum) and what each status flag means in your install, including UD fields. The model reasons far better with this than with raw DDL.
- 4
Build the tool layer
Expose functions like get_open_shortages, get_po_releases and get_job_material. Each returns small, typed results with the SQL that produced them. No free-form SQL tool in production.
- 5
Add one controlled write path
Proposed changes land in a staging table or approval queue. After a named person approves, a separate service calls the relevant business object or a Service Connect workflow. The agent itself never holds write credentials.
- 6
Log everything
Store the prompt, tool calls, result rows and the approver's decision. This is your audit trail and your evaluation set.
Example flows
Morning shortage digest
Trigger: 6:00 AM scheduled run
- Query released jobs starting in the next five days with unissued material.
- Compare required quantity to on-hand and to open PO releases due before the job start.
- Classify each gap: covered by PO, PO late, no PO.
- Rank by sales order due date and customer priority.
- Post the digest to the planner group with the SQL attached.
Result: Planners start the day with a short, justified list instead of exporting three screens into a spreadsheet.
Supplier delay to PO change proposal
Trigger: Buyer forwards a supplier delay email to a monitored mailbox
- Agent extracts PO number, part and new promise date.
- It looks up the PO release and the jobs consuming that part.
- It computes which jobs slip and by how many days.
- It writes a proposed due date change and impact note to the approval queue.
Result: The buyer approves with one click, and the change is applied through the business object layer with the impact note stored.
Keeping data on-prem
Epicor 9 and Vantage are typically deployed on servers the customer already owns, so keeping the AI on-prem is natural. Run an open-weight model (Llama, Qwen, Mistral or gpt-oss class) with vLLM or Ollama on a GPU server in the same network segment as the database replica. The agent service talks to the model locally, reads over ODBC, and writes only through an approval queue. Nothing about part numbers, costs or customer orders needs to cross the firewall. For air-gapped sites, load the model weights and tool code through a controlled transfer process and keep the replica refreshed from backup media.
Security checklist
- Use a dedicated read-only database login limited to named tables and views, never the application service account.
- Separate the agent service identity from the approver identity so no single credential can both propose and apply.
- Mask or exclude sensitive columns such as customer pricing contracts if the agent's audience should not see them.
- Keep full logs of tool calls and results with retention matching your quality and finance record policies.
- For export-controlled part data, run the model in an environment that satisfies your own compliance program; the architecture helps, the obligation stays with you.
Ways to get it done
Build in-house with a scripting team
Effort: Typically 6 to 12 weeks for the first two agents, longer for write-back.
Works if you already have someone who knows Progress SQL and your Epicor customisations.
Epicor Kinetic upgrade plus Epicor's own AI features
Effort: Dominated by the upgrade project, not the AI.
Sensible if a Kinetic move is already planned; the vendor tooling is then simpler than custom work.
Partner build with Netray and an Epicor domain partner
Effort: A scoped pilot of one or two agents is usually a matter of weeks.
Good when you want on-prem models, read-only by default and a tested approval flow without growing a team.
Pitfalls
- !Pointing the agent at the live production database and letting an expensive join lock users out.
- !Ignoring UD fields and customised status codes, so the agent reasons confidently on the wrong meaning.
- !Writing directly to Progress tables, which skips business object validation and can corrupt balances.
- !Giving the model a free-form SQL tool, which invites runaway queries and leaks columns you meant to hide.
- !Skipping evaluation: no one checks whether the shortage list matches what planners would have found.
Frequently asked questions
Can I add AI agents to Epicor 9 without upgrading to Kinetic?
Yes. The agent reads from the OpenEdge database or exported BAQ results and writes through business objects or Service Connect, none of which require Kinetic. The trade-off is that you build more of the plumbing yourself and test against your own customisations.
Is it safe to let an agent write to Epicor?
Only through a controlled path. Have the agent propose changes into a queue, require a named human approval, and apply them through Epicor's business objects so standard validation runs. Direct table writes should be avoided entirely.
Which model should run the agent?
For on-prem, an open-weight model in the Llama, Qwen, Mistral or gpt-oss class served with vLLM or Ollama is a reasonable start. Pick by testing against your own shortage and PO data, not by benchmark alone.
Do I need a data warehouse first?
Not for a pilot. A read-only replica or nightly restore is enough for triage and expedite agents. A warehouse becomes useful when you want history, trend analysis or to join Epicor with MES and quality data.
How is this different from just asking questions in natural language?
A question-answer tool responds when asked. An agent runs a multi-step routine on a schedule or trigger, such as the morning shortage review, and drafts actions for approval. Many teams start with Q and A and graduate to agents.
Want AI agents working on your Epicor Vantage / Epicor 9?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment