AI Agents in ERP: Give the Buyer a Better Draft, Not a Blank Cheque

At Monday’s purchasing meeting, fourteen suggested orders wait for review. One line says “12 boxes”; the buyer expected 12 pieces. A box holds 12 pieces, so the proposal would buy 144. The scene is fictional, but the decision is real: should software make a useful suggestion, or be allowed to turn that suggestion into a supplier commitment?

The buyer wants help finding shortages and preparing paperwork. She does not want to supervise every keystroke, and she cannot afford to discover an error after dispatch. A sensible AI-agent rollout starts by defining that boundary—not by asking whether a demo can complete an impressive task.

This is the first article in our operations-AI series. Part 2 covers MCP connections; part 3 covers approval and audit controls. Here we decide which work is worth delegating and how to prove the result.

Look past the word “agent”

An AI agent can choose and call tools while working toward a goal: look up an order, inspect a receipt, create a draft or request another step. “Copilot” and “agent” are product labels with overlapping meanings. Inspect the tools and execution rights, rather than assuming one name only talks and another acts.

Use ordinary rules for arithmetic, validation and repeatable transactions. A language model may help interpret a messy supplier message or explain an exception; it should not be the sole calculator or authority deciding what the buyer may purchase. If a fixed workflow already solves the problem well, adding an agent may add cost without useful flexibility.

Wrong answers can already cause loss or expose data. A read-only assistant that reveals another branch’s prices or invents a payment status is not harmless. Write access adds further consequences, but reading needs controls too.

Choose an operating mode for each task

Classify the exact task by data sensitivity, business impact, external commitments, volume and recovery—not just whether an “undo” button exists. Reserving the last item may be technically reversible but still deny a genuine buyer a purchase. Thousands of small actions can also create a large exposure.

The modes below are an operating policy to agree with your owners, not legal risk categories or an automatic ladder. Success at drafting does not authorise sending.

Mode	Useful work	Required boundary
Read and explain	Permitted stock or invoice evidence	Record/field scope, freshness, output privacy
Prepare	Draft PO, reminder or match exception	No hidden downstream effects; human review
Execute within policy	One explicitly permitted, bounded action	Current authorisation, exact approval where required, duplicate protection
Hold and escalate	Ambiguity, denied access, unapproved commitment	Stop that action; route to an accountable person

Follow the purchase order all the way through

For the fictional buyer, start with one supplier and one product family. Check SKU/variant identifiers, approved suppliers, purchase units, currency, lead times, usable stock, existing commitments and incoming receipts. One product can have several suppliers and pack sizes; do not force every item into a single-supplier rule.

The tool returns dated evidence and explicit quantities: 12 pieces = 1 box, not 12 boxes. Calculations and quantity limits are validated by business logic. Ambiguous conversion, stale stock or an unresolved supplier record creates an exception for the buyer; the model does not invent the missing value.

A draft must really be inert. Test whether saving it reserves budget, triggers a supplier email or starts another workflow. The review shows supplier, destination, items, quantities/units, price, currency, tax, total and source timestamps. An authorised buyer approves that exact version; changing a meaningful field or letting evidence expire requires a fresh check and, where needed, renewed approval.

Execution checks current permissions and business constraints again. A purchase order exists only when the system confirms its committed result. If sending to the supplier is a separate step, record its separate outcome. Creating a document, sending it and supplier acceptance are not interchangeable states.

Keep permission outside the conversation

For an interactive request, effective access is the intersection of the requesting user’s rights, the agent/tool scope and current business policy. Apply it to records and fields, not merely menu visibility. Check again on every tool call. A question about one store must not search another store’s private documents or cached answers.

An unattended job needs its own narrowly scoped service identity, named owner and expiry/review—not a shared administrator account or the unexplained inheritance of a human session. Keep prompts, retrieved files, outputs, logs and model-provider access within the same data-handling policy. Check retention, region, subprocessors and training terms; self-hosting the ERP alone does not keep an external model call local.

Supplier PDFs, customer messages and web pages are evidence, not new authorisation. A sentence inside an invoice cannot grant permission to change bank details. OWASP describes over-broad tools, permissions and autonomy as excessive agency. Enforce limits in the application, not only in a prompt.

Start where review has a clear purpose

Stock questions: return permitted stock by location/status with the evidence time. Distinguish available-to-promise from physical on-hand, and an estimate from an allocation.

Purchase proposals: prepare a bounded draft and explain the inputs. Keep quantities, supplier commitments and release with the approved workflow.

Invoice exceptions: compare invoice, purchase order and receipt under agreed tolerances, including partial receipts, currency and tax. Flag uncertain matches; do not silently pay or post them.

Overdue reminders: verify due date, dispute and recent payment first. Draft to the correct authorised recipient. Acceptance of earlier drafts alone does not justify unattended sending; outreach rules and escalation limits still apply.

Product copy: draft from verified attributes. Editors check language, ingredient/safety statements, sizing and warranty terms. Translation should preserve the claim, not strengthen it.

Payroll release, supplier-bank changes, refunds, catalogue-wide pricing, deletion and accounting corrections deserve explicit control design. Some businesses already automate routine ledger postings deterministically with approvals and audit evidence. The issue is not a blanket ban on automation; it is giving a probabilistic agent open-ended authority over consequential work.

Test the awkward cases before the happy path becomes routine

Ask the vendor to demonstrate a denied cross-store query, a malicious instruction embedded in a supplier document, a changed order after approval and an expired permission. A convincing refusal message is insufficient if the underlying data or action already escaped.

Simulate a timeout after the order was created but before the acknowledgement arrived. Query the existing operation/reference before retrying. Use duplicate protection, bounded exponential backoff with jitter for retryable failures, a retry budget and an owner for unresolved outcomes. Do not blindly replay an uncertain purchase, payment or refund. Invalid requests and permission denials require correction, not repeated retries.

Set per-operation and aggregate limits for value, records, tool calls, runtime and provider spend. Test stopping the run: it should prevent new work while preserving in-flight outcomes for reconciliation. Record actor, delegated scope, source references, proposed change, approval/version, tool outcome and operation ID. Restrict and redact the log; do not copy every customer file into it.

Ask for a concise evidence-based explanation, not hidden model chain-of-thought. Verify who can view/export the evidence, how long it is kept and how incidents are investigated. The NIST AI Risk Management Framework is a useful voluntary organising reference, not a product certificate.

Measure a pilot without calling every accepted draft correct

Use 30/60/90 days as review windows if useful, not automatic permission upgrades. Begin with scoped lookups, then supervised drafts. A narrow write action is a separate decision with failure tests and an accountable owner. Stay draft-only if that is the best economic outcome.

Consider an illustrative 200-case review. Staff accept 160 drafts unchanged, edit 30 and reject 10: an 80% unchanged-acceptance rate. An independent sample of 40 accepted drafts finds two material errors, or 5% of that sample. That does not estimate every case precisely, and acceptance alone plainly does not prove correctness. Include difficult cases, languages, abstentions and rare high-impact failures.

The time model below uses invented measurements for the same 200 cases. Compare like-for-like work; review, exception handling and ongoing support count too.

For the same 200 cases	Minutes
Baseline: 200 × 6	1,200
AI-assisted review: 200 × 3	600
Additional exception handling	120
Setup/support allocated to this pilot	90
Total assisted effort	810
Net capacity released	390 (6.5 hours)

At an assumed labour value of 24/hour, 6.5 hours is 156 of capacity. Subtract assumed model/tool charges of 40: allocated benefit 116 before other costs. These are currency-neutral teaching units, not a guaranteed return or cash saving; wages may be unchanged. Track turnaround, verified errors, data incidents and customer/supplier outcomes alongside time. Zero incidents in a small pilot does not prove zero risk.

Return to Monday with a smaller promise

The buyer now receives fourteen reviewable proposals. The box/piece discrepancy is an exception, not an order automatically emailed while everyone sleeps. She corrects the source conversion, reruns the affected proposal and checks the result. A cleaner master record reduces one failure mode; it does not prove the next run cannot fail.

Before choosing a product, ask for a demonstration with your permissions and awkward cases. The StoreConsole Intelligence tour is a way to inspect the product, not evidence that every workflow or connector is enabled. Confirm the actual draft, approval, execution and recovery behaviour in your installation.

For customer-facing AI, plan clear disclosure and check applicable rules. EU AI Act Article 50 includes direct-interaction transparency duties with defined scope and exceptions; it is not a universal rule for every internal ERP action. Employment, credit and other sensitive decisions need their own assessment.

The useful outcome is modest and valuable: fewer routine searches and better prepared decisions, with evidence that the buyer can trust and authority she can still control.

Reviewed 5 November 2026. Anichur Rahaman is the creator of StoreConsole. The purchasing scene, pilot counts and cost model are illustrative.