Agents + approval gates
AI Agents for ERP, Running On-Prem
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.
- ERP
- SAP S/4HANA, Infor LN, Infor SyteLine, Oracle EBS, Dynamics 365
- Industries
- Manufacturing, Aerospace, Defense, Electronics
- Written for
- CIO
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.
What usually gets in the way
The problems we hear most from cio teams running SAP S/4HANA.
"Agent" is used to describe both a chatbot and an autonomous writer
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
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
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
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
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.
Where AI earns its place in SAP S/4HANA
Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.
Read-only exception triage
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.
Touches: 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
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.
Touches: 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
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.
Touches: 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
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.
Touches: 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
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.
Touches: 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
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.
Touches: 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
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.
Touches: 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
Reference architecture
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.
- 1
ERP connectors and tool definitions
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.
- 2
Data and semantic layer
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.
- 3
Model serving
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.
- 4
Agent orchestration and approval gates
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.
- 5
Governance and audit
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.
Integration notes for your ERP team
- 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.
Deployment options
Air-gapped on-prem
Defense, aerospace, and electronics manufacturers with export-controlled data or strict flow-down requirements
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
Manufacturers wanting managed infrastructure without a public multi-tenant AI service
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
Organizations that want to move faster on low-risk, non-sensitive agent use cases while keeping sensitive workflows fully on-prem
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 and data control
How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.
ITAR / EAR (export-controlled data touched by an agent)
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.
CMMC 2.0 / NIST SP 800-171 (CUI accessed 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.
SOX and financial controls (for agents touching financial transactions)
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.
Internal change management / IT governance
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.
Where Netray fits
ERPray
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
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.
How an engagement runs
Phase 1 . 2-3 weeks
Discovery
- -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
Phase 2 . 6-8 weeks
Pilot
- -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
Phase 3 . ongoing
Production
- -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
Phase 4 . ongoing
Scale
- -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
Questions to ask any vendor, including us
A short list that separates real SAP S/4HANA AI work from a chatbot demo.
- 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?
Frequently asked questions
What is the difference between an AI agent and a chatbot for ERP?
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?
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?
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?
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?
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?
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?
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.
Related guides
A Private LLM Grounded on Your ERP Data
How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.
ITAR + on-prem AIITAR-Compliant AI for ERP Technical Data
How to add generative AI to your ERP without creating a deemed export under ITAR. On-prem architecture patterns an Empowered Official can sign off on.
ERP AI Buyer GuideHow to Choose an ERP AI Implementation Partner
A CIO checklist for picking an ERP AI implementation partner: the architecture questions to ask, red flags, pricing models, and what to demand in the SOW.
On-prem AI, any ERP, A&DOn-Prem AI for ERP in Aerospace, Defense, and Electronics Manufacturing
A hub guide to on-prem AI across SAP, Infor LN, Costpoint, IFS, and Oracle EBS for aerospace, defense, and electronics manufacturers under ITAR, CMMC, and AS9100.
PO follow-up that does not wait on a personAI Purchase Order Automation: Supplier Follow-Up and Expedite Without a Buyer Chasing Email
AI drafts routine PO confirmation and expedite messages from open ERP order data, with a buyer approving every message and change before it goes out.
Ask your ERP anythingNatural Language Query for ERP Data: Ask SAP, Infor, or Oracle a Question in Plain English
See how natural language query over SAP, Infor, Oracle, and NetSuite data works: grounded text-to-SQL, role-based permissions, and a visible audit trail.
Plan it with numbers
AI Agent Security Review Checklist
A 30-point security review for AI agents that can call tools and write to business systems, covering identity, permissions, prompt injection, data handling, and audit.
Free ToolAI Agent Use Case Prioritizer
Answer ten questions about a candidate process and get a prioritization score that tells you whether it deserves an AI agent pilot now, later, or never.
Free ToolAI Governance Maturity Assessment
Score your AI governance across policy, inventory, risk classification, data handling, monitoring, and executive oversight, and get a banded improvement roadmap.
GuideAI Agent Architecture for Enterprise ERP Systems
Design AI agent architectures for ERP systems with multi-agent orchestration, tool-use patterns, memory management, and enterprise integration strategies.
GuideAI Agent Orchestration Across ERP Workflows
AI agent orchestration coordinates multiple AI agents across ERP workflows like order-to-cash and procure-to-pay, with guardrails, audit trails, and ROI.
GuideHuman-in-the-Loop Design for ERP AI
Human-in-the-loop design for ERP AI: where to place approvals, confidence thresholds, and audit trails so agents act safely inside SyteLine, LN, and M3.
Talk it through with an engineer who knows SAP S/4HANA
Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.