Can the agent write to our accounting or ERP?

Yes, through tools we write one by one, never through the database: each tool does one named action, create a credit note, send a reminder, with typed parameters. The model proposes the call; your server checks it, role, parameters against your data, limit, duplicate, and executes or refuses it. Above a limit, the action becomes an approval request on the phone of whoever can say yes.

What happens if the agent gets the amount or the customer wrong?

The gate stops it before writing: an amount that is not a line of the invoice is refused, an invoice that does not belong to the customer too, and a missing parameter makes the agent ask instead of guessing. For writes, a preview is shown before writing, and above the limit nothing is written without approval. Every refusal is in the log.

And if the same action is executed twice?

Every call carries an idempotency key; if the connection drops and the call is resent, the second execution returns the result of the first instead of creating a second credit note or resending twenty-three reminders. It is the same mechanism as for an offline app that resynchronises.

Does the agent have more rights than my employees?

Never. It inherits the role of the person talking to it, and additionally has a narrower “agent” role of its own: reading what is needed, writes under a limit, no deletion, no export. A sales rep cannot get it to do what they are not allowed to do themselves, and every action carries both names in the log.

How do we know what the agent did?

Through the log: one line per call, who asked, which tool, which parameters, the value before and after, and the result, executed, pending or refused. A weekly screen summarises what it did, what it was refused, what it cost, and the evaluation set is replayed at every change of tool or model.

How long to plug in an agent?

Eight weeks: one to write the requests and the tool list, one for the evaluation set, two for the read tools and the gate, during which the agent explains without writing, two to open the write tools one by one with their limits, two of pilot with the manager. The agent writes nothing before week five.

An AI agent in your back office and ERP in Algeria in 2027: the tools it is allowed to call, what it reads, what it writes under a limit, what needs an approval, and how every action leaves a trace

Short answer. An AI agent never has access to your database: it has access to tools, written one by one, each doing one named thing with typed parameters. The model proposes a call; your server executes it, after going through the same gate every time: does the role of whoever talks to the agent allow this tool, do the parameters exist in your data, is the amount under the limit, has this call already been executed. Reads pass alone; writes pass under a limit with a preview; above the limit they become an approval request on the phone of whoever can say yes; what the role does not have does not exist for the agent. Every call, executed or refused, has a log line. The agent never has more rights than the person it assists. Eight weeks, two of which it can write nothing.

This guide is for the manager who wants the AI to finally do something in their management software, the founder settled in France who wants to run their back office by messages, and the IT department that must say yes or no to plugging an agent into accounting. It does not repeat where to start or which uses pay, described in the guide on the agent in the company, nor how the agent lives on WhatsApp, described in the dedicated guide; it describes what is built between the model and your ERP, and extends our page on AI functions.

What the figures say

The model proposes, your code executes: the vendors themselves write it. Anthropic’s documentation describes tool use thus: the model “determines when to call a tool based on the user’s request and the tool’s description”, then “returns a structured call that your application runs”; your code does the operation and returns the result. OpenAI’s says the same: “when the model calls a function, you must execute it and return the result”. What this imposes: everything that protects your ERP lives in your code, between the model’s proposal and the execution, and no model setting replaces that gate.

The shape of the call can be guaranteed, not its meaning. Both vendors offer a strict mode which, per OpenAI, “will ensure function calls reliably adhere to the function schema, instead of being best effort”, and recommend always enabling it. But Anthropic’s documentation also warns that, when a required parameter is missing from the request, the model may “infer a reasonable value” rather than ask, and that this behaviour “is not guaranteed”. What this imposes: a credit-note amount proposed by the model is in the right format, but it may be invented; the gate checks it against the invoice, and the preview shows it before writing.

