ERP Assistant Agent: Specification

What this agent is

An assistant that lets someone ask a question of ERP data in plain language — "which customers have invoices more than 30 days overdue" — and get back a figure, the exact filters that produced it, and a link to the underlying records.

It is read-only. Every query runs under the asking user's own permissions, and it answers only from a curated set of queries that a person defined. It does not write free-form SQL against your production database, and it does not create or amend documents.

Why it is deliberately narrow

The tempting design is to point a model at the schema and let it generate queries. It demonstrates beautifully. In production it produces two failures that are hard to recover from: a query that is syntactically fine and semantically wrong, delivered as a confident number, and a query expensive enough to degrade the system for everyone else using it.

An ERP is also a permissions boundary before it is a database. Margin, payroll, supplier pricing and pipeline all sit in the same schema as things everyone may see. An assistant that queries as a service account and filters the rows afterwards has replaced your permission model with a prompt — which is the single change most likely to turn a useful tool into an incident.

Oversight and failure modes

Definitions are the project, not the model. "Revenue" means at least three things in most companies — booked, invoiced, recognised — and they differ by material amounts. Until finance has written down which one the assistant answers with, it will produce numbers that disagree with the finance report, finance will be right, and the assistant will be switched off. Do the definitions first. They are the deliverable that outlives the tool.

A number without its filters is a rumour. Every answer shows the period, the entity, the status filter and the currency it used. Without that, two people ask the same question in different words, get different numbers, and nobody can establish which one is correct.

The permission model must not be re-implemented. Queries execute as the asking user, through the same permission layer the Desk uses. Any design that queries as a service account and then hides rows has moved access control into the part of the system least able to enforce it — and least able to prove it did.

Expensive questions are a production risk. "Show me everything for the last five years" is one sentence to type. Row caps, query cost limits and a read replica where volume justifies one are part of the build, not a later optimisation.

Ambiguity is a refusal, not a guess. "Last quarter" against a non-calendar fiscal year, a customer name matching four records, a metric with no agreed definition — each is a clarifying question. A wrong number delivered confidently costs far more than a question asked.

The unanswerable questions are a roadmap. Everything that does not map to a curated query goes into a backlog. That list is the most honest report-request queue your organisation will ever have, because people asked for what they actually wanted rather than for what they assumed was possible.

Writes are a separate decision. Creating or amending documents through a conversational interface is a different risk class needing a different approval design. Do not fold it into a read assistant because the interface makes it look like a small addition.

What it might save

This depends on how much of your reporting is currently ad hoc, so treat it as an estimate. Where a finance or operations team fields a steady stream of one-off "can you pull me…" requests, plan for something in the range of three to eight hours a week of report-pulling returned to the team that currently absorbs it, plus a much shorter path to an answer for the people asking.

The larger effect is harder to price honestly: questions that never get asked because the queue is too long start getting asked, and some of them matter.