# How to add AI agents to Ignition (MES/SCADA) > Source: https://netray.co/integrations/ignition-ai-agents > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## Short answer Add AI agents to Ignition by giving them a narrow tool layer over the Gateway: tag reads, historian queries, alarm journal lookups and named queries against the MES database. Keep the agent read-only at first, route any tag write or work order change through an operator approval, and run the model next to the Gateway so plant data stays on site. ## System Inductive Automation Ignition (MES/SCADA) ## Capability ai-agents ## Intro Ignition sits in an unusual place. It is a SCADA platform, a historian front end, an alarm system and, with the right modules and projects, the MES layer that tells people what to run next. That means the data an agent needs is already in one place: live tags, historized values, alarm events, downtime codes and production counts. What is missing is something that reads across them and does the legwork a controls engineer or shift supervisor does by hand. Most Ignition teams do not want a chatbot floating above the plant. They want a worker that notices a line is running slow, pulls the last four hours of the relevant tags, checks the alarm journal, compares against the last good run of that product, and posts a short, sourced summary to the supervisor. They also want it to stop short of changing a setpoint without a human saying yes. This page covers the realistic way to build that on Ignition: what the Gateway exposes, how to wrap it as agent tools, where the approval step belongs, and what to do when the plant network is segmented and nothing can reach the internet. ## Use Cases ### Downtime triage **Description:** When a line stops, the agent reads the alarm journal, the last state of the key tags and the operator downtime reason, then drafts a likely cause and links the three historian trends worth opening first. ### Shift handover summary **Description:** At shift end the agent queries production counts, reject counts and downtime events from the MES tables and writes a handover note grouped by line, so the incoming supervisor does not start from a blank screen. ### Alarm flood analysis **Description:** After a noisy period the agent groups alarms by source and priority, spots chattering points, and proposes deadband or delay changes for an engineer to review. It never edits the alarm configuration itself. ### Quality drift watcher **Description:** The agent compares live process tags against the recipe or product limits held in your SQL tables and flags slow drift before it becomes a reject, with the evidence attached. ### Work order exception handling **Description:** When a production count falls behind schedule, the agent drafts a note to planning and, if your ERP is connected, prepares an expedite or reschedule request that waits for approval. ### Tag and screen discovery **Description:** New engineers ask the agent where a value comes from. It walks the tag provider browse tree and project resources to answer, which shortens the usual hunt through Designer. ## System Surface Tag system: tag providers, UDTs and tag paths, readable through system.tag.readBlocking and system.tag.browse in Gateway scripting. This is the live-state tool for an agent. Historian: tag history is stored in your SQL database, with partitioned tables and a tag lookup table. The Tag Historian query functions (for example system.tag.queryTagHistory) return aggregated values without touching raw tables. Alarm system: the alarm journal and active alarm queries (system.alarm.queryStatus and queryJournal) give an agent the event trail. Table and function names vary by Ignition version, so confirm against your 8.1 or 8.3 manual. WebDev module: lets you define doGet and doPost endpoints inside a project that run Jython on the Gateway. This is the most common way to publish a small, controlled HTTP API for an agent. Named queries and database connections: parameterised SQL against your MES schema, with permissions set per Gateway database connection. Safer than free-form SQL from a model. Gateway network, MQTT and Sparkplug modules from third parties, and OPC UA are other paths in, but for agents the WebDev plus named query route is usually the least invasive. ## How It Works ### Decide the tool list before the model **Detail:** Write down five to ten operations: read tag, query history, list active alarms, get production summary, get downtime events, find work order. Each becomes one tool with fixed parameters. ### Expose tools through WebDev or a service account **Detail:** Create a dedicated Ignition project with WebDev resources that call system.tag and named queries. Protect them with an API token or a service identity mapped to a restricted role, not an admin account. ### Add a thin agent runtime next to the Gateway **Detail:** Run the agent loop on a server in the same network zone. It calls your WebDev endpoints, keeps a step log, and enforces limits such as maximum tags per call and maximum history window. ### Ground answers in returned data **Detail:** Require every claim to cite the tag path, time range or alarm ID that supports it. If a tool returns nothing, the agent says so instead of guessing. ### Put approval in front of every write **Detail:** Writes such as system.tag.writeBlocking or a database update go to a pending queue shown in a Perspective view. An operator or engineer approves, and the Gateway performs the write under their identity. ### Pilot on one line with shadow output **Detail:** For two weeks the agent posts findings only to a test channel. Compare them with what the supervisor actually did, then widen scope. ## Example Flows ### Line slow-down investigation **Trigger:** Production rate tag drops below 85 percent of target for ten minutes. **Steps:** - Gateway script or alarm pipeline calls the agent endpoint with the line ID. - Agent reads current values for speed, temperature and feed tags and queries the previous four hours of history. - Agent lists active and recently cleared alarms for that area. - Agent compares against the last run of the same product code from the MES table. **Result:** Supervisor receives a short message with a probable cause, the three trends to open, and the evidence used, within about a minute. ### Missed schedule to expedite request **Trigger:** Produced quantity trails the work order plan at the half-way mark. **Steps:** - Agent reads the work order and counts from the MES schema. - Agent checks recent downtime events to explain the gap. - Agent drafts a reschedule note and, if the ERP connector exists, prepares an update. - A planner approves or edits the request in a Perspective screen. **Result:** The ERP update is made only after a named person approves it, and the log shows why. ## On Prem Ignition is very often deployed on isolated or lightly connected plant networks, and that suits a local agent. Run an open-weight model with vLLM or Ollama on a GPU server in the plant or site data center, call it from the agent runtime over the internal network, and keep the Gateway talking only to that server. Retrieval over manuals, SOPs and past downtime notes can live in a local vector store. Nothing about tags, recipes or product data needs to leave the site, which matters for regulated and defense customers. Place the agent in a DMZ or the level above the control network and allow only the specific WebDev ports, in line with the Purdue-style segmentation most plants already have. ## Security - Use a dedicated Ignition role and service identity for the agent, limited to read on specific tag providers and named queries. - Never expose raw SQL execution or system.tag.writeBlocking as a generic tool; wrap each allowed action with fixed parameters. - Log every tool call, argument and result to an audit table with the approving user for writes. - Keep the agent out of the control network. Reach the Gateway through a firewalled path and rate limit it so a loop cannot flood the historian. - Treat free-text from operators and alarm descriptions as untrusted input to the model, since it can contain instructions. ## Options ### Ignition scripting plus a hosted LLM API **Fit:** Fast proof of concept on a non-sensitive line where cloud access is allowed. **Effort:** Two to four weeks for a single read-only workflow. ### Build in-house on WebDev with an open-weight model **Fit:** Teams with a strong controls and software group who want to own the code. **Effort:** Six to twelve weeks including approvals, logging and testing. ### Partner build such as Netray **Fit:** Plants that want an on-prem agent layer across Ignition and the ERP, with a review process built in. **Effort:** Scoped per workflow, typically a pilot first, then expansion line by line. ## Pitfalls - Giving the agent broad tag write access in the first release. Start read-only and add one approved write at a time. - Pulling long historian windows at raw resolution, which can load the database. Use aggregation and cap the window. - Letting the model invent tag paths. Provide a searchable tag catalog and validate every path before reading. - Ignoring version differences between 8.1 and 8.3 in scripting and module names; test on a staging Gateway first. - No clear owner for false alarms from the agent, which erodes operator trust quickly. ## Faq ### Can an AI agent run directly inside the Ignition Gateway? **Answer:** Not usefully. The Gateway runs Jython scripting and is not a place to host model inference. The common pattern is a separate agent service that calls Gateway endpoints you define, such as WebDev resources, and returns results to Perspective or messaging. ### Should the agent write to tags or setpoints? **Answer:** Not at the start. Reads, summaries and drafted recommendations carry little risk. If you later allow writes, limit them to specific tags, require approval by an authorised user, and log the change under that person so the audit trail stays honest. ### Does Ignition already include AI features? **Answer:** Inductive Automation and third parties have been adding analytics and AI related tooling, and what exists depends on your version and modules. Check the current release notes. A custom agent still makes sense when you need your own tools, data sources and on-prem model. ### How does this connect to the ERP? **Answer:** Through the ERP API or a staging table the Gateway already writes to. The agent calls an ERP read tool for orders and items and a gated write tool for updates. See the related ERP AI page for the pattern. ### What data volume can the agent handle? **Answer:** The agent should never read raw bulk data. It asks for aggregates, specific tags and short windows, and the Gateway or database does the heavy work. A well scoped tool set keeps responses small and responses fast. ## Search terms ignition ai agents, ai agent for ignition scada, inductive automation ai agent, ignition mes ai, add ai to ignition, ignition scada llm, ignition webdev ai agent, on-prem ai for ignition, ignition alarm analysis ai, ignition downtime ai --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json