This is an illustration, not a client engagement. The systems, the questions and the frustrations are the ordinary ones in contracting; no client data appears anywhere in it. We wrote it because the phrase “AI connected to your systems” means very little until you see what a Tuesday actually looks like before and after.
The company
A contracting firm of a few hundred people. Odoo runs finance and procurement. An internal helpdesk takes IT and equipment requests. Site photographs, drawings and variation orders live in a shared drive. Timesheets are spreadsheets. Everything urgent happens on WhatsApp. Nothing here is broken, and that is the point: each system does its job well, and none of them can see the others.
A question that should take seconds
“Is Project 12 over budget, and what is still committed against it?” Answering that today means exporting the cost report, opening the purchase order list, checking which subcontractor claims have not been certified, and calling the site engineer to ask what is arriving this week. The answer lands the following afternoon. By then two more purchase orders have gone out against the same cost code, which is precisely the problem the question was meant to catch.
What gets connected
Four connectors, each scoped deliberately. Odoo: read across projects, budgets, purchase orders and subcontractor claims, with one write action, raising a draft purchase order. The shared drive: read only, so drawings and variation orders can be found and quoted. The helpdesk: read, plus the ability to open a ticket. The timesheet sheets: read only. Payroll is not connected at all, because nobody needs it in this conversation.
The same Tuesday, afterwards
The project manager asks the same question in plain language and gets committed against actual cost by cost code, the three purchase orders sitting unapproved, and the subcontractor claim that has been waiting eleven days for certification. He follows up with “draft the purchase order for the rebar against Project 12” and gets a draft that still needs the same human approval it always did. Then “show me labour cost per floor this month” returns a chart built on the spot, with the rows behind it.
Where the guardrails sit
Read-only is the default, and every write lands as a draft that a person approves. Permissions mirror the roles people already hold in the ERP, so a site engineer sees his own project and nothing else, and the assistant cannot become a way around an approval chain. Every action is written to an audit trail. Systems you would rather keep out simply stay disconnected, which is a decision you make per system rather than once for everything.
What we would measure
Three numbers, taken before the work starts and again afterwards: how long it takes to answer a cost question, how many manual exports the finance team produces in a week, and how many purchase orders are raised against cost codes already over budget. If those do not move, the implementation has not earned its place, and we would rather find that out in week six than in year two.
Why an open standard rather than a one-off integration
The Model Context Protocol is an open standard, so the connectors are not tied to a model or a vendor. The same four connectors work whether you run Claude, GPT, Gemini or an open model on your own servers, and they keep working when you change your mind. A custom integration written against one provider's interface becomes a rewrite the day that decision changes, and in this field it changes often.
Where to start
Not with everything. One system, one team and one question that is asked every week. Connect it read-only, let people use it for a fortnight, and watch which questions they actually ask, because that list is never the one drawn up in the kick-off meeting. Then add the second system, and the first write action, once the guardrails have been tested on something harmless.
If you want to see this mapped against your own systems rather than a worked example, that is what a first conversation with us covers.