AI agentsEpicor Kinetic Agent view

How to add AI agents to Epicor Kinetic

Short answer

Build AI agents for Epicor Kinetic as a thin tool layer over its REST v2 OData API and published BAQs, with a model that plans multi-step work and a human approval gate on every write. Start with read-only agents for MRP exceptions and late POs, then add drafted (not posted) transactions once the reads are trusted.

Get this built on your Epicor Kinetic

Most Kinetic shops already have the raw ingredients for agents: a few hundred BAQs, a BPM layer that fires on business events, and planners who spend the morning clearing the same exception lists. What they lack is something that reads those lists, gathers the surrounding context (supplier history, job status, open sales orders) and proposes an action, instead of just displaying another grid.

An agent here is not a chat window. It is a loop: a trigger, a model that picks tools, calls to Kinetic's API to fetch facts, a draft of the action, and a person who approves. The value is in the context assembly that a planner does manually across four or five Kinetic screens.

Epicor ships its own AI features in recent Kinetic releases, and they are worth evaluating first for generic tasks. A custom agent layer earns its place when the workflow is specific to your plant, when the data cannot leave your network, or when you need to span Kinetic plus a MES, a QMS or a shared drive.

What teams use it for

MRP exception triage

An agent reads the Planning Workbench style output (unfirm jobs, late supply, pull-ins and push-outs), groups exceptions by part and cause, and drafts a ranked worklist with recommended action per line for the planner.

PO expediting

For open PO releases past due, the agent checks the supplier's recent receipt history, the demand dates driving the part, and drafts an expedite email with the exact lines and the real need-by date.

Draft NCR from a receiving reject

When an inspection reject is logged, the agent pulls the PO, lot, supplier and prior rejects for that part, then drafts the nonconformance with a suggested disposition for the quality engineer to confirm.

Quote desk assistant

Given an RFQ email, the agent finds similar past quotes and the cost roll-up of the closest part, and drafts quote lines with a flagged margin range. A person finalises the quote in Kinetic.

Shortage chase for a kit

Before a job releases, the agent checks JobMtl requirements against on-hand by warehouse and bin, finds substitutes and open supply, and tells the supervisor what will actually stop the job.

Month-end accrual checks

An agent compares received-not-invoiced balances and aged AP against the receipts, and lists the items that need an accrual decision with the supporting documents attached.

Epicor Kinetic integration surface

Kinetic REST API v2 (OData) under paths like /api/v2/odata/{company}/Erp.BO.<Service>/..., with v1 still present on many installs. Service and method names vary by version, so confirm in the built-in API help page of your instance.
BAQs (Business Activity Queries) exposed through the BaqSvc OData endpoint. This is the safest read surface for agents because the query is reviewed once and the role security still applies.
Epicor Functions and BPM directives (method, data and in-transaction) for server-side logic and for emitting events when something changes.
Authentication with a per-user or service account plus an API key header on cloud and recent on-prem builds, subject to your version and licence.
Direct SQL Server access to the Erp and Ice schemas (for example OrderHed, OrderDtl, JobHead, JobMtl, PartTran, POHeader, PORel) is possible on-prem but bypasses Kinetic business logic, so use it only for read-only reporting replicas.

How it works

1
Pick one workflow and list the screens a human touches
Write down the exact Kinetic screens and fields the planner or buyer uses. That list becomes your tool list.
2
Expose reads as BAQs
Create or reuse a BAQ per question (late PO releases, unfirm job shortages). Reviewed BAQs are easier to audit than ad hoc OData filters.
3
Wrap each BAQ and BO call as a typed tool
Give every tool a name, a narrow parameter schema and a row limit. The model never sees raw credentials or free-form SQL.
4
Add the planning loop
The model receives the trigger, calls tools, and produces a structured proposal: what to change, why, and which Kinetic records back it up.
5
Route proposals to an approval surface
Send them to a queue, Teams or email. On approval, a separate write tool calls the relevant Kinetic service using a scoped service account.
6
Log everything
Store the prompt, tool calls, rows returned and the approver, so a quality or finance auditor can replay a decision.

Example flows

Morning late-PO sweep

Trigger: A scheduled job at 6:00 each plant day.

Call the late PO release BAQ for releases more than two days past due.
For each part, fetch the next three demand dates and the supplier's last five receipts.
Rank by the earliest demand that would be hit.
Draft one email per supplier listing the lines and the need-by date.
Post the drafts to a buyer queue.

Result: Buyers review and send in minutes rather than assembling the list from three screens. Nothing is written to Kinetic.

Short-kit warning before release

Trigger: A job is firmed in the planning workbench.

Read the job's material requirements.
Compare each to on-hand and allocated quantity by warehouse and bin.
Look up open supply and approved alternates for the short parts.
Draft a note with the true blockers and a proposed transfer or expedite.

Result: The supervisor learns about the real constraint before the job hits the floor.

Keeping data on-prem

Many Kinetic installs are on-prem or in a customer-controlled private cloud, and plants in aerospace or defense often forbid sending part data to a public model API. Run an open-weight model (for example a Llama or Qwen class model) with vLLM or Ollama on a GPU server inside the same network as the Kinetic application server. The agent service calls the Kinetic REST API locally, so no data crosses the boundary. For multi-tenant Epicor cloud, you are limited to the API surface Epicor exposes and your own network egress rules, so decide up front whether a hosted model is acceptable for those fields.

Security checklist

Use a dedicated Kinetic service account whose security roles equal the least a human in that job would have.
Keep agents read-only until a month of logs shows the reads are correct, then enable drafted writes only.
Never let the model compose raw SQL or arbitrary OData URLs. Only fixed tools with validated parameters.
Require named human approval for any PO change, receipt, job status change or price change.
Redact or tokenise supplier banking and customer contact data before it reaches the model.

Ways to get it done

Epicor's own AI features

Effort: Low, but limited to what ships.

Generic assistance and tasks Epicor has already productised, if licensed in your edition.

Build in-house on the REST API

Effort: Two to three months for a first production agent including approvals and logging.

You have developers comfortable with OData and a clear first workflow.

Partner such as Netray

Effort: Weeks for a scoped pilot, then iterate per workflow.

You need private, on-prem models, cross-system context, or an audit trail suited to regulated work.

Pitfalls

!Building agents on ad hoc OData filters that time out on large tables like PartTran. Use indexed BAQs.
!Letting a write tool run without approval because the demo looked right.
!Ignoring multi-company setups: every call must carry the correct company in the path.
!Forgetting that BPM directives can reject or alter the agent's writes, so test with the same directives live.
!Measuring success by demo quality instead of exceptions cleared per planner per day.

Frequently asked questions

Can an agent post transactions in Epicor Kinetic?

Technically yes, through business object methods in the REST API, but you should not start there. Begin with read-only agents, then allow drafts that a person approves. Posting directly to receipts, jobs or POs without review is how small model errors become inventory or financial errors.

Does this need Epicor's permission or a special licence?

API usage is governed by your Kinetic licence and whichever integration or user-count terms apply. Confirm with your Epicor account manager, especially for service accounts and high call volumes, before you build.

Which model should the agent use?

For non-sensitive data a hosted frontier model works well. For controlled or competitive data, an open-weight model on your own GPUs is the safer default. Tool calling quality varies by model, so test on your own workflows.

How is this different from Epicor Data Discovery or dashboards?

Dashboards show data and wait for a person to interpret it. Agents take a trigger, assemble context across several records, and propose an action. They complement dashboards rather than replace them.

How long until the first agent is useful?

A read-only exception triage agent over two or three BAQs is often usable in a few weeks. Approval flows, logging and role scoping take most of the remaining time, and they matter more than the model.