The tool list has a written, reasonable size. OpenAI recommends “clear and detailed function names, parameter descriptions, and instructions”, enums “to prevent invalid states”, and keeping the list “small for higher accuracy”, with fewer than twenty functions available at the start of a turn; its rule of thumb is the “intern test”: could someone use the function correctly given only what the model sees? What this imposes: no “run a query” or “modify a field” tool, but one tool per business action, create a credit note, send a reminder, and one list per role. What we did not find: a public measure of incidents caused by agents in ERPs; what we see are the six traps described below, and we say so as an observation.

One request becomes four tool calls

The agent is not understood on a diagram but on a real request from the manager, and on what each of its calls becomes.

Figure 1 · The agent never sees the database: it sees four tools, and each goes through the same gate before touching the ERP. The read passes alone; the write under the limit passes with a key that prevents duplicates; the write above the limit becomes an approval request; the tool the role does not have does not exist for it, and the attempt is written.

The request arrives at 9:12 with the manager’s name and role: chase customers more than thirty days late, prepare the credit notes for the week’s returns. The agent splits it into calls. The first reads late customers: a read allowed for this role, twenty-three customers, and the read itself is written to the log. The second sends the reminders: a write, but under the limit, twenty-three sends for a limit of fifty a day, with an approved template and no free text, and an idempotency key so that a call resent after a drop does not send twice; executed.

The third creates a credit note of 12,400 dinars: the invoice exists and belongs to the right customer, the amount is found in the invoice, but it exceeds the 10,000-dinar limit written for this role; the call becomes a preview sent to the manager on their phone through the notification described in the notifications guide, and the credit note does not exist until they approve with one key. The fourth wants to delete an invoice: that tool is not in the “agent” role’s list, it does not exist for it, no parameter is even read, and the attempt is written. Four calls, four log lines, one human decision, and no action the manager could not have done themselves.

An agent in the back office, in five layers

Behind those four calls, five layers, and the middle one is the only one that says no.

Figure 2 · The middle layer is what separates an agent you can plug into your accounting from one you dare not: the model never touches the ERP, it calls tools you wrote, and the gate applies your rules whatever it sends.

The channel: the manager talks to the agent from WhatsApp, the back office or a button in the screen; the request arrives with their name and role, and the agent never has more rights than them, per the rules described in the roles guide. The agent: the model reads the request, chooses the tools, proposes the parameters and explains what it will do; it proposes, it does not execute, and its instructions and limits are versioned in your repository. The tools and the gate: one card per tool, read or write, strict schema; the gate checks the role, the parameters against your data, the limit, idempotency, then logs; it is the layer that belongs to you and depends on no vendor.

The ERP and data: your management software or accounting, called through their API or connector, never the database directly, with the same business rules as for a human, stock, credit, numbering; the way to connect them is that of the integration guide. Supervision: the call log, pending approvals, refusals, cost per task, and the evaluation set replayed at every change, per the measurement guide; a screen read every week that says what the agent did, what it was refused, and what it cost.

«The model proposes; the server disposes. A guessed parameter is stopped at the gate, not at the customer.»

One tool, seen by the agent and checked by the server

A tool’s card is all the model knows; the gate is all the server does, whatever the model sends.

Figure 3 · The card on the left is all the model knows about the tool; the list on the right runs whatever it sends. The vendors themselves warn that a model may guess a missing parameter: that is the reason for the third check, the amount must exist in the invoice, and the fifth, the preview before writing.

What the model reads: a name, create a credit note; a description saying when to use it and when not, “only for a confirmed return or price error, never guess the amount”; and three typed parameters, the invoice number, the amount in dinars, the reason among three values and nothing else. The schema is strict: the call will always have this shape. What the server checks, whatever the model sends: does the “agent” role have this tool; does the invoice exist, for this customer; is the amount a line of the invoice and under the limit; has this call already been executed, by its key; was the preview shown; is the log line written.

The third check answers the vendors’ warning: a model may invent a plausible amount when one is missing; the gate refuses any amount that is not in the invoice, and the agent asks instead of executing. The fifth is the one that reassures the manager: nothing is written to accounting before a preview has been shown, and above the limit, approved. The model proposes; the server disposes. A guessed parameter is stopped here, not at the customer.

Six requests from a manager, and the tools they become

Six requests we hear, and for each the tools, limits and approval it becomes.

Figure 4 · The right column contains no “generic” tool: no “run a query”, no “modify a record”. Each tool does one named thing, with typed parameters and its limit, and that is what makes the agent predictable.

Chase late payers: read balances, then send through an approved template, under a daily limit, never free text, and the list of those sent in return. Create a credit note: write under limit, amount taken from the invoice and never typed, preview and approval above. Place a supplier order: read stock and sales, proposal, and creation as a draft only, validated by a human, because an order commits money going out.

Change a price: write under limit per role, approval beyond, old value kept, dated effect; it is the rule of the B2B portal. Answer a customer: read the order and the route, sourced answer, and never a promise that is not in the data. Produce a report: read the aggregates already defined for the dashboard, no invented calculation, so that the agent’s figure and the screen’s are the same. None of these rows contains a generic tool: each tool does one named thing, and that is what makes the agent predictable.

«The agent never has more rights than the person it assists, and what its role does not have does not exist for it.»

Six traps of an agent in the ERP

Six traps we see on the agents we take over, and what the architecture does against each.

Figure 5 · The first two traps come from the tool card; the other four from the gate. None is solved by changing model, and all are decided in week one, when the tool list is written.

The tool too broad: “run a query”, “modify any field”; the agent does what it understands, and nobody can say in advance what; one tool per business action, typed parameters, enumerated values, fewer than twenty tools per agent. The guessed parameter: the manager did not say the amount, the model invents a plausible one; parameter checked against the source data, and if it is not there, the agent asks. The double execution: the connection drops, the call is resent, two credit notes; idempotency key per call, the second execution returns the result of the first, on the principle described in the offline guide.

The write with no preview: the agent writes to accounting before anyone has seen anything; systematic preview, approval above the limit. The agent more powerful than the human: an administrator account “to keep things simple”, and the sales rep gets it to do what they cannot; the agent inherits the role of whoever talks to it, never more, with a narrower “agent” role of its own. The action with no trace: nobody knows the agent changed this price; log line per call, who asked, which tool, which parameters, before, after, refusals included. The first two come from the tool card, the other four from the gate, and all are decided in week one.

Seen elsewhere: the vendors’ tool documentation, and what transposes

Two sources say the essentials. Anthropic’s and OpenAI’s documentation say the model proposes a structured call and your code executes it, that strict mode guarantees the call’s shape, and that a missing parameter may be inferred rather than asked for; what transposes is that an agent’s safety is a matter of server-side code, not of model, and that a guaranteed shape does not excuse checking the meaning. OpenAI also says to keep fewer than twenty tools, with clear names and enumerated values; what transposes is a short list of business tools per role, not a generic tool.

What these sources do not say: which actions your manager wants to delegate, which limits they accept, and who approves above; the project’s first week answers that, with the ten requests they really make.

The rules of an agent you can plug into the ERP

Six rules, written in the first week. The agent sees only tools, never the database. A tool does one named thing, with typed parameters and enumerated values; fewer than twenty per role. Reading before writing, and every write has a limit and a preview. Above the limit, an approval, on the phone of whoever can say yes. One key per call: nothing executes twice. One log line per call, refusals included, and the agent never has more rights than the person it assists.

A seventh rule concerns the quote: “AI agent connected to the ERP” is not a requirement, it is a sentence; the requirement reads “tool list per role, read or write, strict schema and description per tool; server-side gate checking role, parameters against data, limits, idempotency; preview before writing; approval on the phone above the limit; log per call with before and after; evaluation set of sixty real requests including missing parameters, out-of-rights and duplicates; two read-only weeks before the first write”, and it is checked as the specification guide recommends. A quote that prices “the AI’s access to the database” has priced trap number one.

Six companies, and the first write tool opened

Six companies we often equip, and for each the first write tool opened after the two read-only weeks.

The distributor and its portal, described in the dedicated guide. Chasing late payers by template, under a daily limit; credit notes stay in approval for several weeks.
The accounting firm. Filing read documents in the right client folder; no accounting entry by the agent before the second month.
The clinic. Booking appointments in free slots; never the medical record in write.
The real-estate agency. Generating the month’s receipts as drafts, validated in bulk by the manager.
The private school. Due-date reminders to parents by template; tuition discounts in approval.
The company run from France. The day’s report per branch in read; approval of credit notes and discounts on the founder’s phone, wherever they are.

The 2027 calendar

The calendar is that of an agent plugged into the back office in eight weeks, two of which it can write nothing.

Figure 6 · Eight weeks, and the agent can write nothing before the fifth: two read-only weeks, during which it explains what it would do, are what gives the manager the confidence to open the first write. Writes are opened one at a time, each with its limit.

Week 0 to 1 writes the requests and the tools: the ten requests the manager really makes, the tool list with read or write, limit and approver; signed. Week 1 to 2 writes the evaluation set: sixty real requests with the expected calls, and the traps, missing parameter, out-of-rights request, duplicate. Weeks 2 to 4 build the read tools and the gate: cards, strict schemas, role and parameter checks, log; the agent answers and explains what it would do, and writes nothing.

Weeks 4 to 6 open the write tools, one at a time: limits, idempotency, preview, approval on the phone. Weeks 6 to 8 are the pilot with the manager and two people: every refusal and approval read every day, cost per task measured, and every error added to the set. Every batch is demoed as the delivery guide describes; and when requests contain sensitive documents, the model runs where the private deployment guide provides.

What makes an agent in the ERP fail

The agents we take over almost always failed for one of these reasons.

Direct access to the database. The model writes queries; nobody knows which in advance.
Writing from day one. No read-only period; trust was never built.
No limit. A 40 % discount granted because the customer insisted.
No idempotency key. A network drop, and three identical invoices.
The administrator agent. It does for the sales rep what the sales rep is not allowed to do.
Generic tools. “Modify a record”: the agent modified the wrong one.
No log of refusals. Nobody knows what the agent tried, or who asked it.

Frequently asked questions

The questions we receive from managers, founders and IT departments.

Can the agent write to our accounting or ERP?: Yes, through tools we write one by one, never through the database: each tool does one named action, create a credit note, send a reminder, with typed parameters. The model proposes the call; your server checks it, role, parameters against your data, limit, duplicate, and executes or refuses it. Above a limit, the action becomes an approval request on the phone of whoever can say yes.
What happens if the agent gets the amount or the customer wrong?: The gate stops it before writing: an amount that is not a line of the invoice is refused, an invoice that does not belong to the customer too, and a missing parameter makes the agent ask instead of guessing. For writes, a preview is shown before writing, and above the limit nothing is written without approval. Every refusal is in the log.
And if the same action is executed twice?: Every call carries an idempotency key; if the connection drops and the call is resent, the second execution returns the result of the first instead of creating a second credit note or resending twenty-three reminders. It is the same mechanism as for an offline app that resynchronises.
Does the agent have more rights than my employees?: Never. It inherits the role of the person talking to it, and additionally has a narrower “agent” role of its own: reading what is needed, writes under a limit, no deletion, no export. A sales rep cannot get it to do what they are not allowed to do themselves, and every action carries both names in the log.
How do we know what the agent did?: Through the log: one line per call, who asked, which tool, which parameters, the value before and after, and the result, executed, pending or refused. A weekly screen summarises what it did, what it was refused, what it cost, and the evaluation set is replayed at every change of tool or model.
How long to plug in an agent?: Eight weeks: one to write the requests and the tool list, one for the evaluation set, two for the read tools and the gate, during which the agent explains without writing, two to open the write tools one by one with their limits, two of pilot with the manager. The agent writes nothing before week five.