# AI Agents for ERP, Running On-Prem > Source: https://netray.co/erp-ai/erp-ai-agents-on-prem > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## Short answer An AI agent for ERP is a model given a defined set of tools, read queries, draft actions, and specific write actions gated by human approval, that it can call against your ERP to complete a task like drafting a PO follow-up or triaging a scheduling exception. Run on-prem, the model and its tool access stay inside your network, and the key design decision is not which model to use, it is which actions the agent is allowed to take on its own versus which require a person to approve first. Most production deployments start read-only and add specific, narrow write actions only after the read-only version has proven reliable. ## Kind use-case ## Erp Family multi-erp ## Erp Products - SAP S/4HANA - Infor LN - Infor SyteLine - Oracle EBS - Dynamics 365 ## Industries - Manufacturing - Aerospace - Defense - Electronics ## Region Global ## Persona CIO ## Eyebrow Agents + approval gates ## Intro Every ERP vendor now uses the word 'agent' for something, from a chatbot that answers questions to a workflow that can post a transaction on its own. For a CIO evaluating this for a manufacturing ERP environment, the distinction that actually matters is not the marketing term, it is the specific list of actions the agent can take, how it decides to take them, and what stops it from taking the wrong one. A useful mental model is three tiers of capability. Tier one is read and summarize: the agent queries the ERP and reports back, no data changes. Tier two is draft and recommend: the agent prepares an action, a PO follow-up email, a reorder suggestion, a draft NCR, but a person has to approve it before it takes effect. Tier three is autonomous write: the agent changes something in the ERP without a person in the loop first. Almost every credible production deployment in a manufacturing ERP today lives in tiers one and two; tier three is reserved for narrowly scoped, low-risk, high-volume actions where the cost of an occasional mistake is genuinely low. On-prem matters here for a reason beyond data residency: an agent that can query and, eventually, act on your ERP is effectively a new class of privileged account. Running the model and its tool-calling logic on infrastructure you control means you can audit every query and action it takes with the same rigor you would apply to a service account, rather than trusting a third-party vendor's internal logging. This page is the pillar for how Netray approaches agentic AI on ERP: what agents can safely do today, how approval gates are designed so they do not become a rubber stamp, and how to sequence a rollout from read-only to draft-and-approve to, eventually and selectively, narrow autonomous actions. ## Pain Points ### "Agent" is used to describe both a chatbot and an autonomous writer **Detail:** Vendor marketing rarely distinguishes between a read-only Q&A assistant and something that can actually change a record, which makes it hard for a CIO to evaluate real risk from a product deck. ### Approval gates are often designed as a rubber stamp **Detail:** A poorly designed approval step just shows a person a wall of text to click 'approve' on, which trains staff to approve without reading, defeating the purpose of the gate. ### Write access is requested before read-only value is proven **Detail:** Vendors and internal teams alike often want to jump straight to autonomous actions because that is where the efficiency story is best, before establishing that the agent's judgment is reliable on read-only tasks. ### Audit logging is an afterthought **Detail:** Many agent deployments log the final action taken but not the intermediate reasoning or the data the agent read to get there, making it hard to explain a bad outcome after the fact. ### No clear owner for agent behavior when something goes wrong **Detail:** When an agent-drafted action turns out to be wrong, it is often unclear whether that is an IT problem, a business-process problem, or a vendor problem, which slows down the fix. ## Use Cases ### Read-only exception triage **Description:** An agent reviews open orders, scheduling boards, or inventory positions on a schedule and produces a prioritized list of exceptions worth a person's attention, with no ability to change anything. **Erp Objects:** Open Orders, Scheduling records, Inventory Balances **Outcome:** gives planners a prioritized worklist instead of a raw exception report they have to interpret themselves ### Draft-and-approve PO follow-up **Description:** The agent drafts a supplier follow-up email for a late purchase order, but the email sits in a queue for a buyer to approve, edit, or reject before it sends. **Erp Objects:** Purchase Orders, Vendor records, Receiving status **Outcome:** cuts drafting time to near zero while keeping a human decision before anything reaches a supplier ### Draft NCR or CAPA entry **Description:** Given a description of an inspection finding, the agent drafts a structured nonconformance record for a quality engineer to review and finalize, never submitting it as an official record on its own. **Erp Objects:** NCR/CAPA records, Part Master **Outcome:** speeds up documentation while preserving the human sign-off a quality system requires ### Narrow autonomous action: reorder point replenishment for C-class items **Description:** For a defined, low-risk category of items (low unit cost, no lead-time volatility, no export control), the agent is allowed to generate and release a routine reorder against a pre-approved supplier and quantity range without a per-transaction approval. **Erp Objects:** Reorder Point records, Approved Supplier, Purchase Order creation **Outcome:** removes a high-volume, low-risk task from a planner's queue, reserved for the narrowest, best-understood cases ### Scheduled compliance and audit-prep summaries **Description:** An agent runs on a schedule ahead of an internal or external audit, compiling open corrective actions, overdue document reviews, or access control exceptions into a single prep list. **Erp Objects:** Compliance and audit-tracking records across the ERP and connected quality/security systems **Outcome:** replaces a manual pre-audit compilation with a generated draft a compliance lead still reviews ### Escalation routing **Description:** When the agent's read-only analysis flags something above a defined risk or dollar threshold, it routes the item to a specific person rather than either acting on it or silently reporting it in a list nobody checks. **Erp Objects:** Order/exception data plus a defined escalation ruleset **Outcome:** makes sure high-stakes exceptions reach a person directly instead of getting buried in a report ### Post-hoc action review sampling **Description:** A second, independent agent process periodically samples a percentage of approved agent-drafted actions and checks them against outcome data (did the supplier actually respond, was the NCR root cause later confirmed) to measure real-world accuracy over time. **Erp Objects:** Historical drafted actions, outcome/status fields **Outcome:** gives the CIO an evidence-based accuracy measure instead of relying on anecdote to decide whether to expand agent scope ## Architecture **Overview:** The architecture separates what the agent can see (read scope), what it can propose (draft scope), and what it can do without approval (write scope), with each scope enforced at the tool-calling layer, not just by instructing the model to behave. **Layers:** #### ERP connectors and tool definitions **Detail:** Each tool the agent can call (a specific query, a specific draft action, a specific narrow write action) is individually defined and permissioned, rather than giving the agent a general-purpose API key. #### Data and semantic layer **Detail:** A mapping from ERP objects to concepts the agent reasons about, kept consistent across read and write tools so the agent's understanding of 'this purchase order' is the same object the write tool would act on. #### Model serving **Detail:** An open-weight model served on customer infrastructure, sized to the expected agent call volume, which is typically far lower than interactive chat volume since agents run on schedules or triggers. #### Agent orchestration and approval gates **Detail:** The layer that sequences read, then draft, then (where allowed) write actions, and routes any draft action through an approval queue before it can execute, logging the full chain. #### Governance and audit **Detail:** Full logging of every tool call, the data read, the action drafted, who approved or rejected it, and the eventual outcome where measurable, kept as a queryable audit trail, not just application logs. ## Deployment Options ### Air-gapped on-prem **Fit:** Defense, aerospace, and electronics manufacturers with export-controlled data or strict flow-down requirements **Detail:** The model, orchestration layer, and all ERP connectors run inside the customer's network with no outbound path; agent tool calls never leave the boundary that already protects the ERP itself. ### Private sovereign cloud **Fit:** Manufacturers wanting managed infrastructure without a public multi-tenant AI service **Detail:** A single-tenant instance in the customer's chosen region, with the same tool-scoping and approval-gate design as the on-prem option, trading some infrastructure ownership for reduced operational burden. ### Hybrid by risk tier **Fit:** Organizations that want to move faster on low-risk, non-sensitive agent use cases while keeping sensitive workflows fully on-prem **Detail:** Read-only and draft-and-approve agents touching non-sensitive data can run in a lighter-weight environment, while any agent touching export-controlled, CUI, or safety-critical data stays on the fully on-prem deployment. ## Compliance ### Agent tool calls that read or draft against export-controlled records run on-prem with no external model API, and the audit log records exactly what was read and by which process, supporting a deemed-export risk review. **Framework:** ITAR / EAR (export-controlled data touched by an agent) ### An agent's tool access to CUI-containing ERP objects is scoped and logged the same way a human user's access would be, so it can be included in the same access control and audit evidence CMMC assessors expect. **Framework:** CMMC 2.0 / NIST SP 800-171 (CUI accessed by an agent) ### Any agent tool that could affect financial records is kept at the draft-and-approve tier at minimum, preserving the segregation of duties and human authorization controls SOX compliance already requires. **Framework:** SOX and financial controls (for agents touching financial transactions) ### Expanding an agent's scope from read-only to draft-and-approve to (rarely) narrow autonomous write follows the same change approval process as any other production system change, not a separate fast-tracked AI process. **Framework:** Internal change management / IT governance ## Integration Notes Each agent tool is defined as a specific, scoped function (e.g. 'draft_po_followup_email') rather than granting the agent a general database or API credential, so its blast radius is limited by design, not by instruction. Approval queues are built into the existing workflow tools staff already use (email, a task list, a dashboard) rather than a separate AI-only interface, to avoid creating a queue nobody checks. Agents that run on a schedule (nightly exception triage, weekly audit prep) are the easiest starting point because their output is naturally batched and reviewed, unlike a real-time chat interface. Narrow autonomous write actions, where they exist at all, are scoped to a specific, bounded category (a dollar threshold, an item class, a pre-approved supplier list) defined by the business owner, not by the AI implementation team. Audit logs capture the full tool-call chain, not just the final action, so a reviewer can see what the agent read and reasoned from, not only what it did. Rollout typically follows read-only, then draft-and-approve, then (selectively) narrow autonomous action, with each stage requiring a defined period of measured accuracy before advancing. ## Product Fit ### ERPray **Why:** ERPray's agents are read-only by default and show the underlying query, which fits the tier-one and tier-two model described here directly, for NetSuite, Infor SyteLine, M3, and LN. ### Custom build **Why:** Draft-and-approve or narrow autonomous write actions on ERPs outside ERPray's current connector list, or with bespoke approval workflows, are delivered as scoped custom agent builds with the same tiered design. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - Inventory of candidate agent use cases, each classified by risk tier (read-only, draft-and-approve, autonomous) - Review of existing approval workflows the agent should plug into rather than replace - A data handling and hosting decision (air-gapped, private cloud, hybrid) based on data sensitivity ### Pilot **Duration:** 6-8 weeks **Deliverables:** - One or two read-only or draft-and-approve agents deployed against a real, bounded workflow - Full audit logging in place from day one of the pilot - A defined accuracy measurement process against real outcomes, not just user satisfaction ### Production **Duration:** ongoing **Deliverables:** - Pilot agents rolled out to their full intended user base - Approval queues tuned based on real usage patterns (queue length, rejection rate) - A documented process for proposing and reviewing any expansion to autonomous write scope ### Scale **Duration:** ongoing **Deliverables:** - Additional agent use cases added following the same risk-tiered rollout - Post-hoc outcome sampling running continuously to catch accuracy drift - Periodic review of whether any draft-and-approve agent has earned a narrower, defined autonomous scope ## Buyer Questions - For each proposed agent, exactly which tools can it call, and what is the maximum damage one of those tools could do if used incorrectly? - Does the vendor default to draft-and-approve, or do they push straight to autonomous write actions? - What does the audit log actually capture: just the final action, or the full chain of what the agent read and reasoned from? - How is accuracy measured after deployment, and how often is it reviewed? - Who owns the decision to expand an agent's scope, and what evidence do they require first? - Can we see the exact prompt and tool definitions the agent uses, or is that a black box? - What happens if the agent's tool call fails partway through a multi-step action? - Does the approval interface show enough context that a person can genuinely evaluate the draft, or is it designed to be rubber-stamped? ## Faq ### What is the difference between an AI agent and a chatbot for ERP? **Answer:** A chatbot answers a question in a conversation. An agent can be given tools, specific queries or actions it is allowed to call against the ERP, and can chain several of them together to complete a task, like checking an order status and then drafting a follow-up email, without a person directing each step. ### Should an ERP AI agent be allowed to write data on its own? **Answer:** For most workflows, no, at least not initially. The safer default is read and draft, with a person approving any write. A small number of narrow, low-risk, high-volume actions (like routine C-class reordering within pre-approved limits) can eventually move to autonomous write once accuracy is proven, but this should be the exception, not the starting point. ### How do you keep an agent from making a costly mistake? **Answer:** Scope each tool narrowly so the agent cannot do more than the specific action it was built for, route anything above a read-only summary through a genuine approval step (not a rubber-stamp UI), and log the full reasoning chain so mistakes can be traced and the tool corrected, not just the individual action undone. ### Why does on-prem matter specifically for agents, more than for a Q&A chatbot? **Answer:** An agent with tool access to your ERP is effectively a new privileged account, even a read-only one has visibility a compromised or misconfigured process could exploit. Running it on infrastructure you control means the same access controls, monitoring, and audit standards you apply to any privileged account apply to the agent too. ### How long does it take to get from read-only to draft-and-approve? **Answer:** Most pilots run a read-only or draft-and-approve agent for six to eight weeks before expanding scope, specifically to gather real accuracy evidence rather than assuming the agent works because a demo looked good. The exact timeline depends on how much genuine usage volume the pilot workflow generates. ### Can we start with just one narrow use case instead of a big rollout? **Answer:** Yes, and that is the recommended path. A single well-scoped agent, like draft-and-approve PO follow-up emails, proves the approach on a real workflow with measurable outcomes before expanding to additional use cases or higher-risk tiers. ### What happens to agent access when an employee leaves or changes roles? **Answer:** Agent tool access should be tied to the same identity and role system that governs the underlying ERP access, so a role change or departure that revokes ERP access also revokes whatever agent capability was scoped to that role, rather than requiring a separate manual step. ## Search terms AI agents for ERP, on-prem AI agents, ERP AI agent approval gates, autonomous AI agents manufacturing, AI agent governance ERP, private AI agents ERP, ERP agent guardrails, AI agent audit trail, human in the loop AI ERP, AI agents manufacturing, on-prem AI for manufacturing, ERP agentic AI --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json