Microsoft 365 Copilot and the Work It Does Not Do

Copilot is an assistant and this is a governed execution substrate. They are not competing for the same budget line, and a comparison that pretends otherwise is selling something. The useful question is where the boundary sits — and it sits exactly where an action stops being reversible.

Where Copilot is the right answer

If the work is drafting, summarising, or finding something inside the Microsoft estate, buy Copilot and do not build anything. It is already licensed, already deployed, already inside the applications people have open, and it is grounded in tenant content without anyone standing up a retrieval pipeline. There is no procurement cycle, no security review of a new vendor, and no integration work. Nothing you build will beat that economics for that class of work.

From the standard

“Granting LLMs unchecked autonomy to take action can lead to unintended consequences, jeopardizing reliability, privacy, and trust.”

That is a large share of the value people expect from enterprise AI, and it is available now. Teams that skip it in order to build something more ambitious usually end up with a worse assistant and a project.

Inheriting permissions is not intersecting them

The most reported Copilot problem is oversharing: content a user technically had access to but would never have found now arrives in a summary. This is usually described as a Copilot flaw. It is not. It is an accurate report of a permission state that existed before anyone installed anything, and the honest response is to fix the permissions rather than blame the retrieval.

The distinction that matters once a system takes actions rather than only reading is between inheriting a permission set and intersecting one. An agent that inherits acts with everything its user could reach. An agent that intersects acts with the overlap of what the platform allows, what the tenant has enabled, and what that user's role permits — computed per turn, so a capability outside the current task is not merely unused but absent. The second is a containment boundary. The first is a convenience.

Assistant	Governed agent
Retrieves what you can already see	Acts as you, within an intersected tool roster
A confirmation dialog before an action	Policy validated outside the model’s own channel
The action is logged	Approval pinned to a version token, replay refused
An answer with references	Each claim resolves to the tool call and result set behind it

Where the line actually falls

Reversibility. A wrong summary wastes five minutes and the reader notices. A wrong write to a system of record propagates into a forecast, a customer record, or a regulatory filing, and nobody notices until the quarter closes. Every control worth paying for exists on the second side of that line, and none of them are worth paying for on the first.

Assistants are increasingly able to cross that line through connectors and extensions. That capability is real and it is not the same thing as the control that should accompany it. The question to ask a vendor — including us — is not what the system can reach, but what stands between the model deciding and the write landing, and whether an auditor can reconstruct the decision two years later without the vendor in the room.

How to decide

Deploy the assistant first. It is cheaper, it is faster, and the adoption data it produces tells you which workflows people actually want automated — which is better input to a build decision than any workshop. Then look at what is left over: the work that crosses application boundaries, ends in a write somebody has to answer for, or touches data a reviewer will ask about by name. That residue is the case for a governed substrate, and it is usually smaller and more specific than the original ambition.

If the residue is empty, you do not need us, and we would rather tell you that in the first conversation than in the third month.