Mahmoud ElZouhery

Giving an AI agent write access to your ERP

2026-08-12T00:00:00Z

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.

The deployment playbook that ended our environment drift

2026-07-09T00:00:00Z

When I took ownership of a company's full Azure footprint — dev, staging and production across several departments — the problem wasn't cost or performance. It was that no two environments were the same, and nobody could tell you why.

Staging had a configuration production didn't. One team's dev environment had drifted so far it was effectively a fourth environment. Every release involved a small archaeology project.

The fix wasn't a tool. It was a document.

Drift is a decision-making problem

Environment drift is usually described as a technical failure — someone clicked something in the portal. That's the mechanism, not the cause.

The cause is that when an engineer hits a blocker at 6pm before a release, the portal is the fastest path to unblocked, and nothing in the process makes the slower path more attractive. Drift is what a rational person does under deadline pressure when the correct route is undefined.

So the question isn't "how do we stop people clicking in the portal." It's "what makes the repeatable path the fastest path."

What went into the playbook

Not a wiki with everything. One document, short enough that people actually read it, covering four things:

Provisioning. How an environment comes into existence, defined as code, with the exact command. Not "use Terraform" — the command, the repo, the variables file. If creating an environment requires a decision, the playbook makes the decision.

Release gates. What must be true before a build moves to the next environment, expressed as checks rather than as approvals. An approval is a person's judgement under time pressure; a check is a check. Approvals still existed, but they stopped being the mechanism of quality.

Rollback. Written before it was needed, tested when it wasn't. The single biggest driver of portal-clicking is a failed release with no defined way back. Once rollback was a known, rehearsed one-liner, the panic edits mostly disappeared.

Ownership. Who owns each environment, and specifically who to wake up. Ambiguous ownership means everyone's fix is somebody else's surprise.

Why it was adopted

I've written process documents that nobody read. This one got picked up across every team, and I think the reason is that it was shorter than the alternative.

The playbook wasn't competing with a better process — it was competing with improvisation. If following it takes fifteen minutes and improvising takes forty-five plus an incident, adoption isn't a cultural problem. Make the correct path measurably faster and the argument makes itself.

The parts I got wrong were the parts where I asked people to do something slower "because it's correct." Those got skipped, quietly, exactly as they deserved to be.

The unglamorous conclusion

Most of what I'd call good architecture at the infrastructure level is removing reasons for things to go wrong, rather than adding capability. Nobody puts "wrote a deployment playbook" on a conference slide. It still returned more hours than any framework decision I made that year.

Taking over an account that's already on warning

2026-06-18T00:00:00Z

There's a particular kind of phone call in this job. A flagship account is in trouble, the customer has put something in writing, and someone needs to take it over. In my case the stack was unfamiliar, the team was demoralised, and the customer had stopped assuming good faith.

That engagement ended with documented positive feedback. Here's the order I did things in, because the order mattered more than any individual decision.

Week one: stop talking about the plan

The instinct when you inherit a troubled account is to produce a recovery plan. Resist it for a few days. A plan written before you understand the failure is a second thing the customer will watch you miss.

What I did instead:

Read every ticket, not the summary of every ticket. Summaries are written by people protecting themselves. The raw tickets told me the real story: the same three integration points failing repeatedly, and each fix being applied at the symptom.

Talked to the engineers alone, before the managers. Not to gather evidence — to find out what they'd already flagged and been overruled on. In almost every troubled project I've walked into, someone junior called it correctly six months earlier and got talked out of it. Finding that person is the fastest route to the actual problem.

Asked the customer what "fixed" looks like. Concretely. Not "improved quality" — which release, which behaviour, observed by whom. A formal warning is usually a communication failure wearing a technical costume. The customer often can't tell you what would satisfy them until you make them say it out loud.

Week two: fix one visible thing, completely

Not the biggest thing. The most visible thing that can be genuinely finished.

Credibility on a warned account is spent, and you rebuild it with completed items, not progress percentages. One thing shipped, verified, and closed does more for the relationship than a Gantt chart showing eleven things at 60%.

This is also where you find out whether your team can actually finish anything, which is diagnostic information you need early.

The uncomfortable parts

I stopped some work that people were emotionally invested in. Two workstreams were consuming capacity and producing nothing the customer had asked for. Ending them cost me goodwill inside the team that took months to earn back.

I over-communicated to the point of it feeling excessive. Weekly written status, every week, whether or not there was good news — especially when there wasn't. A warned customer reads silence as concealment. The week I had nothing good to report was the most important status update I sent.

I didn't defend the past. The temptation to explain why the previous decisions were reasonable given the constraints is strong and completely counterproductive. The customer doesn't need the history litigated. They need to see the next thing land.

What I'd tell someone walking into one

Ramping up on an unfamiliar stack while the account is on fire is survivable — the technology is rarely the bottleneck. The bottleneck is that everyone involved has stopped trusting the process, and trust is rebuilt in small completed increments, publicly, on a schedule.

The stack you can learn in a fortnight. The trust takes the whole engagement.