# How to add AI agents to Infor VISUAL > Source: https://netray.co/integrations/infor-visual-ai-agents > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## Short answer Add AI agents to Infor VISUAL by giving a language model a small set of audited tools: read-only queries against the VISUAL SQL Server database, and writes routed through the VISUAL API toolkit or a staging table after a person approves. Start with one narrow job, such as triaging late purchase orders, before adding anything that changes data. ## System Infor VISUAL ## Capability ai-agents ## Intro VISUAL (originally Visual Manufacturing from Lilly Software, now Infor VISUAL) is a job-shop and make-to-order system, often running on a single SQL Server box in the plant. Planners live in the Material Planning Window, the Shop Resource Manager and the Purchase Order Entry screens, and a lot of the real knowledge sits in people's heads and in spreadsheets built around those screens. An agent is different from a chatbot: it takes a goal, decides which lookups to run, and returns a worked answer or a proposed action. On VISUAL the interesting goals are the repetitive ones: chasing vendors for late POs, reviewing planned orders, checking whether a rush customer order can be covered, and drafting follow-ups. The honest constraint is that VISUAL was not designed with an event bus or a modern REST layer in every version. Most teams end up reading from the database and writing through the supported toolkit. That is workable, and it keeps the agent small and auditable. ## Use Cases ### Late purchase order chasing **Description:** Each morning the agent lists open PURC_ORDER_LINE rows past their desired receive date, groups by buyer, checks vendor history, and drafts a follow-up email for the buyer to send. ### Shortage triage before a work order releases **Description:** For a work order about to release, the agent walks the requirements, compares on-hand and on-order by part, and lists which materials block which operations, ranked by due date. ### Quote-to-order sanity check **Description:** When a customer order is entered, the agent compares the lines against the part master, lead times and the last few orders for that customer, and flags missing or odd data for review. ### Planned order review **Description:** The agent reads MRP planned orders, spots ones that look like noise from an out-of-date forecast or a bad lead time, and prepares a list for the planner to accept or cancel. ### Labor and WIP exception reports **Description:** It scans labor tickets for open tickets left running overnight or hours far outside the routing estimate and proposes corrections for a supervisor. ## System Surface The VISUAL database on Microsoft SQL Server. Core tables include PART, CUSTOMER_ORDER, CUST_ORDER_LINE, WORK_ORDER, OPERATION, REQUIREMENT, PURC_ORDER, PURC_ORDER_LINE, VENDOR, LABOR_TICKET and INVENTORY_TRANS. Exact columns vary by version, so confirm in your own schema. The Visual API toolkit (a COM-based library historically shipped with the product) for supported creation and update of business objects. Availability and naming depend on version, so check with Infor or your reseller. Infor ION and Infor OS connectivity on newer releases, where your VISUAL version supports ION messaging. Treat this as optional, not assumed. Crystal Reports and the Visual reporting layer, useful as a source of already-trusted business logic that you can reuse as agent tools. Database-side options such as read-only SQL logins, views that hide sensitive columns, and a separate staging table that a person-approved job later turns into real transactions. ## How It Works ### Pick one job and one success measure **Detail:** Choose something like late PO follow-up. Define what a good output looks like and who approves it. Avoid starting with anything that posts inventory or financial transactions. ### Create a read-only data path **Detail:** Add a SQL Server login with SELECT only on a set of views. Mask pay rates and cost fields the job does not need. Point the agent at a restored copy or a read replica if the production server is already busy. ### Write the tools, not free-form SQL **Detail:** Expose functions such as get_open_po_lines(vendor, days_late) and get_part_availability(part_id). The model picks tools and arguments; your code owns the SQL. This makes every answer traceable and avoids a model writing an expensive query. ### Add a proposal layer for writes **Detail:** When the agent wants to change something, it writes a row to a proposals table with the object, the change and its reasoning. A named user approves, and only then does a separate service apply it through the toolkit. ### Serve a model that fits your data rules **Detail:** Use a hosted API if policy allows, or an open-weight model on a local GPU server. Keep prompts free of data the task does not need. ### Log everything and review weekly **Detail:** Store the question, the tool calls, the rows returned and the final answer. Review a sample each week and tighten the tools where the agent wandered. ## Example Flows ### Morning late-PO digest **Trigger:** Scheduled job at 6:30 each weekday **Steps:** - Call get_open_po_lines for lines past desired receive date. - For each vendor, pull the last six receipts to estimate typical lateness. - Check whether the part is on a released work order short list. - Rank by production impact and draft a short email per vendor. - Post the digest to the buyer for review and send. **Result:** Buyers start the day with a ranked list and ready drafts instead of building the list by hand. ### Can we cover this rush order? **Trigger:** A sales user asks about a rush customer order line **Steps:** - Read the part, quantity and requested date. - Check on-hand, allocated and open supply by date. - Walk the routing for load on the constrained work centers. - Return a yes, no or maybe with the specific blocking materials or operations. **Result:** Sales gets a grounded answer with the numbers it was based on, and planning is only pulled in when the answer is maybe. ## On Prem Many VISUAL sites are fully on-prem on a SQL Server instance with no inbound internet, which suits an agent well. Run the tool service and an open-weight model (a Llama, Qwen, Mistral or gpt-oss class model served with vLLM or Ollama) on a GPU server in the same network, and let it query read-only views. Nothing leaves the plant, and the audit log lives next to the ERP. A single modest GPU is usually enough for tool-calling over structured data, though quality on long documents will depend on the model you choose. ## Security - Use a dedicated SQL login with SELECT on views only, never the application login. - Block write paths for the agent identity at the database level, not just in prompts. - Require named human approval before any change reaches the toolkit. - Log prompts, tool calls and returned rows with timestamps and user identity. - Mask or exclude cost, pay rate and customer pricing fields unless the job needs them. ## Options ### Build in-house with a tool-calling framework **Fit:** You have a developer who knows SQL Server and VISUAL data and wants full control. **Effort:** A few weeks for one narrow agent, plus ongoing tuning. ### Use Infor's own AI features where your edition has them **Fit:** You are on a current cloud-connected edition and the feature covers your use case. **Effort:** Configuration only, but scope is set by Infor and may not reach custom tables. ### Work with a partner such as Netray **Fit:** You want a tested tool layer, on-prem deployment and approval workflow without building the plumbing. **Effort:** Typically a scoped pilot first, then expansion by job. ## Pitfalls - Letting the model write raw SQL against production, which risks slow queries and wrong joins. - Assuming column names from another version of VISUAL; verify against your schema. - Writing around the toolkit with direct UPDATE statements, which can bypass business rules and break integrity. - Giving the agent too many tools at once so it picks poorly. - Skipping a baseline, so nobody can tell whether the agent saved time. ## Faq ### Can an AI agent post transactions in Infor VISUAL? **Answer:** It can propose them. The safer pattern is that the agent writes a proposal, a person approves it, and a separate service applies it through the supported toolkit. Direct database updates are a common source of corrupted records, so avoid them. ### Do I need to upgrade VISUAL first? **Answer:** Not usually. Read-only agents work against the SQL Server database on older versions too. Write-back options depend on what your version's toolkit supports, so check that before promising any automation. ### Which model should run the agent? **Answer:** Any model with reliable tool calling. Hosted APIs are fine if your policies allow business data to leave. For private plants, current open-weight models served locally work well for structured lookups. ### How is this different from a chatbot? **Answer:** A chatbot answers one question. An agent plans several lookups, combines the results, and can prepare an action for approval. That extra autonomy is why the tool layer and logging matter more. ### What is a sensible first agent? **Answer:** Late purchase order follow-up or shortage triage. Both are read-heavy, easy to verify against screens users already know, and carry little risk if the output is wrong. ## Search terms infor visual ai agents, ai agents for infor visual, infor visual manufacturing ai, visual erp ai automation, infor visual late po automation, add ai to infor visual, infor visual agentic ai, infor visual sql server ai, lilly visual manufacturing ai --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json