Copilot Isn't Enough: Where Microsoft 365 AI Ends and Custom AI Begins
I've written six books about Microsoft 365, so let me start by defending it: Copilot is not hype. If your team lives in Outlook, Teams, Word, and Excel, Copilot removes real friction from real work. Summarizing a thread you were cc'd into too late, drafting the first pass of a document, catching you up on a meeting you missed. That's genuine value, and for a lot of knowledge work it's plenty.
The trouble starts when Copilot becomes the entire AI strategy. "We have Copilot" turns into the answer to every AI question, and problems that Copilot cannot touch get quietly filed under "solved." I see this constantly in operations, because operations is exactly where Copilot's boundaries live.
What Copilot is actually for
Copilot, meaning the assistant itself, as distinct from Copilot Studio agents, which I'll come to, is an assistant for a person working inside a Microsoft document or conversation. That sentence sounds obvious, but every word of it is a boundary.
A person. The assistant activates when a human asks it something. It doesn't run on its own at 6 a.m. because a shipment file arrived.
Working inside. It assists the work happening in the app in front of you. It's not watching your queue, your inbox, and your vendor portal simultaneously.
A Microsoft document or conversation. Its native ground is your M365 content. The moment the work involves your ERP, your industry-specific system, a customer portal, or the database only your longest-tenured admin understands, you're at the edge of the map.
Take one concrete workflow and hold onto it, because we'll carry it through the whole framework: a purchase order arrives by email, gets validated against the ERP, updates a tracking sheet, and triggers a notification in Teams. Keep asking where that PO fits as we go.
Stay: further than most teams have gone
The first zone is the one that costs nothing extra, and it covers more ground than people expect. If the work is a person working in M365 content (writing, summarizing, searching your own documents, meeting recaps), stay put and get better at it. Most companies haven't extracted half of what the license already offers, and the two highest-leverage moves aren't features at all. Teach the team a handful of prompt patterns instead of a prompt library. And fix the content Copilot draws from, because a well-organized SharePoint is the difference between impressive answers and confident nonsense from the same product.
Where does the PO workflow fit here? Partially. Copilot will happily summarize the email thread about a problem PO, or answer "what did we agree with this vendor last quarter" from your files. A person, present, working in Microsoft content. That's real help at the edges of the workflow. It is not the workflow.
Extend: where most teams actually land
The second zone is the live decision for most operations teams, and it deserves more attention than it usually gets. When the workflow is mostly M365 work that needs a connection, a trigger, or a scoped agent, Microsoft's extension layer is genuinely productive: Copilot Studio for building agents grounded in specific content, Power Automate for trigger-and-flow automation, connectors for reaching into other systems. This is where "it answers policy questions in the Teams channel" lives, and "when the form is submitted, route it with a summary attached," and the scheduled report that drafts itself.
The simple version of the PO workflow can genuinely live here: a flow watches the inbox, an AI step extracts the fields, the tracking sheet updates, Teams gets notified. If your version is that clean, extend and be done. The zone is right when the process is simple, the volume is moderate, and you want to stay inside the licensing and governance you already have.
Its limit is complexity, and the limit announces itself. Exceptions accumulate, the flow chart stops fitting on one screen, and every "except when" adds a branch someone has to maintain. Past that point, extension projects start costing custom-app money while delivering flowchart-tool flexibility. When the PO validation logic has real rules in it (tolerance thresholds, vendor-specific handling, escalation conditions), you've hit the ceiling.
Build: when the workflow is the application
The third zone is for workflows that cross systems as their whole job, run on your own structured data, or embed decision logic you need to control and audit. The full PO workflow, with validation rules that must behave identically on Friday afternoon and Monday morning, is an application. That's not a Copilot limitation to file a complaint about; consistency and auditability are application properties, and no assistant licensing changes that.
What has changed is the price of admission. Building a focused operations app used to mean a six-figure project, which is why these workflows stayed manual for a decade. It doesn't anymore: a small team ships this class of application in weeks now, and the leaders still making the stay-or-build call with 2019 prices in their heads are leaving the most valuable workflows unfixed.
The test I give clients
If you're unsure which zone a problem lives in, ask: could one person do this task entirely inside Microsoft apps, and is a human present every time it happens?
Yes to both: stay, and get better at it. Yes to the first, no to the second: extend, and watch the complexity ceiling. No to the first: you're in build territory, and no amount of Copilot licensing will change that. Naming that boundary honestly is how you stop paying assistant prices for application problems, and application prices for assistant problems.
Where does your version of the PO workflow sit: stay, extend, or build? If you can't tell, that's usually a one-conversation answer. Ask me.