What Microsoft Copilot for 365 does very well
Copilot for Microsoft 365 lives where your team already spends the day. It summarises a long Outlook thread, drafts an agenda from the latest Word version, writes the Excel formula you described in plain English, turns a Teams meeting into actionable bullets. If the team works on top of M365 full time, the personal ROI shows up quickly and Microsoft doesn’t need to be told how the ecosystem works.
It also inherits the tenant’s governance. Sensitivity labels, DLP, Conditional Access and the permissions of every SharePoint site apply without anyone having to reconfigure them. For many companies, that “respects what we already had” weighs as much as the new capabilities.
What Copilot for Sales / Service / Studio covers
The “Copilot” umbrella is wider than the productivity edition. Copilot for Sales and Copilot for Service bring conversational logic into Dynamics 365, with assistance for AEs and support agents. Copilot Studio lets teams build custom copilots — conversational flows, triggers, action calls — with no code, inside the Microsoft stack.
If your CRM is already Dynamics, your service desk runs on Customer Service and your team can build on Power Platform, Copilot Studio is a very reasonable option for the first layer of conversational automation. The line shows up when the flow needs to go beyond what Studio comfortably models, or when the systems that need to join the dance aren’t Microsoft’s.
Where a custom agent adds value
A custom agent is the answer when the process needs more freedom than Copilot offers. Typical cases where we get involved:
- The flow crosses M365 with Salesforce, HubSpot, SAP, Holded, Odoo or a vertical ERP. Copilot can read SharePoint and Dynamics; for everything else you need a connector that lives outside.
- Business logic is dense — per-customer pricing, per-contract SLAs, sector-specific exceptions. Copilot Studio can model some of it; what doesn’t fit comfortably ends up hidden in Power Automate or Functions.
- Traceability has to reach the decision level, not just messages: which sources the agent consulted, which rules it applied, what it left pending for human review.
- The team wants to keep code, prompts and connectors in their own repo, without exclusive dependence on a single vendor.
When we build against M365 we go through Microsoft Graph and Entra ID, with admin consent and the same governance controls Copilot uses. The agent is ours, but the rules are still the tenant’s.
They can coexist — and usually should
Framing it as “Copilot or custom agent” is usually the wrong question. What we see working is: Copilot for 365 covering the team’s personal productivity, Copilot for Sales or Service in place if Dynamics is already there, and custom agents handling the vertical workflows that cross systems or need explicit logic. Each one in its lane, no toes stepped on.
The practical rule we use: if the use case lives entirely inside M365 and a generalist copilot solves it, Copilot. If it touches several systems, packs dense business rules or needs deep audit, a custom agent. When it’s not clear, we look at the actual workflow during a working session and the answer shows up on its own.