# How to add AI agents to SYSPRO > Source: https://netray.co/integrations/syspro-ai-agents > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## Short answer Add AI agents to SYSPRO by exposing a small set of read tools over e.NET business objects and a read-only SQL Server login, then letting a model plan multi-step work such as MRP exception triage or PO expediting. Anything that posts a transaction goes through a human approval step and a narrow e.NET write tool. ## System SYSPRO ## Capability ai-agents ## Intro Most SYSPRO shops run a mature SQL Server database, a few hundred custom reports and a team of planners who know exactly which exceptions matter. What they lack is time. Every morning someone opens the MRP output, checks open purchase orders, reads supplier emails and decides what to expedite. That is a multi-step job with rules in people's heads, which is the shape of work an agent handles well. An agent is different from a chatbot. A chatbot answers a question. An agent is given a goal such as 'review all late purchase orders for the next ten days', calls several tools in sequence, reasons about the results and produces a proposed action list. In SYSPRO terms it queries purchase order lines, joins them to requirements and stock, checks supplier history and drafts the expedite emails or the due date changes. The safe pattern is the same on every ERP: agents read freely inside the permissions of a service operator, and propose writes that a person approves. SYSPRO's operator and role model makes this practical because every e.NET call is made as a named operator with its own security profile. ## Use Cases ### MRP exception triage **Description:** The agent reads the MRP suggestions and pegging, groups them by buyer and urgency, flags the ones caused by a single late job or a changed forecast, and proposes reschedule or cancel messages for the planner to confirm. ### Late PO expediting **Description:** For each open purchase order line past or near its due date, the agent checks the linked sales orders and jobs, ranks by customer impact and drafts a supplier chase email with the specific line, quantity and needed date. ### Job shortage chasing **Description:** Before a work order is released, the agent compares the job's bill of materials against warehouse stock and open receipts and tells the supervisor exactly which components will cause a stoppage and when they are due. ### Quote-to-order checking **Description:** On a new sales order the agent checks customer credit status, price list consistency and stock availability, then lists anything a CSR should resolve before the order is confirmed. ### Non-conformance drafting **Description:** When goods receipt inspection fails, the agent pulls the supplier, lot, purchase order and job context and drafts the NCR text for a quality engineer to review and submit. ### Month-end sweep **Description:** A scheduled agent scans for GRNs not invoiced, stale suspense items and jobs with variance outliers, and produces a short exceptions pack for the controller. ## System Surface SYSPRO e.NET Solutions: the business object layer that takes XML in and returns XML out. Query objects return data, transaction objects post it. Object names such as INVQRY (inventory query) and PORQRY (purchase order query) have been stable for years, but available objects and XML parameters vary by version, so confirm against your installed e.NET documentation. e.NET access paths: depending on version this is the COM/.NET component, the e.NET WCF service, or the newer REST-style web services layer. Pick the one your site has licensed and supported, and wrap it in one client class so the agent never sees the transport. SQL Server company databases: each SYSPRO company is a separate database with tables such as InvMaster, InvWarehouse, PorMasterHdr, PorMasterDetail, SorMaster, SorDetail, WipMaster and BomStructure. A read-only login is the fastest route for analytic reads, with the caveat that table and column names should be verified for your version. Operators and security: e.NET logon uses a SYSPRO operator and optionally a company password, so a dedicated 'AI service' operator with restricted program access is the correct identity for the agent. Add-ins and triggers: SYSPRO supports custom forms, user-defined fields and trigger or workflow style extensions, which can be used to post events to a queue when a purchase order or job changes. ## How It Works ### Define the agent's job narrowly **Detail:** Pick one workflow, such as late PO triage. Write down the inputs, the decision rules a buyer applies and the output format. Agents fail when the goal is 'help with purchasing'. ### Build a read tool layer **Detail:** Create 6 to 10 functions: get_open_po_lines, get_requirements_for_item, get_supplier_history, get_stock_by_warehouse, get_job_shortages. Back each one with e.NET queries or parameterised SQL against a read-only login, and return compact JSON. ### Create a service operator **Detail:** In SYSPRO create an operator limited to the programs the tools need. Log all calls with the operator, tool name, parameters and row counts. ### Choose and host the model **Detail:** Use an open-weight model served on your own hardware if data must stay on site, or a cloud API for non-sensitive pilots. Tool calling quality matters more than raw size. ### Run the loop with limits **Detail:** Cap steps, rows per tool and runtime. The agent plans, calls tools, reads results and writes a proposal, never an unbounded crawl of SalesOrder tables. ### Add an approval gate for writes **Detail:** A proposed PO due date change or a note is stored as a pending action. A buyer approves in a small web page or a Teams card, then a single narrow e.NET write tool posts it under the buyer's context or the service operator. ### Evaluate on history **Detail:** Replay last month's exceptions through the agent and compare its recommendations against what planners actually did before you turn on any live suggestions. ## Example Flows ### Morning late-PO review **Trigger:** A scheduled run at 6:30 each weekday. **Steps:** - Fetch open PO lines due within ten days or already overdue. - For each line look up the linked sales demand and job requirements. - Rank lines by the earliest customer promise date they affect. - Look up the supplier's last six receipts for typical lateness. - Draft one chase email per supplier listing only the lines that matter. **Result:** Buyers open a ranked list with drafted emails instead of building the list by hand, and nothing is sent without their click. ### Job release readiness check **Trigger:** A supervisor asks which jobs can be released tomorrow. **Steps:** - Query jobs with scheduled start dates in the next day. - Explode each job's bill of materials and compare against warehouse stock. - Add open receipts with due dates before the job start. - Flag jobs with a shortage and name the component and expected date. **Result:** A short readiness table with reasons, so shortages are known before a job is pulled to the floor. ## On Prem SYSPRO is frequently installed on premises with SQL Server on the same network as the application server, and an agent can live entirely beside it. Run the tool service on a small Windows or Linux host that can reach the e.NET service and the SQL Server instance, and serve an open-weight model with vLLM or Ollama on a GPU server in the same segment. The model never needs outbound internet, prompts and tool results stay inside the firewall, and the audit log lives in your own database. If the site is air-gapped, ship model weights and packages in through a controlled transfer and keep the tool service version pinned. ## Security - Use a dedicated read-oriented SYSPRO operator and a separate SQL login with SELECT on named tables only, never the system administrator account. - Treat text from supplier emails and free-text fields as untrusted input to the model, and never let it choose tool names or SQL. - Keep write tools separate from read tools, require a human approval record for each write, and log operator, payload and result. - Mask or exclude fields the task does not need, such as bank details in ApSupplier or personnel data. - Rate-limit tools and cap result sizes so a looping agent cannot run heavy queries during production hours. ## Options ### Use SYSPRO's own AI and analytics features **Fit:** Good when your version includes assistant or insight features that cover the workflow and you want vendor support. **Effort:** Low, mostly configuration and licensing. ### Build in-house with e.NET and an open model **Fit:** Good if you have a developer who knows SYSPRO business objects and you want full control of one or two agents. **Effort:** Roughly 4 to 10 weeks for a first read-heavy agent with approval gates. ### Work with a partner such as Netray **Fit:** Good for on-prem or regulated sites that want private models, a tested tool layer and an evaluation harness without building it from scratch. **Effort:** A scoped pilot in weeks, then extension to more workflows. ## Pitfalls - Giving the agent raw SQL generation against the live database leads to slow queries and wrong joins, so expose fixed parameterised tools. - Assuming e.NET object XML is identical across versions causes silent failures after an upgrade, so keep a contract test per object. - Posting transactions directly from the model output skips validation SYSPRO would normally enforce on screen, so always post through a validated tool. - Ignoring multi-company setups mixes data across company databases, so pass the company ID in every tool call. - Judging success by demos instead of replaying historical exceptions hides the cases where the agent is confidently wrong. ## Faq ### Can an AI agent post transactions into SYSPRO? **Answer:** Yes technically, through e.NET transaction business objects, but it should not post unsupervised. Keep writes behind an approval step, use a narrow tool per transaction type and let SYSPRO's own validation reject bad input. Start read-only for several weeks before enabling any posting. ### Do I need to expose the SQL Server database to the AI? **Answer:** No. The model should never connect to the database. Your tool service connects with a read-only login and returns limited results. The model only sees the JSON your tools return, which keeps access scoped and auditable. ### Which SYSPRO version do I need? **Answer:** Agents can work with any version that exposes e.NET or a readable SQL Server schema. Newer versions with REST-style web services are easier to wrap. Older versions work through the COM or WCF layer. Check your installed e.NET documentation for exact objects. ### Does the agent respect SYSPRO security? **Answer:** Only if you design it to. Use a dedicated operator with limited program access for e.NET calls, and enforce row and field limits in the tool layer. SQL reads bypass SYSPRO operator security, so scope that login tightly. ### Is this better than building reports in SYSPRO Reporting Services? **Answer:** Reports are better for fixed, repeatable output. Agents are better for judgement across several data sources, such as combining POs, jobs, stock and supplier history. Many sites keep both and let the agent draw on the same data. ## Search terms syspro ai agents, ai agents for syspro erp, syspro agentic ai, syspro mrp automation ai, syspro purchase order automation, syspro e.net ai integration, add ai to syspro, syspro ai on-premise, syspro llm integration --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json