A customer rolled out an AI assisted discovery project across its 28,000 user on-premises legacy telephony infrastructure, prior to a planned move to Microsoft Teams. When asked where they were wasting license spend on aspects such as duplicated licenses and unused services, the customer produced a genuinely good answer almost immediately – a justifiable saving in excess of $800,000 a year.
Then it stopped. Nothing in that organization could take the recommendations and implement the changes. Reclaiming those licenses meant touching identity, entitlement policy, three approval chains, and a service desk queue. The answer sat in a chat window for eleven weeks. As far as I know, it is still there.
This is the last in a series of three posts from me; which form one fundamental argument. The first post was about domain knowledge: AI accelerates execution, but without expertise guiding what to build, you move faster in the wrong direction. The second post addressed trusted data: judgment applied to stale or incomplete numbers produces confident, fast, wrong decisions.
Both are necessary, but neither is sufficient, because knowing what to do, and knowing it is true, still leaves the hardest question untouched. This is the question rarely asked in the demo.
Who executes change?
This is where most AI discussions stop, because this is where the demo ends. An AI assistant might identify a problem, and it might even recommend a solution. But the critical question remains: who executes it? Who applies governance policies across multiple Microsoft tenants? Who provisions thousands of users? Who orchestrates workflows across identity systems, ITSM platforms, communications infrastructure, licensing, and security? And who ensures that every action remains compliant with organizational policy?
Those questions have answers in most enterprises. The answers are usually people – and usually fewer people than anyone is comfortable admitting. A handful of engineers who know which console to open, in what order, and what breaks if you do it wrong.
AI does not remove that constraint. It moves it, and it moves it in an uncomfortable direction. A system that generates ten well-grounded recommendations a day, delivered into an organization that can execute two times a week, has not created value. It has created a more articulate backlog.
Output is different from change
It’s worth conceding something here, because arguments like this one usually skip it: plenty of organizations are getting real value from AI today with no operational platform at all. Summarization, drafting, code assistance, search across documents – these work, they work now, and they need no orchestration to deliver a return. For those workloads, model choice genuinely matters.
The distinction is whether the AI is producing output or producing change. Output is finished when it appears on the screen. Change is only finished when something in the estate is different, and everything between those two states is operational work that no model performs. Output needs a good model. Change needs somewhere to land.
Execution is a governance problem before it is a technical one
In the first post I made the point that RBAC, data segmentation, compliance controls and audit trails are not features you can generate from a prompt. This mattered when we were talking about some automation a developer had vibe-coded over a weekend. It matters more when AI stops “recommending” and starts “doing”.
The risk profile is not symmetrical. A recommendation engine that gets it wrong wastes someone’s afternoon. An execution engine that gets it wrong deprovisions 400 users on a Tuesday morning. Most enterprise policy frameworks I see were written for a world where every change had a person’s name against it, an approval behind it, and a change window around it – and they simply do not describe what should happen when the actor is an agent operating at machine speed.
Which means safe execution isn’t one capability but several, and none of them are glamorous. Every action needs to be checked against policy before it runs, not reviewed after the damage is done. Changes need to be contained, so a bad instruction affects ten users, not ten thousand – the blast radius must be bound by design, not by luck. Approval routing should kick in for the changes that genuinely warrant a human, and only those. There needs to be a complete audit trail that reconstructs exactly what was done, by which agent, under whose authority, against which policy. And everything needs to be reversible – because the question was never whether something would go wrong, only when.
This is the difference between an AI agent you can give write access to and one you cannot. Very few enterprises can currently tell you which of the two they have.
Becoming the platform for enterprise AI
Organizations should not have to rebuild their operational foundations every time AI evolves. They need a layer that lets AI technologies plug into existing processes while governance, automation, and control stay where they are.
This is why VOSS is evolving beyond communications management. Concretely: the platform executes the change that AI recommends, under policy. Multi-tenant Microsoft governance applied consistently rather than tenant by tenant. Bulk provisioning and de-provisioning that survives an audit. Workflows that cross the underlying communications infrastructure, track usage records, licensing, and as a single transaction rather than four tickets and a spreadsheet. Every action checked against policy before it runs and logged after it does.
Customers bring whatever models they prefer, whenever they are ready. VOSS takes care of what happens after the recommendation.

AI is only one layer of the stack
The future of enterprise AI will not belong to organizations with the largest or most advanced language models. Those are getting cheaper and more interchangeable every quarter, which is rather the point of this series.
It will belong to the organizations that have all three layers: the domain knowledge to know what is worth doing; the trusted data to know whether it is true; and the operational platform to actually do it safely, repeatedly, and at a scale no team of engineers can match by hand. Miss any one of the three and the other two stop paying.
AI is not replacing operational platforms. It is exposing exactly how much weight they were always carrying. And that is where the real opportunity lies – not in building another AI assistant, but in becoming the platform that makes enterprise AI work.
If you would like to talk about what that looks like in your estate, please get in touch.
Previous articles of interest

This first post was about domain knowledge: AI accelerates execution, but without expertise guiding what to build, you move faster in the wrong direction.

The second post addressed trusted data: judgment applied to stale or incomplete numbers produces confident, fast, wrong decisions.
Keep up to date with our latest blogs and subscribe today



