How to add AI agents to ECI JobBOSS2
Short answer
Add AI agents to JobBOSS2 by giving a model a small set of audited tools over its SQL Server data (and its API where your edition has one), then letting the agent run narrow jobs such as late-job triage or quote drafting. Reads are open, writes go through a human approval step.
JobBOSS2 runs a large number of job shops: CNC machining, fabrication, sheet metal, and contract manufacturers with high-mix, low-volume work. The data is rich (quotes, jobs, operations, material requirements, deliveries, purchase orders, time tickets) but the people who know how to pull it together are usually two or three office staff who are also quoting, expediting and invoicing.
An AI agent is not a chatbot. It is a worker that takes a goal, calls tools against the system, checks its own results and produces a finished artifact: a ranked list of at-risk jobs with reasons, a draft PO, a quote built from similar past jobs. In a job shop the value is mostly in repetitive investigation work that currently eats the scheduler's morning.
This page describes how to wire that up safely on JobBOSS2, including when the database is on a server in your building and nothing can leave it.
What teams use it for
Late-job triage every morning
An agent reads open jobs with due dates in the next two weeks, compares remaining operation hours to work center load, checks material requirements for shortages, and writes a short ranked list: which jobs will miss, why, and what the cheapest fix is.
Quote drafting from history
Given an RFQ with part number, material, quantity and process, the agent finds similar past quotes and the actual hours booked on completed jobs, then drafts a quote with estimated operations and a note on where the estimate is thin.
Purchase expediting
For POs past their promised date and tied to a job that is scheduled to start, the agent drafts a vendor email asking for a firm date. A buyer reviews and sends it. Replies are summarised back onto the job.
Quote-to-job follow-up
Open quotes older than a set age are grouped by customer. The agent drafts a follow-up that cites the quoted lead time and any material price changes since the quote date.
Actual vs estimated costing review
After a job closes, an agent compares estimated and actual hours and material by operation and flags the operations where the estimator is consistently low, so quoting rates can be corrected.
Shipping and invoicing hold list
Finds jobs that are complete on the floor but not shipped, or shipped but not invoiced, and lists the blocker for each one.
ECI JobBOSS2 integration surface
- The JobBOSS2 database is Microsoft SQL Server. Tables commonly seen include Job, Job_Operation, Material_Req, Delivery, Quote, PO_Header and PO_Detail, Work_Center, Customer and Employee, but exact names and columns vary by version, so inspect your own schema before building tools.
- A read-only SQL login (db_datareader on a restricted set of views) is the simplest safe base for agent read tools. Prefer creating your own views that join and rename what the agent needs.
- Newer JobBOSS2 releases and the cloud edition expose an API (REST style). Check with ECI which endpoints and scopes your subscription includes before you design write paths around it.
- Writing directly to JobBOSS2 tables with SQL is a bad idea: the application maintains status flags, costing roll-ups and sequence numbers that raw inserts will not update. Write through the application, the API, or a staged import.
- Reports built in Crystal Reports or SSRS against the same database are a good spec for what the agent should be able to reproduce.
How it works
- 1
Pick two or three narrow jobs
Start with late-job triage and PO expediting. Narrow scope makes evaluation easy: you can compare the agent's list to what your scheduler would have produced.
- 2
Build read-only views
Create SQL views such as open jobs with remaining hours, material shortages by job, and overdue POs with linked jobs. Grant the agent login SELECT on those views only.
- 3
Wrap the views as tools
Each tool has a name, typed parameters and a row limit. Examples: get_job(job_number), list_late_jobs(days), get_work_center_load(week), find_similar_quotes(part, material).
- 4
Choose where the model runs
A hosted API is fine for non-sensitive shops. For ITAR or customer-NDA work, serve an open-weight model on a GPU server on your network so prompts and rows never leave.
- 5
Add a drafting layer, not a write layer
The agent produces drafts: an email, a quote worksheet, a PO suggestion. A person reviews and enters or approves it in JobBOSS2 or through the API.
- 6
Log everything
Store each run: goal, tool calls, returned row counts, final output, who approved. This is how you debug a wrong answer and how you show an auditor what the agent touched.
- 7
Evaluate on last quarter
Replay old dates. Did the agent flag the jobs that actually shipped late? Tune the tools and prompts before letting anyone rely on it.
Example flows
Morning late-job brief
Trigger: Scheduled 6:30 AM on weekdays.
- Call list_late_jobs for the next 10 working days.
- For each job, call get_work_center_load and the material shortage tool.
- Rank by customer priority and days of slip.
- Write a one-page brief with the reason and suggested action per job.
Result: The scheduler starts the day with a prioritised list instead of building it from three screens.
Vendor date chase
Trigger: A PO line is 3 days past its promised date and its job starts within a week.
- Look up the PO, vendor contact and the job that consumes the material.
- Draft an email stating the PO number, quantity and the need date.
- Queue it for the buyer to approve.
- On the vendor reply, extract the new date and propose the delivery date update.
Result: The buyer approves two actions instead of researching and writing both.
Keeping data on-prem
Most JobBOSS2 shops already keep SQL Server on a local server. Keep the agent next to it: a small Linux or Windows host running the tool service, with an open-weight model served by vLLM or Ollama on a GPU workstation or server in the same network segment. The agent login is read-only, the tool service is the only thing that can reach the database, and outbound internet access can be blocked entirely. For shops under export control rules this keeps part numbers, drawings references and customer names inside your boundary, and your compliance team still decides whether the setup meets its obligations.
Security checklist
- Use a dedicated SQL login with SELECT on named views only. No table-level access and no write permissions.
- Restrict the tool service to the internal network and require authentication per user, so results respect who is asking.
- Mask or exclude fields the agent does not need, such as customer pricing for users without that role.
- Require human approval before any email is sent or any transaction is created.
- Keep an immutable run log with the tool calls and outputs for audit.
Ways to get it done
Use the vendor's own AI features if any
Effort: Days to evaluate
If ECI ships an assistant that covers your first use case, try it first. It will be simpler than anything custom.
Build in-house
Effort: 4 to 10 weeks for a first agent
Works if you have a developer comfortable with SQL Server and Python. The tool layer is modest; evaluation and guardrails take most of the time.
Work with a partner such as Netray
Effort: Typically a few weeks for a scoped pilot
Useful when you want the agents on-prem with open models, and a JobBOSS2 reseller or consultant can validate the data model with us.
Pitfalls
- !Letting the agent query raw tables without views, which leads to wrong joins and silently wrong totals.
- !Trusting remaining-hours numbers when shop floor time reporting is late or incomplete. Check data freshness first.
- !Building write access before the read agents are trusted.
- !Ignoring multi-company or multi-site setups, where the same job number can exist in separate databases.
- !Skipping the evaluation replay, then discovering the agent ranks by due date only and ignores customer priority.
Frequently asked questions
Can an AI agent write jobs or POs directly into JobBOSS2?
It can, through a supported API or import path, but you should not start there. Begin with read-only agents that produce drafts, and add write-back one transaction type at a time with a person approving each one. Direct SQL writes are risky because the application maintains calculated fields.
Do I need the cloud edition for AI agents?
No. On-prem SQL Server editions work well because you can read through views. The cloud edition may limit direct database access, in which case you rely on the API or scheduled exports that ECI supports.
How is an agent different from a Power BI dashboard?
A dashboard shows numbers you chose in advance. An agent investigates: it follows a late job to its missing material to the PO to the vendor, and writes up the answer. They complement each other, and many shops want both.
Which model should we use?
For structured tool use over your own data, a mid-size open-weight model such as Qwen, Llama or gpt-oss class often works and runs on one or two GPUs. If data can leave your network, a hosted model is simpler. Test on your own questions before choosing.
What does a first pilot cost in effort?
A scoped pilot with one or two agents, read-only views and a draft-only output is typically a matter of weeks, not months. Most of that time goes into data checks and evaluation rather than model work.
Want AI agents working on your ECI JobBOSS2?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment