Giving an AI agent write access to your ERP

Connecting a language model to an ERP so it can answer questions is a weekend project. Connecting one so it can create the invoice is a different exercise entirely, and most of the difficulty has nothing to do with the model.

I've spent this year building MCP plugins and agentic workflows over Odoo — HR, sales, invoicing, timesheets — and these are the design rules I keep coming back to.

Read and write are different products

The temptation is to expose one set of tools and let the agent figure out intent. Don't. Read operations and write operations have different failure modes, different blast radii, and should be designed as if they were built by different teams.

A wrong read is a wrong answer, and the human catches it. A wrong write is a record in a system of truth that somebody's month-end depends on. The bar isn't "usually correct."

Design the tool, not the prompt

Most agent failures I've debugged were tool design failures wearing a prompt costume.

If your create_invoice tool takes fifteen optional parameters and silently defaults the rest, the model will produce plausible invoices with wrong defaults, and it will do so confidently. The fix isn't a longer system prompt telling it to be careful. The fix is a tool that refuses to run without the fields that matter, and returns an error the model can actually act on.

Practical version of this:

• Make illegal states unrepresentable at the tool boundary. If a sale order can't be confirmed without a customer, the tool should reject it, not the prompt.
• Return errors that describe the remedy, not just the failure. Missing partner_id — call list_contacts to resolve the customer name first gets recovered from. 400 Bad Request doesn't.
• Keep tools narrow. Ten specific tools beat one general one with a mode parameter, every time.

Separate proposing from committing

The pattern that has worked best: the agent proposes a fully-formed action, a human commits it, and the commit path is a different code path from the proposal path.

This sounds like it defeats the purpose. It doesn't. The expensive part of back-office work is almost never the click — it's assembling the context, finding the right records, and getting the fields right. An agent that does 95% of that and stops is delivering nearly all of the value at a fraction of the risk.

Over time you move specific, well-understood operations from propose to auto-commit, one at a time, based on observed accuracy. What you don't do is start there.

Idempotency is not optional

Agents retry. Networks fail mid-call. A model that doesn't get a clean response will try again, because that's the sensible thing to do.

If your write tools aren't idempotent, you will get duplicate records, and you'll find out during a month-end close. Every write operation needs either a natural idempotency key or an explicit one the agent must pass. This is the single most common gap I see in agent integrations that worked fine in testing.

Log the reasoning, not just the result

When an agent creates a record, log what it was asked, which tools it called, and in what order. Not for observability theatre — for the conversation that happens three weeks later when someone asks why this invoice looks odd.

Without that trail, an AI-driven process is unauditable, and unauditable processes don't survive their first real mistake.

The actual lesson

None of this is about models getting better. Every rule above is the same engineering discipline you'd apply to any integration that writes to a system of record — constrained interfaces, explicit contracts, idempotency, audit trails.

The novelty is that the caller is non-deterministic and unusually good at producing plausible-looking wrong input. That doesn't call for new principles. It calls for the existing ones, applied without the shortcuts we've been getting away with when the caller was another service we controlled.