What organisations get wrong about AI readiness, and what it actually takes

In May 2026 I watched something in a conference room in Slovenia that I had not seen before.

DynamicsMinds is one of the largest independent Microsoft Dynamics 365 conferences in Europe, held that year in Portoroz. I was there as part of the 365Connect team, watching our own people present.

Patrick Mouwen, our Principal Architect and co-founder, took the stage with a session called "Headless Superpowers: Building the First MCP Layer for D365 Commerce (with AI Agents)." What he demonstrated was an AI agent taking real actions inside a live D365 Commerce environment. Not suggesting actions. Not a chatbot. Not a prototype running on sample data. An agent completing real B2B commerce workflows, pricing, orders, master data, through a governed API layer that our team had built ourselves.

Microsoft has its own native MCP endpoint for D365 Commerce in development, which was in private preview in late 2025 and is moving toward general availability this year. Patrick's approach is architecturally distinct and independent of that roadmap. It was running in a live production environment and demonstrated publicly while Microsoft's own native capability was still in preview. I think that is the stronger story: the team understood the problem well enough to build their own solution rather than wait for the platform to catch up.

The architecture itself is straightforward to describe, even if it was not straightforward to build. D365 Commerce APIs are exposed through Azure API Management. MCP tools are generated from curated API metadata. Claude acts as the AI agent. No Copilot Studio, no hardcoded tools, and everything runs inside the client's own Azure tenant. No external data, no vendor lock-in.

The room's reaction was genuinely engaged. Watching AI agents act on a live commerce environment in real time landed strongly with an audience that has seen a great many AI demos.

"The hard part is not the AI model or coding an MCP server. The hard part is giving the AI the right metadata." Patrick Mouwen, Principal Architect and co-founder, 365Connect

For anyone outside the D365 world, that line is the whole point. An AI is only as useful as the description of the business context it has been given. The model is rarely the bottleneck. The bottleneck is whether anyone has done the work of describing the system well enough for a machine to act inside it safely.

As I put it on LinkedIn shortly afterwards: AI was everywhere at that conference. Not as a buzzword, as a genuine question the whole community was trying to answer. How do you actually make it work inside an ERP? How do you govern it? How do you make it do things, not just suggest things? That is exactly what our team showed on stage.

Around the same time, we went live with a client's B2B eshop. And the thing that made the launch clean was not just the integration work.

I cannot name the client. What I can say is that they run Dynamics 365 Commerce, and our scope at 365Connect was the headless B2B eshop integration. Another partner handled the ERP implementation itself.

The integration work was substantial and foundational. But the thing that actually made the difference at go-live was what happened before any customer ever touched the system: the Master Data Quality Framework, architected by Patrick, with the validation report built by Siva Ganeshamurthi and Manoj Kumaresan.

It is a continuous, automated validation framework built on Dynamics 365, Azure SQL, and Power BI. It checks every product, customer, and pricing record against more than 40 validation rules, using BYOD data projects to extract from D365 F&O and Commerce into Azure SQL, with Power BI dashboards refreshing up to eight times a day.

Before the framework existed, approximately 25 percent of eshop-enabled products had blocking data errors. This figure is published on 365Connect's website. Missing price lines, untranslated product names, incorrect tax groups, broken customer hierarchy configurations, missing channel assignments. None of these were visible without the framework. They were silent blockers, the kind that surface as order failures or incorrect invoicing only after a customer hits them.

We went live in phases. Phase one was internal testing with real orders, which was cancelled. Phase two moved to manually processed orders from the commerce environment. We are currently in phase three: "friends and family," with three identified customers placing real orders on the live eshop while we monitor closely. The eshop went live last week and the first live orders have landed cleanly.

Every morning, the business team opens a Power BI dashboard to check for new errors before they reach a customer. Manish Dhanabalakrishnan built and tested much of the API layer that this integration runs on.

The framework did not make the data perfect. It made the errors visible so they could be fixed. That distinction matters. If an AI agent had been acting on this data before the framework existed, it would have made decisions based on those errors, not because the AI was wrong, but because the foundation was not ready.

I led the programme. The team built it. These are not the same thing, and I want to be precise about that.