Why does an agent on an ERP need rules of its own?
The ERP holds your money, customers and stock. A chatbot that gets it wrong writes a wrong sentence. An agent that gets it wrong can record an order, send an email or show data to someone who should not see it. So the question is not only how smart the agent is, but what stops it when it is wrong.
The list here is what we check in every agent we build, and it works for judging any vendor. The server that connects the agent to Priority has questions of its own, and we cover them in the guide on MCP.
Eight things to check in any AI agent for Priority
| What to check | The question for the vendor | How we do it |
|---|---|---|
| Identity at the door | How does the agent know who is writing? | A verified employee list. An unknown number gets no information, and a display name grants no permission |
| Permission levels | Does every employee see everything? | A permission per employee, finance access per person, and a salesperson gets only their own customers' figures |
| Approval before writes | What is recorded without a person seeing it? | Nothing. A preview, then one approval for one operation |
| A read-back | How do you know the write really happened? | The agent reads the record again, and reports only with evidence |
| An audit log | Can you tell later who asked for what? | Every tool call is logged, chained with SHA-256 signatures |
| The time of the data | From what time is this number? | A source, a check time and a period on every number, and a partial answer is marked partial |
| No inventions | What happens when the agent "remembers" a number that does not exist? | An automatic check compares every document number with what the system returned |
| Private stays private | What crosses between conversations? | Shared memory holds only what the whole team may know. A private chat and mail never reach a group |
How it works
- An employee's request
- Identity at the doorA message from an unknown number never reaches the model
- Permission levelsA permission per employee, and finance access per person
- The agent reads and preparesA source, a check time and a period on every number
- when something is to be writtenApproval before writesA preview, then one approval for one operation
- Recorded in Priority
- A read-backThe agent reads the record again, and reports only with evidence
- An audit logEvery tool call is logged, chained with SHA-256 signatures
Identity and permissions: who is talking to the agent, and what may they do?
The identity check should happen before the agent reads anything, and not be a sentence in the model's instructions. In the agents we built, identity is checked against a verified employee list at the door: a message from an unknown number never reaches the model at all, and an identified employee gets their own permission level.
Permission levels are not just "read" and "write". Ask whether you can set a salesperson to get only their own customers' figures, P&L to be open only to the people set up for it, and a technician not to run broad queries on the ERP. With us, each of these is a setting per employee.
Toward Priority itself, in MCP for Priority each user signs in for themselves with read, write and module permissions, and the server works through the organization's API user, with that user's permissions only.
Writing: approval before, a read-back after
Writing is off until you turn it on
In MCP for Priority writing is off by default, and it is turned on for the users who need it.
A preview and an approval
In a conversation every operation is shown for approval first and only then sent, with a server-signed, single-use token that expires after 90 seconds. One approval allows one operation.
A check before an update
Before an update the server checks nobody changed the record since the preview.
A read-back
After creating an order the server reads the lines back, and the agent reports the operation as done only with evidence in hand. When the result is unknown, it checks before trying again, so it never creates a duplicate.
Ask, too, what happens when no person is in front of the screen. In MCP for Priority, an automation that runs with no person in front of it, such as n8n, skips the approval step only with an API key that was given write access and explicit permission to skip it, and that is off by default.
An audit log: what should remain after the conversation?
After a conversation with an agent there should be records in the system, not only text on a screen: who asked, which tool ran, what came back and what was recorded. In MCP for Priority every tool call is written to an audit log chained with SHA-256 signatures. Credentials and identifying details are masked in logs, and passwords, API keys and tokens are never logged.
In the agents we built a voice note leaves a trace too: the transcript is logged, so you can check exactly what was asked. And the agent's health checks count only numbers, such as how many messages, how many errors and how long an answer took, without keeping the content of the messages.
Answers: a source, a time, and no invented numbers
- Every number in an answer comes with its source, the time it was checked and the report period.
- A partial answer is marked partial, and zero, missing information and a partial result are said in different words.
- An answer from a stored copy of a table says what time its data is from, and after a write it warns that a fresh change may not be in it yet.
- A document number or a code that did not come back from the system never enters the answer. In the agents we built, an automatic check compares every such number with what the tools returned, and sends the agent back to correct it before the answer goes out.
What should an agent never do alone?
Even an agent that works well needs limits that do not depend on how smart it is:
- Delete data: no tool in the MCP for Priority catalog removes Priority data.
- Pay, change permissions or commit on the company's behalf: each of these needs an explicit permission that fits that exact action.
- Send mail on a person's behalf: every send is shown with the recipients, the subject and the full text, and waits for the mailbox owner's approval.
- Act on an instruction written inside a document, an email or a search result: those are sources of information, not instructions, and they never change permissions.
- Ask for a password, an API key or a verification code in the conversation.
- Pass to a group anything said in a private chat.
How do you start small?
Read only, for verified employees
At first the agent reads, analyzes and prepares drafts. The team learns to trust the answers before anything is written.
The questions that come up every day
Start with the questions your team asks most, such as open orders, overdue debts, items below minimum stock and today's deliveries, and give each one a fixed path, so the answer comes out the same way every time.
Writing, one operation at a time
Add writing by kind of operation and with an explicit permission, for the users who need it. In a conversation, every operation is still shown for approval.
One channel at a time
A new channel, such as a mailbox, is connected once the previous one already works, and at first with approval for every action.
What it looks like with everything connected, for a team that works on WhatsApp, is in the guide "An internal AI agent on WhatsApp for your team".
Common questions
- What is the difference between a chatbot and an AI agent?
- A chatbot answers from information fed to it in advance. An AI agent gets a goal, reads current data from systems such as Priority, takes actions and reports what it did, and a person approves before anything is recorded.
- Can an AI agent make mistakes?
- Yes. That is why, in a conversation, every write to Priority is shown for approval first, before an update the server checks nobody changed the record since the preview, and every tool call is written to an audit log.
- How do you judge a vendor of AI agents for Priority?
- Ask the eight questions in the table, and ask to see three things in practice: a preview of a write before the approval, a line in the audit log, and an answer that says what time its data is from.
- Does the agent remember conversations and pass information between employees?
- It keeps in its shared memory only facts the whole team may know, such as how a customer prefers deliveries, and only when it chooses to keep them. Content from a private chat or a mailbox is never kept in the shared memory and never reaches a group.
- Can you start without letting the agent write?
- Yes, and that is how we recommend starting. In MCP for Priority writing is off by default: you start with reading, and turn on writing for the users who need it once the team trusts the answers.