In May, Microsoft released its Work Trend Index 2026, a comprehensive report based on 20,000 survey responses across ten countries and trillions of anonymised signals from Microsoft 365. One concept stands out and is worth reflecting on: Owned Intelligence.
Microsoft describes Owned Intelligence as institutional knowledge built up over time, unique to the company, and difficult to copy. That is where, according to the report, long-term competitive advantage lies as agents take over more and more of the execution.
For Dynamics 365 buyers, this is more relevant than it sounds, touching on a question that most procurement processes today are not quite structured to handle.
Where the market stands right now
Dynamics 365 is in an interesting phase. Copilot is embedded across the entire product portfolio. Agents can be created directly within applications or via Copilot Studio. Microsoft is releasing new AI features at a pace many customers struggle to keep up with.
At the same time, Microsoft's own report reveals an uncomfortable truth: only 19 per cent of AI users are in what Microsoft calls the "Frontier Zone", where both individual capability and organisational readiness are in place. 65 per cent are worried about falling behind, yet 45 per cent feel safer focusing on current goals than redesigning work. Only 13 per cent say they are rewarded for transforming how work gets done.
This tension is what the report calls the Transformation Paradox. It is not a technical problem. It is an organisational problem. And it is particularly evident in ERP and CRM projects.
Microsoft's picture is interestingly complemented by independent analysts. Gartner notes in its 2026 Hype Cycle that only 17 per cent of organisations have actually deployed AI agents, even though over 60 per cent report planning to do so within two years. Even more strikingly: Gartner predicts that over 40 per cent of all agentic AI projects will be abandoned by the end of 2027, often because costs spiral, business value remains insufficiently clear, or governance and risk controls fail to keep pace with the technology.
McKinsey's State of AI report points in the same direction: 88 per cent of organisations use AI in at least one function, but only 6 per cent qualify as "AI high performers" with measurable EBIT impact. The rest have pilots, demos, and initiatives, but not transformation.
This is the same phenomenon viewed from different angles. Microsoft calls it the Transformation Paradox, Gartner speaks of the gap between ambition and delivery, and McKinsey describes "pilot purgatory". They all point to the same reality: organisations have access to the tools, but have not restructured the surrounding context, leaving the value unrealised.
The evaluation dialogue today
In the procurements I follow, discussions quickly fall into a familiar pattern: functionality, user interface, integrations. That is where procurement templates land, and where both partners and buyers share common ground. It is a good, proven way to compare options.
When Copilot or agents come up, the possibilities are demonstrated - that you can build custom agents, connect Copilot into flows, or use Power Platform for custom development. However, the discussion easily stays light and slides back to core system functionality. That is understandable. That is where value is concrete, measurable, and presentable. That is where a demo feels safe.
This is not a criticism of any party; it is simply how conversations are structured today. But that is not where owned intelligence is built.
It is not a question of building custom vs. buying off-the-shelf
Here lies a common misconception. "Owned Intelligence" is easily misinterpreted as needing to build everything yourself - custom agents, custom integrations, an in-house AI team. That is not what it is about.
The real question is capability.
Does the company have internal capability to understand what is being built, why, and how it should evolve? Or are you left on the outside as the solution grows? Can the organisation independently identify new areas where agents and Copilot would make a difference, or must that proposition always come from the partner?
A solution fully developed by a partner can be technically excellent. But if the understanding of how it functions and how it should be further developed in practice resides exclusively externally, building long-term intelligence within the company becomes far harder. To be clear: many partners excel at knowledge transfer and want their clients to grow stronger, but this needs to be an explicit part of the engagement model, not something assumed to "happen automatically".
This aligns closely with one of the report's strongest statistical observations: organisational factors such as culture, leadership support, and skills development account for roughly 67 per cent of AI's actual impact, while individual mindset and behaviour account for around 32 per cent. In other words, it is not primarily individual employees' AI skills that determine the outcome. It is how the organisation as a whole is set up to capture and build upon what agents produce.
In January 2026, McKinsey published an analysis specifically on AI agents and ERP that reaches a similar conclusion. Their recommendation is that buyers clearly distinguish between two things: standardised capabilities that can be bought ready-made, and proprietary development reserved for areas where the company's domain-specific logic or unique processes actually create a competitive advantage. This is the same principle behind Owned Intelligence, framed from an ERP perspective. The value lies neither in building everything yourself nor in buying everything off-the-shelf, but in knowing where to draw the line.
Two frequently overlooked risks
When speaking with clients facing a major Dynamics 365 selection, there are two uncomfortable observations worth highlighting.
Risk 1: Custom builds resulting in key-person dependency
Companies that choose to build extensively themselves - custom agents, custom automation flows in Power Automate, bespoke integrations - can deliver value quickly. However, the risk is that expertise becomes concentrated in a few key individuals internally. If one of them leaves, a significant portion of the understanding leaves with them. Documentation falls behind, solutions become difficult to maintain, and the company finds itself in an uncomfortable position. This is a real vulnerability, particularly in companies with lean IT departments.
Risk 2: Total partner reliance losing momentum
Relying entirely on a partner can still lead to a slower pace of development than expected - not from any lack of partner willingness, but because internal buyer priorities are easily consumed by daily operational needs like upgrades, security, and support. Without a shared roadmap, clear product owners on the buyer side, and a funded cadence of development (whether led by the partner, internally, or jointly), Copilot and agent initiatives often stall. When initiative resides outside your organisation, process insights, data patterns, and decision points are also less likely to take root internally. The company owns the solution, but risks failing to build an expanding understanding of it.
Neither extreme is sustainable over time. Reality demands a combination, and the question is how that balance is designed from the outset.
What characterises successful buyers
In my experience, three traits consistently appear among companies that handle this well.
Broad engagement
It is not enough for one or two internal champions to drive the initiative. Multiple parts of the organisation must participate - IT, business operations, and executive leadership. Otherwise, owned intelligence effectively becomes the project of a few individuals rather than the enterprise. Microsoft's report confirms this indirectly: only 26 per cent of AI users report that their leadership is clearly and consistently aligned on AI. It is one of the strongest indicators in the entire dataset explaining where organisations get stuck.
Internal project structure mirroring the partner's
Partners operate within a project structure with defined roles, deliverables, and accountability. That structure needs to be mirrored on the buyer side - a counterpart with clear roles, mandates, and routines, not an ad-hoc team that meets only when issues arise. When both sides work in parallel structures, handovers become clearer, decisions are made faster, and knowledge finds a structured home on the buyer side.
Insight into the existing environment
Here lies the true value of internal IT: deep insight into the existing environment, historical decisions, and how business operations function in practice. That context cannot be brought in by a partner; it must be held by the buyer, regardless of how capable the partner is. It is also where the buyer retains a structural advantage that is frequently underestimated in the early stages of a project.
When these three elements are in place, what is built becomes something the company truly owns - not just a solution you operate, but a capability you can develop over time.
The question buyers must ask themselves
In a typical procurement, solutions are presented and evaluated based on functionality, commercial terms, and delivery capability. That is a sound, proven framework, but the question of where long-term intelligence will be built does not arise automatically within it. It must originate from the buyer side, early enough to shape how the project is actually structured.
Here are a few concrete questions worth bringing into discussions:
- Which elements of the solution should be built by the partner, and which elements should be co-developed?
- How will agents, flows, and customizations be documented to ensure knowledge remains in-house?
- What will our internal organisation look like during and after the project - what roles and mandate structures do we need?
- What plan exists for internal IT and business teams to continue developing the solution post-go-live, even without daily partner involvement?
- What knowledge transfer is planned - not as an afterthought at the end, but as an ongoing core component of the project?
These questions are not meant to express distrust in a partner. They are designed to clarify responsibilities and knowledge flows early, benefiting both buyer and partner.
For the buyer, this is fundamentally the question that determines what procurement actually yields over a five-year horizon: a system, or a capability.
Microsoft's report provides a compelling reason to raise this question early, before features and integrations lock in the framework for the entire discussion.