How to add AI agents to ECI E2 Shop System
Short answer
Add AI agents to E2 Shop System by exposing a small set of audited, read-only tools over the E2 SQL Server database (jobs, quotes, purchasing, inventory, shop floor labor), then letting an agent plan across those tools. Writes go through a review queue, not straight into E2 tables.
E2 Shop System is the job-shop ERP many make-to-order machine shops, fabricators and contract manufacturers run quote to ship. The data is rich: job routings, operation-level labor, material requirements, purchase orders, vendor lead times, customer history. The people who use it are usually a small office team already stretched across quoting, scheduling and chasing material.
That is where agents help. A good agent is not a chatbot that guesses. It is a worker that follows a multi-step procedure: pull the late jobs, check which are waiting on material, look at the open PO and the vendor's history, and draft the follow-up. The estimator, buyer or scheduler stays in charge and approves anything that changes E2.
Because E2 is commonly installed on a customer server or private network, the design question is usually not whether an agent is possible but where the model runs and how the agent touches the database safely.
What teams use it for
Late job triage
Each morning an agent lists jobs past or near their due date, finds the blocking operation or missing material, and produces a ranked list with a proposed action per job for the scheduler.
Purchasing follow-up drafts
For open PO lines past promise date, the agent reads the vendor history, drafts a polite chase email, and proposes a revised receive date for the buyer to confirm.
Quote prep assistant
Given an RFQ, the agent finds similar past jobs, pulls actual hours and material cost versus the original estimate, and pre-fills a quote draft with the historical variance noted.
Quote-to-actual margin watch
Weekly, the agent compares quoted and actual cost on completed jobs, flags customers or part families that consistently overrun, and explains where the hours went.
Inventory and reorder review
The agent compares on-hand, allocated and on-order quantities against upcoming job demand and proposes a short buy list with the jobs each line supports.
Shipping and invoice readiness
It checks completed jobs against packing and invoicing status and lists work that shipped but was not billed, a classic leak in small shops.
ECI E2 Shop System integration surface
- SQL Server database: current E2 versions store data in Microsoft SQL Server, so read-only access through a dedicated, least-privilege SQL login is the most reliable surface. Table and column names vary by version, so map them from the actual schema rather than assuming.
- Reports: E2 ships with Crystal Reports based reporting, and existing report definitions are a good way to learn which tables and joins the vendor itself uses for jobs, orders and purchasing.
- Import and export tools: E2 includes data import and export utilities and Excel export on many screens, useful for a first bulk load into a retrieval index but not for live answers.
- Add-on modules: depending on licensing, there may be data collection, scheduling, customer portal or document modules. Ask ECI or your reseller what APIs or web services your licensed version exposes before building on any of them.
- Email and file shares: attachments, drawings and quote documents often live on file shares referenced from E2 records, which an agent can index separately.
How it works
- 1
Pick two or three narrow jobs
Start with late-job triage and PO follow-up. Narrow scope makes accuracy testable and makes approvals quick.
- 2
Create a read-only data path
Provision a SQL login with SELECT only on the needed tables or views. Prefer curated views (open jobs, open PO lines, inventory position) so the agent never sees raw tables it does not need.
- 3
Define the tool layer
Wrap each view in a function with typed parameters: get_job(job_no), list_late_jobs(days), get_po_lines(vendor), get_part_history(part). The agent calls tools; it never writes SQL freely.
- 4
Add a retrieval layer for documents
Index quotes, drawings notes, supplier emails and procedures so the agent can cite them next to the numbers.
- 5
Write the agent procedures
Encode each workflow as explicit steps with stop conditions, for example: if a job has no blocking cause after three checks, escalate to a human rather than guess.
- 6
Route writes to an approval queue
Anything that changes E2, such as a revised promise date, goes to a queue where a person approves it, and the change is applied through the supported import path or by hand.
- 7
Log and evaluate
Record every tool call and answer, replay real past scenarios, and compare agent findings against what the scheduler actually did.
Example flows
Morning late-job brief
Trigger: Scheduled at 6:30 each weekday.
- Agent calls list_late_jobs for jobs due within three days.
- For each, it fetches the next incomplete operation and material status.
- It checks open PO lines tied to the shortage and their promise dates.
- It ranks jobs by customer priority and slack.
- It posts the brief to the scheduler with the evidence for each line.
Result: The scheduler starts the day with a prioritised, evidence-backed list instead of building it from three screens.
Vendor chase on a short PO
Trigger: A PO line is two days past promise date and blocks a job.
- Agent loads the PO line, vendor and the job it supports.
- It reads the vendor's last twelve months of on-time performance.
- It drafts a chase email citing the PO number and need date.
- Buyer reviews, edits and sends.
Result: Faster, consistent follow-ups with the buyer still owning the vendor relationship.
Keeping data on-prem
A typical E2 install is a Windows server running SQL Server inside the shop's network, which suits a fully local agent stack. Run an open-weight model with vLLM or Ollama on a GPU workstation or small server, keep the retrieval index on the same network, and give the agent service only the read-only SQL login. No job, pricing or customer data has to leave the building, which matters for shops serving aerospace and defense customers under flow-down requirements. The agent host, the model and the database can sit on separate machines with firewall rules that allow only the specific ports needed. Backups of the index and logs follow the same schedule as E2 itself.
Security checklist
- Dedicated read-only SQL login scoped to curated views; no shared sa or admin credentials.
- Role-aware answers: the agent should respect which users may see pricing and cost, since E2 users have differing rights.
- Human approval for every write, with the proposed change shown as a diff.
- Full audit log of prompts, tool calls and outputs retained on your own infrastructure.
- Redaction rules for customer-controlled data before anything is sent to an external model, or no external model at all.
Ways to get it done
Use E2 reports and Excel plus a general AI tool
Effort: Hours to set up; manual and stale by nature.
Fine for ad hoc analysis of exported data when nothing sensitive is involved and freshness is not critical.
Build in-house with a read-only tool layer
Effort: Several weeks for a first agent, plus ongoing tuning.
Works if you have a developer comfortable with SQL Server and an LLM framework who can maintain it.
Work with a partner such as Netray
Effort: A scoped pilot over a few weeks, then extend workflow by workflow.
Best when you want private on-prem deployment, an E2-aware schema map and an approval workflow without building the plumbing.
Pitfalls
- !Letting the model write free-form SQL against production; use fixed tools and views instead.
- !Assuming column names from a different version of E2; verify against your own schema.
- !Automating writes before accuracy on reads is proven and measured.
- !Ignoring that routings and labor reporting quality in E2 depends on how disciplined the shop floor is; agents inherit bad data.
- !Running reports queries during production hours against a heavily loaded SQL Server without testing impact.
Frequently asked questions
Does E2 Shop System have an official API for AI agents?
It depends on your version and licensed modules. Many shops rely on the SQL Server database for read access and on supported import tools for writes. Confirm with ECI or your reseller what web services your version offers before choosing a design.
Can an agent update jobs or purchase orders in E2 directly?
Technically possible, but writing straight into ERP tables bypasses business logic and is risky. A safer pattern is an approval queue where a person confirms the change and it is applied through a supported path.
Will agents work with a small shop's data quality?
They work, but they surface data problems quickly, such as missing routings or inconsistent vendor lead times. Plan for a short cleanup phase and treat the first findings as data-quality feedback.
Do we need a GPU to run this on-prem?
For a private model of useful quality, usually yes, though a single modest workstation GPU can serve a small shop. Smaller open models handle structured lookups well; heavier reasoning benefits from more memory.
How is this different from E2 reports?
Reports answer fixed questions. An agent chains several lookups, reads documents and drafts actions. For a question you ask every day, a saved report is still the simpler tool.
More for ECI E2 Shop System
Want AI agents working on your ECI E2 Shop System?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment