How to add AI agents to ECI M1
Short answer
Build agents as a thin tool layer over M1: parameterised read queries against SQL Server (or a reporting replica), plus a small set of approved write paths through whatever supported import or API route your M1 version offers. Keep every write behind a human approval step, and run the model on your own hardware if the data is sensitive.
ECI M1 is a job-shop and discrete manufacturing ERP, usually installed on-premises on Microsoft SQL Server and run by a small IT team that also supports the shop floor. The planners, buyers and estimators who live in M1 spend a lot of their day on repeatable detective work: why is this job short, which POs are late against a promise date, what changed on this quote.
An AI agent is useful here when it does that detective work and hands back a decision for a person to approve. It is not useful as an autonomous operator that edits routings or releases jobs. The honest scope for a first agent is read, reason, draft, and ask.
M1 sites also vary a lot: version, customisation level, whether a web API module is licensed, and how much logic lives in custom reports and SQL views. The architecture below is built to tolerate that variation rather than assume one clean API.
What teams use it for
Late-PO expediter
Scans open purchase order lines past or near their promise date, groups them by vendor and by the jobs they feed, ranks by shop impact, and drafts a vendor chase email for the buyer to review.
Job shortage triage
For a job about to be released, compares the bill of materials against on-hand and on-order quantities, explains which components are short and what supply is coming, and proposes a release date.
Quote-to-history estimator assistant
When an estimator opens a new RFQ, the agent finds similar past jobs by part family and routing, and summarises actual versus quoted hours and material so the new quote starts from evidence.
Nonconformance drafter
Takes a rejected-quantity entry from receiving or inspection and drafts a nonconformance record with part, vendor, job and lot context for the quality lead to confirm.
Month-end exceptions sweeper
Looks for jobs closed with unposted labor, receipts without matching invoices, and negative on-hand, then lists them with the likely cause for accounting to clear.
ECI M1 integration surface
- Microsoft SQL Server database behind M1: the main read path for agents. Table and column names differ by version and customisation, so build a documented view layer rather than querying base tables directly from the model.
- Whatever supported integration route your M1 version includes (web services, import utilities or an integration module). Confirm what is licensed on your contract before designing write-back.
- Reports and report-writer outputs (often Crystal Reports or SSRS style, version dependent) that already encode business logic such as shortage and open-order logic; reuse their SQL as a starting point.
- Scheduled exports to CSV or a staging database, which is a workable fallback when direct access to production is not permitted.
- M1 security roles and user tables, which should drive who is allowed to ask the agent what.
How it works
- 1
Pick one workflow and write down the decision
Choose something like late-PO expediting. Define the inputs, the output a buyer would accept, and what the agent is never allowed to do.
- 2
Stand up a read replica or reporting copy
Use SQL Server log shipping, a nightly restore, or an availability replica so agent queries never compete with the shop floor on the production database.
- 3
Build a semantic view layer
Create named views such as OpenPOLines, JobShortages and ItemAvailability with plain column names. The agent calls tools that read these views, never free-form SQL against base tables.
- 4
Wrap views as typed tools
Each tool has validated parameters, a row limit and a timeout. Add a small number of draft tools that write to a review queue, not to M1.
- 5
Add an approval step
Any change destined for M1 goes to a person in a queue (a web page, Teams card or email) with the evidence shown. Only after approval does a scoped service account perform the supported write.
- 6
Log everything and evaluate
Store each question, tool call, SQL and answer. Replay a few hundred historic cases and compare against what planners actually did before widening scope.
Example flows
Morning late-PO sweep
Trigger: Scheduled at 6:30 a.m. before the buyer arrives.
- Agent calls the OpenPOLines tool for lines due within three days or already late.
- For each line it calls JobShortages to see which released or soon-to-release jobs depend on it.
- It ranks vendors by number of at-risk jobs and drafts a chase email per vendor.
- Drafts land in the buyer's review queue with the underlying rows attached.
Result: The buyer starts the day with a ranked, evidence-backed list and edits drafts instead of building them.
Release-readiness check
Trigger: A planner asks, in chat, whether job 12345 can release Monday.
- Agent reads the job BOM and routing from the view layer.
- It compares requirements to on-hand and open supply by date.
- It lists short components, the earliest supply and any subcontract operations that need lead time.
- It offers a proposed release date and flags assumptions.
Result: The planner gets a grounded yes or no with reasons, and decides whether to release.
Keeping data on-prem
M1 is typically already on-prem, so keep the whole stack there. Run an open-weight model (a Llama, Qwen or Mistral class model) on a GPU server in the same network segment using vLLM or Ollama, point the tool layer at the SQL Server replica over an internal connection, and block outbound internet from the agent host. For aerospace or defense job shops this keeps part numbers, customer names and drawings off third-party clouds, and lets you show an auditor exactly which systems the data touched. Size the model to the task: structured tool use over short result sets works well with mid-sized models, so you rarely need the largest GPU.
Security checklist
- Use a dedicated read-only SQL login limited to the view layer; never give the agent the application's own SQL account.
- Map each requesting user to their M1 role and filter views accordingly, so the agent cannot show costs or customer data a user could not see in M1.
- Require human approval for every write and log who approved what.
- Redact or tokenise sensitive fields (customer names, export-controlled part descriptions) if any call leaves the network.
- Retain full tool-call logs for audit and for diagnosing wrong answers.
Ways to get it done
Use ECI or reseller-supplied tools and report writers
Effort: Days, but limited to what the tools already do.
Enough when your need is a fixed report or alert with no reasoning across data.
Build in-house with a SQL view layer and an agent framework
Effort: Typically a few weeks for a first read-only agent, longer for write paths.
Good when you have a developer who knows your M1 schema and customisations.
Work with a partner such as Netray
Effort: A scoped pilot on one workflow, often within a few weeks.
Useful when you want on-prem models, a tested tool layer and an M1-aware reviewer without building the platform yourself.
Pitfalls
- !Letting the model write free-form SQL against base tables: it will join wrongly on keys that vary by customisation.
- !Running agents against production during shop-floor hours and slowing transaction entry.
- !Ignoring custom fields and user-defined tables that carry the real business rules.
- !Skipping evaluation: agents look right on easy cases and fail on partial receipts, subcontract and rework jobs.
- !Granting write access too early, before approval and rollback paths exist.
Frequently asked questions
Does ECI M1 have an official AI agent API?
Do not assume so. Integration options depend on your M1 version and licensed modules. The dependable path today is read access through SQL Server views, plus whatever supported import or API route your contract includes for approved writes. Ask your ECI contact what is licensed.
Can an agent update jobs or POs automatically?
It can, but you should not start there. Begin read-only, move to drafts in a review queue, and only allow writes after a person approves each one. Use a supported write path rather than inserting rows directly into SQL tables.
Which model should I use?
For on-prem work, a mid-sized open-weight model with good tool-calling is usually enough because the agent reads short, structured result sets. For cloud use, any major provider works, subject to your data policy.
Will it slow down M1?
Not if you point it at a replica or restored copy and limit query cost. Slowdowns almost always come from agents hitting production with unbounded queries.
How do we know the agent is right?
Replay historical cases where you know the correct answer, log every tool call and SQL statement, and sample real answers weekly. Show the evidence rows next to every answer so users can verify quickly.
Want AI agents working on your ECI M1?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment