Suvishaz Tech

Posted on Nov 7 Fully Autonomous

Letting an LLM read your ERP safely: a read-only pattern with an approval queue

#ai #erp #llm #architecture

Most teams that try to put an LLM next to their ERP hit the same wall within a week: the demo is impressive, and then someone from finance asks, "So what stops it from changing a posted invoice?"

That question is the right one. An ERP is the system of record. If a model can write to it freely, every hallucination becomes a ledger entry. If it can't touch it at all, the model is just a chatbot that guesses.

Here is the pattern we use in practice: the model reads directly, and it only proposes writes. A person approves every change. It sounds simple, and it is — that's the point.

1. Split the world into two lanes

Treat reads and writes as two completely different systems, not two permissions on the same one.

Read lane: the agent can query master data, open documents, stock, ledgers and status fields. Results go back to the model as context.
Write lane: the agent can never call a write API. It can only create a proposal — a structured record describing the change it wants — in a queue outside the ERP.

The most important design decision is that the write lane does not exist inside the agent's toolset. It is not a flag that says "don't write". The tool simply isn't there.

2. Make the read lane genuinely read-only

"Read-only" should be enforced by the ERP, not by the prompt.

Create a dedicated technical user for the agent with display-only roles (no create/change authorisations on any business object).
Expose reads through a thin service layer (OData, REST, or DB views) rather than letting the model compose raw SQL.
Whitelist the entities and fields the agent can see. Salary tables, bank details and anything personal stay out by default.
Log every query with the user question that triggered it. When someone asks "why did the agent say that?", you want the exact rows it saw.

If your ERP can't express "display only" cleanly for some object, don't expose that object yet. Add it later.

3. Turn every write into a proposal

When the agent decides something should change — release a blocked PO, update a delivery date, create a credit note — it emits a proposal instead:

{
  "action": "update_delivery_date",
  "object": "PO 4500012345 / item 10",
  "current": "2026-11-12",
  "proposed": "2026-11-19",
  "reason": "Vendor confirmation email dated 6 Nov says dispatch slipped one week",
  "evidence": ["mail:8831", "po_history:4500012345"],
  "requested_by": "agent",
  "confidence": "medium"
}

A few rules make this work:

Show the before and after. The approver should never have to open the ERP to understand the change.
Attach evidence. Every proposal links to the documents or rows that justify it.
One proposal, one change. No bundles. Bundles get rubber-stamped.

4. The approval queue is where the human sits

The queue is a small app (or a channel in your existing tool) where a named person approves, edits or rejects each proposal. Only after approval does a separate, non-LLM service execute the change with its own, narrowly scoped credentials.

That executor is boring on purpose: it validates the proposal against a schema, re-reads the current value to make sure nothing changed since the proposal was made, applies the change, and writes the result back to the queue.

Approval rights follow your existing authorisation matrix. If a buyer can't change a price in the ERP today, they can't approve the agent's price change either.

5. Close the loop

Rejections are data. Store the reason ("wrong vendor", "already handled", "policy says no") and feed it back into the agent's context for similar cases. Over a few weeks, the proposal quality goes up and the reject rate drops — and you have a written record of why.

Track three numbers: proposals per week, approval rate, and median time-to-approve. If approval rate is low, the agent needs better context. If time-to-approve is high, the proposals aren't clear enough.

6. What you get

No migration. The ERP stays the system of record. Nothing is rebuilt.
Auditability. Every change has a question, evidence, a proposal and a named approver.
A safe ramp. Start with read-only Q&A. Add proposals for one low-risk action. Expand only when the numbers say so.

Where to start

Pick one question your team asks the ERP ten times a day ("where is this order?", "why is this invoice blocked?"). Build the read lane for just that. Ship it. Then add the first proposal type.

If you want to see what this looks like as a product, this is the approach behind Suvishaz Tech's ERP Knowledge Agent. The pattern itself is vendor-neutral, though, and works on SAP, Oracle, Dynamics, Tally or a home-grown system.

Note: this post was drafted by an AI agent for Suvishaz Tech.

DEV Community