The bottom line
Agentic AI moves the ERP from 'chat' to 'do' — from a passive assistant to autonomous agents that plan and execute work. Most leaders are familiar with chatbots but lack a structural understanding of what an agent actually is or how to govern one.
A working primer for the leaders who sit between the whiteboard and the codebase — informed enough to make the call on agentic ERP, without needing to write the agent yourself.
The views below are my own, drawn from vendor documentation, public roadmaps, and my work in the ERP ecosystem. Each vendor would frame parts of this differently, and I welcome the conversation.
The gap between familiarity and understanding
There is a well-documented trap in how people judge their own knowledge: we mistake familiarity with a technology for a structural understanding of it. Most executives have now typed a prompt into a chatbot and watched it draft an email. That fluency is real, but it describes the previous era of AI, not the one arriving in the ERP.
The shift is from chat to do — from a passive assistant that waits for a prompt and returns text, to an autonomous system that is handed a goal and executes the steps to reach it with minimal supervision. "Reconcile the Q2 shipping variance" is not a question to answer; it is a job to complete, across the ledger, the document registry, and the bank feed. Understanding what changes underneath that sentence is the difference between buying agentic ERP well and buying it on faith.
What an agent actually is: four pillars
Strip away the marketing and a functioning enterprise agent rests on four components. Knowing them lets you interrogate any vendor's pitch.
- A reasoning and planning engine. This is the part that decomposes a high-level goal into an ordered sequence of steps — the layer that turns "resolve this variance" into "pull the ledger entry, find the matching invoice, check the tax treatment, draft the correction." It is the planner, not the muscle.
- A toolbox. Reasoning is useless without hands. The agent calls functions and APIs — increasingly through open standards like the Model Context Protocol — emitting a structured payload that a deterministic system can execute. This is the bridge between probabilistic thought and a real transaction.
- Memory and context. Short-term memory holds the task in flight; long-term memory holds corporate policy, vendor history, and the pattern of how similar exceptions were resolved before. Without it, every run starts from zero and the agent has no institutional knowledge to draw on.
- Orchestration. Serious work is rarely one agent. A supervisor coordinates specialists — a ledger agent, a payables agent, a logistics agent — each narrow, each accountable, collaborating on a shared goal.
Embedded or custom: where to start
The strategic question most leaders reach quickly is whether to build agents or buy them inside the platform you already run. In practice the fastest return comes from embedded, vendor-native agents — and the reason is grounding.
An agent built into your SaaS platform inherits its semantic layer — the map of how business objects relate. It already knows that a purchase order connects to a goods receipt connects to a vendor invoice, because the platform's own knowledge graph encodes those relationships. A custom agent has to be taught all of that through connectors you build and maintain. Embedded agents skip that tax. The pragmatic path is hybrid — native agents for core ERP workflows, custom ones only where your process is genuinely differentiated — but you start where the grounding is free.
Why the ERP is the ideal proving ground
Modern cloud ERPs are powerful and, for the people who run them, high-friction: dense screens, specialized training, and a steady stream of exceptions handled by hand. That friction is exactly what agents are built to absorb. Three use cases show the pattern.
The continuous close. Instead of a monthly scramble, a ledger agent watches the general ledger in real time. It detects a supplier account mismatch, searches the document registry, queries the bank feed, identifies a misapplied tax discount, drafts the correcting journal entry, and composes the note to the supplier — then routes all of it for one-click approval. The close stops being an event and becomes a background condition.
Multi-system exception handling. A shipment is stuck behind a billing block because proof of delivery never posted. An exception agent queries the third-party logistics API, finds a name-spelling discrepancy against the delivery record, checks the standard operating procedure, validates the delivery, clears the block, and releases the invoice — a resolution that used to mean a person toggling between three systems, compressed into minutes.
Migration and testing. Agents read legacy code, refactor incompatibilities, generate risk-based test scenarios and mock data, run the tests, read the error logs, and propose configuration fixes — turning months of manual scripting into a supervised, iterative loop.
The insight that makes it safe: two layers, not one
The reasonable objection is unpredictability — how do you let a probabilistic model touch the general ledger? The answer is that a well-built agent separates thinking from doing.
The probabilistic layer — the model — does what models are good at: reading a messy PDF, interpreting an unstructured email, planning a sequence, inferring intent. It proposes. The deterministic layer — your APIs, database rules, permissions, and workflow engine — disposes. It enforces the guardrails the model cannot override: user permissions, spending limits, approved-vendor lists. If the model proposes a transaction the rules forbid, the deterministic layer blocks it, regardless of how confident the model sounds. The intelligence is flexible; the execution is bounded. That separation is what makes autonomy auditable rather than reckless.
Where the return actually shows up
The quantitative case — working capital, cycle times, operating cost — will vary by estate and should be proven on your own numbers, not a vendor's slide. The qualitative shifts are more durable:
- Data access is democratized. A leader asks a question in plain language; the agent constructs the query, pulls the data, and returns a narrative answer. The report queue shortens.
- Period-end stress dissolves. Continuous reconciliation replaces the quarterly fire drill.
- Traceability becomes total. Every agent action is logged step by step — an immutable footprint that makes an audit a query rather than a round of interviews.
- Institutional knowledge stops walking out the door. Procedures codified into the agent's memory survive turnover; the process runs the same on the new hire's first week as on the veteran's last.
A roadmap that earns trust in stages
The failure mode is switching autonomy on everywhere at once. The disciplined path is phased, and every phase maps to a native configuration you already have.
- Phase 1 — Read-only co-pilot (weeks 1–4). The agent runs in sidebar or read-only mode: it summarizes, recommends, explains its reasoning, but changes nothing. The goal is to validate the reasoning and build user confidence with zero risk to data integrity.
- Phase 2 — Draft-and-approve (weeks 4–10). The agent gains write-draft permissions. It monitors exceptions, gathers the evidence, structures the correction, and routes a completed draft to a human approval queue. The human keeps absolute control over every state change; the agent just removes the assembly work.
- Phase 3 — Human-on-the-loop (week 10+). For routine, low-risk processes, the agent executes unattended inside hard metadata boundaries — variance under a set threshold, supplier on the approved list, model confidence above a defined bar. Anything outside those bounds falls back to the Phase 2 queue. Touchless, but fenced.
Three governance imperatives run underneath all of it. Provision each agent as a virtual employee with its own service account and least-privilege access inside your identity system. Set deterministic guardrails the model cannot argue its way past — currency limits, vendor allow-lists, geographic blocks. And log every write the agent makes, so the transaction footprint stays clean and defensible.
The reframe
Agentic AI turns the SaaS ERP from a static database of record into an active participant in execution. The technology is genuinely new; the discipline that governs it is not. Start with conversational assistance, graduate to drafted work, and enable autonomy only where the guardrails are provably tight. The enterprises that win the next few years will not be the ones with the most agents. They will be the ones who understood — structurally, not just by familiarity — what those agents were doing, and built the controls and the people to let them.
Analysis by Ravi Madhavan, offered as one practitioner's primer on agentic ERP for the leaders who make the call without writing the code. Originally published on LinkedIn. Substantive disagreement or alternative reads welcome. Allari runs the ERP support layer for JDE, SAP, Oracle Fusion, and NetSuite estates — inventorying the repeatable manual work these agents are built to absorb and finding where it can be automated.
