How to add AI agents to Global Shop Solutions
Short answer
Add AI agents to Global Shop Solutions by exposing a small set of read-only tools (jobs, purchase orders, inventory, routings, schedule) over its database views or web services, then letting a model plan multi-step work against those tools. Writes go through a queue that a planner or buyer approves. The model can run on-prem so job and customer data never leaves the building.
Global Shop Solutions is usually bought by job shops and make-to-order manufacturers that live inside jobs, routings, shop-floor data collection and a finite-capacity schedule. The people running it are planners, buyers and estimators who spend their day cross-checking three or four screens to answer one question: will this job ship on time, and what do I have to chase to make it so.
That cross-checking is exactly what an AI agent does well. An agent is not a chatbot that answers a question once. It is a worker that is given a goal (for example, find every open job at risk of missing its promise date and tell me why), calls tools to read the ERP, reasons over the results, and produces a worklist or a draft transaction for a human to approve.
The honest caveat is that Global Shop Solutions has its own roadmap for built-in analytics and automation, and a lot of teams will get value from that first. Agents earn their place when the question spans systems (ERP plus a supplier email plus a quality record) or when the data must stay on-prem and a hosted assistant is not acceptable.
What teams use it for
Late-job triage
Each morning an agent reads open jobs, remaining operations and the schedule, then ranks the jobs most likely to slip and names the blocker: missing material, a busy work center, or an outside-process vendor that has not confirmed.
Purchase expedite drafts
For jobs short on material, the agent finds the open purchase order lines, checks promise dates against the job start, and drafts a short expedite email per supplier for the buyer to send.
Quote-to-history comparison
Given a drawing number and quantity, the agent pulls actual hours and material cost from prior completed jobs on similar parts and proposes a quote basis, flagging where history is thin.
Inventory exception review
The agent scans negative or stale on-hand records, unissued job material and open receipts that never closed, and produces a cleanup list grouped by who can fix each item.
Customer status replies
A customer service agent drafts order status answers from job progress and ship dates, using the customer's own PO number, and leaves the send decision to a person.
Global Shop Solutions integration surface
- Underlying database: many Global Shop Solutions installs sit on an Actian Zen (Pervasive PSQL) style database reachable by ODBC, while newer or hosted releases may differ. Confirm your version and whether direct reads are supported by your agreement.
- Vendor-provided web services or API: recent releases expose documented services for common objects. Check your version's API guide and licensing for what is read-only versus transactional.
- Reporting layer: saved reports and exports (including Crystal-style reports and spreadsheet exports) can feed an agent when direct access is not allowed.
- Shop floor data collection: labor, quantity complete and scrap postings are the freshest signal for job progress and should be read, not written, by the agent.
- Business objects an agent needs: customers, sales orders, jobs and routings, purchase orders, inventory locations, work centers and the scheduling output.
How it works
- 1
Pick three read-only questions first
Do not start with a general assistant. Choose late jobs, open PO lines against job demand and inventory exceptions. Each is a clear goal with a checkable answer.
- 2
Build a read layer
Create views or a small service that returns clean, named records (job, operation, PO line, on-hand). Hide raw table names from the model and apply the same company and site filters your users have.
- 3
Define tools, not prompts
Expose functions such as get_open_jobs, get_job_routing, get_po_lines_for_job and get_on_hand. Typed arguments, bounded result sizes, and no free-form SQL.
- 4
Add a planner loop
A model chooses which tool to call next, reads the result and stops when it has an answer. Log every call so a planner can see exactly what was queried.
- 5
Route writes through a proposal queue
When the agent wants to change a promise date or create a requisition, it writes a proposal record with evidence. A named approver releases it, and only then does a service account post to the ERP.
- 6
Evaluate on real history
Replay last month's late jobs and score whether the agent would have flagged them and named the right cause before widening scope.
Example flows
Morning at-risk job report
Trigger: Scheduled at 6:30 am before the production meeting.
- Agent lists open jobs due in the next ten working days.
- For each, it reads remaining operations and compares scheduled finish to the customer promise date.
- It checks material shortages and outside-process lines for the worst offenders.
- It groups causes: material, capacity, outside vendor, engineering hold.
Result: A one-page ranked list in the planner's inbox, each line with the reason and the record to open.
Shortage to expedite
Trigger: A planner clicks Expedite on a shortage in the report.
- Agent finds open PO lines for the part and their promise dates.
- It checks whether an alternate approved vendor or stocked substitute exists.
- It drafts the supplier email and a proposed promise date change.
- The buyer edits and approves; only then is the PO note updated.
Result: The supplier gets a specific request and the ERP record shows what was asked and when.
Keeping data on-prem
Most Global Shop Solutions customers are on-prem or in a private hosted environment and many serve aerospace, defense or contract manufacturing customers with flow-down requirements. Run the agent entirely inside that boundary: an open-weight model (Llama, Qwen or Mistral class) served by vLLM or Ollama on a local GPU server, the tool layer on a small internal VM that talks to the database or API over the LAN, and logs kept locally. Nothing about jobs, customers or drawings needs to reach a public AI endpoint. If your hosted ERP agreement restricts database access, use the vendor API or scheduled exports as the only read path.
Security checklist
- Use a dedicated read-only database login or API account for the agent, scoped to the sites and companies it needs.
- Never give the model raw SQL access. Expose parameterised tools with row limits.
- Keep a full audit trail of each tool call, its arguments and the answer, retained per your quality system.
- Gate every write behind named human approval and post it with a separate service account.
- For controlled technical data, keep prompts and retrieved records on infrastructure you control and apply your own access rules.
Ways to get it done
Use vendor-supplied analytics and automation first
Effort: Days to weeks of configuration, no custom code.
Good when the question stays inside one module and the reporting you already have is close to enough.
Build a small agent in-house
Effort: Roughly one to three months for a hardened first agent including evaluation.
Good if you have a developer comfortable with the database or API and a clear first use case.
Work with a partner such as Netray
Effort: A scoped pilot of a few weeks, then extend by use case.
Good when you want an on-prem model, a vetted tool layer and approval workflow without building the plumbing.
Pitfalls
- !Letting the agent read tables directly: column meanings and status codes differ by version and customisation, so wrap them in named views first.
- !Treating promise date and scheduled date as the same field. Agents confuse them unless the tool output labels each clearly.
- !Skipping evaluation. An agent that sounds confident but misses a third of late jobs is worse than a plain report.
- !Writing to the ERP before reads are trusted. Start with drafts and notes, not transactions.
- !Ignoring licensing. Confirm what your agreement allows for direct database access and third-party API use.
Frequently asked questions
Does Global Shop Solutions have a native AI agent feature?
The vendor has been adding analytics and automation capabilities over time, and the exact set depends on your version. Check your release notes. A custom agent is mainly justified when you need cross-system reasoning or an on-prem model the vendor feature does not provide.
Can an agent update jobs or purchase orders automatically?
It can, but you should not start there. Begin with read-only analysis and drafts, add a proposal queue with named approvers, and only automate a specific low-risk write once it has a track record in your own data.
Which model should we run on-prem?
A mid-size open-weight instruction model with reliable tool calling is enough for most planning and buying tasks. Pick it by testing on your own late-job history, not by benchmark reputation, and size the GPU for your concurrent users.
How is this different from a Power BI dashboard?
A dashboard shows you numbers you already decided to look at. An agent chases the cause across several records, drafts the next action and can include unstructured inputs such as supplier emails. They complement each other.
How long until the first useful agent?
With a clean read layer and one focused question like at-risk jobs, a working pilot in a few weeks is realistic. The longer part is evaluation and getting planners to trust the output.
More for Global Shop Solutions
Want AI agents working on your Global Shop Solutions?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment